|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
What is the correct way to detect primary/secondary instance |
« View previous topic :: View next topic » |
Author |
Message
|
ghoshly |
Posted: Wed Apr 16, 2014 6:40 am Post subject: What is the correct way to detect primary/secondary instance |
|
|
Partisan
Joined: 10 Jan 2008 Posts: 333
|
Hello,
Need suggestion on WMB V8.0.0.2 with extreme scale for cache.
We have a single broker running in multi-instance mode. Instance1 is running with cache data in server1 and instance2 is stand by in server2.
Our code looks for data in cache, if data is not available in cache, it performs database lookup.
During failover instance2 becomes active but is unable to access cache. (Limitation confirmed by IBM through PMR because of single broker)
When wmb code in instance2 tries to connect to cache, it takes almost 30 seconds to respond with the error (Connection exception). Is there any retry attempt being performed which we can configure?
Code: |
2014-04-16 07:50:33.692176 6349 UserTrace BIP2539I: Node '': Evaluating expression ''CH_MapKey'' at ('.ICE_ProfileLoader_Update_ICE_Profile.Main', '70.57'). This resolved to ''CH_MapKey''. The result was '''TMCInvoicingIRExportUSAEI0050TMCGetIRMessage'''.
2014-04-16 07:51:03.720840 6349 UserTrace BIP2918I: Node 'ICE_ProfileLoader.Update_ICE_Profile': Executing Java Method ''com.java.cache.flow.MBGlobalMapWrapper.get'' derived from ('Utils.PROC_getMBGlobalMapWrapper', '1.4'). Parameters passed '''TMCInvoicingIRExportUSAEI0050TMCGetIRMessage', 'RequestDataMap', REFERENCE''. Resulting parameter values '''TMCInvoicingIRExportUSAEI0050TMCGetIRMessage', 'RequestDataMap', REFERENCE''. Return value '''<com.ibm.broker.plugin.MbRecoverableException class:MbEmbeddedCacheConnection method:MbEmbeddedCacheConnection source:BIPmsgs key:7164 >'''. |
What would be the best way to identify the broker instance from esql code itself so that when it is instance2 (Initial passive instance) code does not attempts to connect with cache?
Workaround -
Through java we can identify the broker host name and through that we can make out the current server, but certainly not the best way. |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Apr 16, 2014 9:10 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
check with IBM. However I believe that when you set the cache policy you can specify "localhost". So if you really do run only one broker in the environment, setting the listener host to 'localhost' should allow you to find the global cache on which ever host the broker is currently active...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
ghoshly |
Posted: Wed Apr 16, 2014 10:34 pm Post subject: |
|
|
Partisan
Joined: 10 Jan 2008 Posts: 333
|
Hi,
Already tried with localhost or virtual IP (VIP) but no luck. IBM confirmed, its would be possible in IIB only.
Hence trying to identify the instance either through esql or java api. |
|
Back to top |
|
 |
ghoshly |
Posted: Mon Apr 21, 2014 7:21 am Post subject: How to reduce time out??? |
|
|
Partisan
Joined: 10 Jan 2008 Posts: 333
|
Quote: |
When wmb code in instance2 tries to connect to cache, it takes almost 30 seconds to respond with the error (Connection exception). Is there any retry attempt being performed which we can configure?
|
Through configuration, can we reduce the time out period WMB cache takes before throwing exception while connecting to cache from secondary server. |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|