| Author |
Message
|
| prasadpav |
 Posted: Mon Dec 03, 2012 7:44 am Post subject: JavaCompute node - Non-static variable scope |
 |
|
Centurion
Joined: 03 Oct 2004
Posts: 142
|
I'm using message broker "7.0.0.2" on Linux environment. I'm finding an odd behaviour with the non-static variables that I've defined in my java compute node. I expected non-static variables values to be specific to the current message interaction; however, these variables are exhibiting "static" variable scope. Here is the simple code which I'm testing using MQInput node wired to the java compute node:
| Code: |
public class PrivateVariableBehaviour_JavaCompute extends MbJavaComputeNode {
private String tester;
public void evaluate(MbMessageAssembly assembly) throws MbException {
MbOutputTerminal out = getOutputTerminal("out");
MbOutputTerminal alt = getOutputTerminal("alternate");
MbMessage message = assembly.getMessage();
System.out.println((tester == null)?"tester variable is - " + tester:"tester variable is NOT null - " + tester);
if (tester == null)
tester = Long.toString(System.currentTimeMillis());
out.propagate(assembly);
}
} |
The output from this code for each MQInput message is (4 messages injected in total):
| Code: |
tester variable is - null
tester variable is NOT null - 1354548809199
tester variable is NOT null - 1354548809199
tester variable is NOT null - 1354548809199
|
Is this the correct behaviour?
Thanks in advance. |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Mon Dec 03, 2012 7:50 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
JVM maintains objects and variables defined in those objects are not guaranteed to be static but often are. Don't depend on the variables within objects to be static.
What you are observing is the situation where the object left scope of the evaluate method in the JCN but the gc not collected (ttl not exceeded) and a new message arrived before the scope was nulled by ttl.
Don't depend on this behavior; its coincidental to your operation.
Have explicit cleanup done by setting static variables to null.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Dec 03, 2012 8:15 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
There is only one instance of your class.
Therefore, there is only one copy of your class-level variables.
If you want to define variables that will be specific to each message interaction, you need to define those variables within the evaluate() method.
Or initialize them within the evaluate() method. |
|
| Back to top |
|
|
| prasadpav |
| Posted: Mon Dec 03, 2012 9:02 am Post subject: |
|
|
Centurion
Joined: 03 Oct 2004
Posts: 142
|
| I thank you both for the explanation. It makes sense now. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Dec 03, 2012 9:06 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Your welcome. You may like to update your version to a more recent fix pack 7.0.0.5. There are lots of bug fixes between 7.0.0.2 and 7.0.0.5.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| prasadpav |
| Posted: Mon Dec 03, 2012 9:40 am Post subject: |
|
|
Centurion
Joined: 03 Oct 2004
Posts: 142
|
| We've recently gone through lengthy discussions whether to upgrade or not, if so when to upgrade. It is not going to happen soon but it is in the pipeline. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Dec 03, 2012 9:51 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
It seems your management wants to be bitten by the bug rather than innoculated for it ? LOL !
Be sure the runtime 'effective level' is set properly. mqsireportbroker
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Dec 03, 2012 12:26 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
With apologies to lancelotinc, whose non-training-related contributions are very much valued...
This is nothing to do with garbage collection. There is no 'race condition' going on here. As mqjeff says, each instance of a message flow flow maintains exactly one instance of the MbJavaComputeNode class. Any class members in your derived class will therefore have the same lifetime as the deployed message flow.
I feel a bit of a pedant for mentioning it, but it's easy for folk tales like this to take on a life of their own. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Dec 03, 2012 12:37 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| kimbert wrote: |
| With apologies to lancelotinc, whose non-training-related contributions are very much valued... |
lolz kimbert...
| kimbert wrote: |
| This is nothing to do with garbage collection. There is no 'race condition' going on here. As mqjeff says, each instance of a message flow flow maintains exactly one instance of the MbJavaComputeNode class. Any class members in your derived class will therefore have the same lifetime as the deployed message flow. |
Can you talk more about multi-message flow-instance interaction with regard to static variables contained within JCNs?
I realize my description above is not ideal. Thanks for setting it straight.
Please describe the thread safety of MbJavaComputeNode-derived objects. Would static objects be sync'd or not?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mgk |
| Posted: Mon Dec 03, 2012 1:11 pm Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
| Quote: |
| Can you talk more about multi-message flow-instance interaction with regard to static variables contained within JCNs? |
Yes. Static variables are shared at the scope of the classloader, so if you use a classloader configurable service, the same static variable is visible to all other Java code loaded by the same class loader. This includes Java methods called from ESQL declared with a classloader (in 8.0.0.1) as well as other JCN's using the same classloader etc.
Instance members of a class are shared between all users of a class. As a given JCN is only instantiated once per flow this equates to all additional instances of the flow in WMB.
| Quote: |
| Please describe the thread safety of MbJavaComputeNode-derived objects. Would static objects be sync'd or not? |
Essentially you (the developer) has to ensure the thread safety of any static variables or member (class) variables. The Broker does not provide any external locking for the evaluate() method - essentially evaluate() must be reenterant. However, any default constructor, the onInitialize() method and the onDelete() method are always called under a Broker lock. FYI, the thread that calls them is not one of the ones that ever calls evaluate().
| Quote: |
| Be sure the runtime 'effective level' is set properly. mqsireportbroker |
There seems to be a little misconception about what the "effective level" is so I want to try and make it clearer. When you install a fixpac, all defect fixes are always applied, whatever the effective level is set to. You only need to change the effective level to turn on any new functionality delivered in that fixpac, not to get the fixes themselves. This allows us to deliver new functionality as "off" by default, allowing the user to choose to turn on the new functionality if they choose to use it.
I hope this helps a little...
Kind regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions.
Last edited by mgk on Mon Dec 03, 2012 1:43 pm; edited 1 time in total |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Dec 03, 2012 1:36 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Very nice information Mr. mgk. Thank you.
| mgk wrote: |
| the onInitialize() method and the onDelete() method are always called under a Broker lock. |
If you choose, please specify the process owner of the process that owns this Broker lock. What is the implication if the pgid for this process is not the same as mqbrkrs group id?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Dec 03, 2012 1:38 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
Very nice information Mr. mgk. Thank you.
| mgk wrote: |
| the onInitialize() method and the onDelete() method are always called under a Broker lock. |
If you choose, please specify the process owner of the process that owns this Broker lock. What is the implication if the pgid for this process is not the same as mqbrkrs group id? |
The only process that could possibly own this lock is the EG process itself. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Dec 03, 2012 1:40 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| mqjeff wrote: |
| lancelotlinc wrote: |
Very nice information Mr. mgk. Thank you.
| mgk wrote: |
| the onInitialize() method and the onDelete() method are always called under a Broker lock. |
If you choose, please specify the process owner of the process that owns this Broker lock. What is the implication if the pgid for this process is not the same as mqbrkrs group id? |
The only process that could possibly own this lock is the EG process itself. |
Correct. And if this process pgid is not mqbrkrs, what is the result of attempting to get the lock?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mgk |
| Posted: Mon Dec 03, 2012 1:41 pm Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
| Quote: |
| The only process that could possibly own this lock is the EG process itself. |
Correct. The lock is local to the EG itself and is not shared between processes. As the static variable cannot be directly shared between processes, using a cross process lock for this would be overkill in the extreme 
Kind regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Dec 04, 2012 6:23 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
I'm trying to drive toward the pgid issue where perhaps the EG is running under a service Id that gets the lock and an mqsideploy invokes a call to get the same lock with a different pgid.
Hypothetically, I'm posing this question to see if those who wrote the code can postulate the result of the lock being owned by a pgid other than mqbrkrs.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
|
|
