Author |
Message
|
fenway_frank |
Posted: Thu Jan 26, 2012 9:45 am Post subject: Compute node lifecycle in WMB 7.0.0.3 |
|
|
 Apprentice
Joined: 21 Oct 2011 Posts: 43 Location: Boston, MA USA
|
It's my understanding that JCNs are instantiated once (either during EG startup or perhaps upon the first call to a particular message flow) and *NOT* instantiated with each message flow invokation. Conversely, JCN is destroyed when EG is shut down so JCN is essentially a singleton static class. Is this correct?
What about ESQL compute nodes? Do they follow a similar lifecycle? |
|
Back to top |
|
 |
lancelotlinc |
Posted: Thu Jan 26, 2012 9:52 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
For JCN's the class constructor is called at EG start time and remains in memory until EG termination.
For ESQL Compute nodes, the code is interpreted and the interpreter is instantiated inside the broker instance.
Others can correct me, but I'm fairly positive about this info. _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER
Last edited by lancelotlinc on Thu Jan 26, 2012 9:59 am; edited 1 time in total |
|
Back to top |
|
 |
Vitor |
Posted: Thu Jan 26, 2012 9:53 am Post subject: Re: Compute node lifecycle in WMB 7.0.0.3 |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
fenway_frank wrote: |
What about ESQL compute nodes? Do they follow a similar lifecycle? |
Why? What difference does it make?
ESQL nodes are part of the WMB runtime. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
mqjeff |
Posted: Thu Jan 26, 2012 10:01 am Post subject: Re: Compute node lifecycle in WMB 7.0.0.3 |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
fenway_frank wrote: |
It's my understanding that JCNs are instantiated once (either during EG startup or perhaps upon the first call to a particular message flow) and *NOT* instantiated with each message flow invokation. |
That's correct to the best of my knowledge
fenway_frank wrote: |
Conversely, JCN is destroyed when EG is shut down |
That's correctish. it's also destroyed when the flow is undeployed or redeployed.
fenway_frank wrote: |
so JCN is essentially a singleton static class. |
DO NOT DESIGN FOR THIS ASSUMPTION.
fenway_frank wrote: |
What about ESQL compute nodes? Do they follow a similar lifecycle? |
Both Compute and JavaCompute... and PHPCompute and .NETCompute nodes are instances of Broker nodes. They follow the same rules and the same lifestyle as all other nodes. This is documented within the infocenter on how to construct user-defined nodes.
There is no way to add code to anything other than the 'evaluate' method of a Compute node, unlike with a JCN or PHPCN or .NETCN.
The questions you are asking are strongly hinting that you are attempting to overengineer a Broker solution to do clever things, rather than relying on how broker works to produce a reliable solution. |
|
Back to top |
|
 |
fenway_frank |
Posted: Thu Jan 26, 2012 2:22 pm Post subject: |
|
|
 Apprentice
Joined: 21 Oct 2011 Posts: 43 Location: Boston, MA USA
|
our goal is to create small, reusable utilities that help boot-strap message flow apps to shared services such as logging and exception handling.
for example, we already have a configurable service that defines location of log4j.properties file. i want to initialize log4j config once without requiring *every* new JCN to duplicate the steps in onInitialize(). same goes for esql compute nodes if possible. essentially make all compute nodes (especially jcns) automatically 'logging aware' when time comes to execute 'evaluate' api. make sense? |
|
Back to top |
|
 |
jlaisbett |
Posted: Fri Jan 27, 2012 12:29 am Post subject: |
|
|
Apprentice
Joined: 27 Nov 2009 Posts: 39
|
A JCN class is instantiated once per usage, i.e. if you have the same JCN class used by two different nodes in the same flow then it will be instantiated twice, once per node.
That said if you have multiple instances of the flow running all threads will share the same object instance of the JCN class for each node so if you are planning to do anything outside the evaluate method make sure it's thread safe.
And as mentioned every time the execution group is restarted or a new deployment is performed the classes are re-instantiated. Also the mqsireload command does the same thing. |
|
Back to top |
|
 |
mqjeff |
Posted: Fri Jan 27, 2012 2:50 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
It has generally been my experience that using onInitialize is not as useful as one would expect.
I typically adopt a pattern of "initialize on first use".
Remember that the EG is the container for both the JVM and the C++ runtime. So that any shared data you create exists only within the same EG not within the Broker as a whole. |
|
Back to top |
|
 |
fenway_frank |
Posted: Fri Jan 27, 2012 6:29 am Post subject: |
|
|
 Apprentice
Joined: 21 Oct 2011 Posts: 43 Location: Boston, MA USA
|
@mqjeff - yes, i am aware that EG is the container for jvm and c++ runtime. "first use" pattern is exactly what we want and concluded onInitialize() is the API that MbNode provides to do just that. based on your comments, however, perhaps we should consider another strategy.
@jlaisbett - i don't think JCN is instantiated per use. it's static singleton instance accessible to all flows in the EG. although we will not design to this assumption, in practice, i'm pretty sure this is current broker behavior. i can run a quick test to confirm. |
|
Back to top |
|
 |
mgk |
Posted: Fri Jan 27, 2012 7:25 am Post subject: |
|
|
 Padawan
Joined: 31 Jul 2003 Posts: 1642
|
Quote: |
i don't think JCN is instantiated per use. |
Yes it is.
Quote: |
it's static singleton instance accessible to all flows in the EG |
No it's not.
For each JCN node in each flow, a new instance of that node's class will be instanciated. Each instance is "shared" across all "instances" (threads) running against that flow.
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 |
|
 |
mqjeff |
Posted: Fri Jan 27, 2012 8:22 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
fenway_frank wrote: |
@mqjeff - yes, i am aware that EG is the container for jvm and c++ runtime. "first use" pattern is exactly what we want and concluded onInitialize() is the API that MbNode provides to do just that. based on your comments, however, perhaps we should consider another strategy. |
Yeah, I mean something like
Code: |
if singleton==null then singleton= new singleton(); |
|
|
Back to top |
|
 |
fenway_frank |
Posted: Fri Jan 27, 2012 11:51 am Post subject: |
|
|
 Apprentice
Joined: 21 Oct 2011 Posts: 43 Location: Boston, MA USA
|
ran a quick test by doing the following:
1) updated onInitialize(), onDelete(), and evaluate() jcn routines to write simple "i was here" message to text file
2) deployed message flow
3) executed message flow
4) mqsistopmsgflow
5) mqsistartmsgflow
i observed the following behaviors:
1) onInitialize() called during bar deploy or mqsistartmsgflow
2) onDelete() called during deploy or mqsistopmsgflow
3) evaluate() called each time mssage flow is executed
thus, i concluded that jcns are indeed instantiated once during deploy and/or eg startup and not with every message flow execution. i understand the jcn is scoped to the message flow (not the entire eg) and shared across concurrent msg flow threads. given these findings, i think we're all set to continue with design. thx for ur input.[/list] |
|
Back to top |
|
 |
|