| Author |
Message
|
| Melanie.kiit |
 Posted: Thu Jun 11, 2015 5:14 am Post subject: Caching in Message Broker |
 |
|
Newbie
Joined: 20 May 2015
Posts: 5
|
Hi there,
Does caching takes place for a broker?
I got this on net -
The broker itself does not do any DNS caching. However, broker does rely on a JVM. Java by default does do DNS caching. We do not override the defaults to disable them.
If the above is true, can someone please tell me how can I get to know the current caching value(set in/by JVM)?
Thanks in Advance!
Melanie |
|
| Back to top |
|
 |
| zpat |
| Posted: Thu Jun 11, 2015 5:20 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Java's JVM has the horrible default of indefinite DNS caching. Regardless of what the individual TTL might be set to.
To override this and force a 300 second expiry value use this setting on the broker profile (I am assuming Unix here), before starting the broker.
export MQSIJVERBOSE=-Dsun.net.inetaddr.ttl=300
If you run the netcd DNS caching Daemon you need to change that as well, otherwise you get 60 minute caching at the OS level.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jun 11, 2015 5:21 am Post subject: Re: Caching in Message Broker |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Melanie.kiit wrote: |
got this on net -
The broker itself does not do any DNS caching. However, broker does rely on a JVM. Java by default does do DNS caching. We do not override the defaults to disable them. |
From where? Post the link.
| Melanie.kiit wrote: |
| If the above is true |
It is
| Melanie.kiit wrote: |
| can someone please tell me how can I get to know the current caching value(set in/by JVM)? |
See here as a starting point.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jun 11, 2015 6:27 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You can also update the JVM DNS TTL behaviour by editing the relevant java policy files.
It affects the broker nodes which are internally coded in Java (e.g. the fileoutput node). Not all broker nodes are coded in Java.
However the broker profile override works fine.
Don't forget that the JVM will obtain the DNS values from the host OS - if that OS caches, you need to take that into account as well.
However Windows and Unix at least don't have defaults of indefinite DNS caching.
Which OS do you use?
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| Melanie.kiit |
| Posted: Fri Jun 12, 2015 4:30 am Post subject: |
|
|
Newbie
Joined: 20 May 2015
Posts: 5
|
Thank you guys for your help.
| Code: |
| See here as a starting point. |
As per IBM infocenter, once the networkaddress.cache.ttl value is changed in java.security file
Next Step should be :-
"mqsichangeproperties <BrokerName> -e <IntegrationServer> -o ComIbmJVMManager -n jvmSystemProperty -v"- Dsun.net.inetaddr.ttl=0"
If I change the value of ttl=0 in java.security file and restart the broker, do I still have to run the mqsichangeproperties comand to make caching time null?
Victor - The link you asked for : https://developer.ibm.com/answers/questions/184741/does-brokeriib-do-any-dns-caching.html.
TA |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Jun 12, 2015 5:00 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Using the profile option (in my apparently invisible post above) avoids the need to change each execution group.
Also using a low value, rather than having no caching at all will help performance, if repeated requests are made in a short period of time.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| Melanie.kiit |
| Posted: Mon Jun 15, 2015 1:36 am Post subject: |
|
|
Newbie
Joined: 20 May 2015
Posts: 5
|
Thanks a lot zpat for letting me know and yes would definitely agree upon an appropriate value for the time.
TA |
|
| Back to top |
|
|
|
|
