| Author |
Message
|
| er_pankajgupta84 |
 Posted: Thu Feb 02, 2012 2:38 pm Post subject: Extending JavaCompute Node |
 |
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
Is it advisable to extend Java Compute node and create a customised java class.
For example
| Quote: |
public class BrokerEnvironmentDetails extends MbJavaComputeNode {
public void evaluate(MbMessageAssembly arg0) throws MbException {}
public String getExectionGroupName() {
MbExecutionGroup mbEgName = null;
try {
mbEgName = getExecutionGroup();
}
catch (MbException e) {}
return mbEgName.getName();
} |
Then call this method from my plain java code like this -
| Quote: |
BrokerEnvironmentDetails brokerEnvDtls = new BrokerEnvironmentDetails();
egName = brokerEnvDtls.getExectionGroupName();
|
I tested this it works fine. But I have checked what's going on in the back group.
Need some expert advice. If we should not do something like this then why?
MbJavaComputeNode is deployed as a singleton class. Is this thing effect here? |
|
| Back to top |
|
 |
| er_pankajgupta84 |
| Posted: Thu Feb 02, 2012 4:42 pm Post subject: |
|
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
|
| Back to top |
|
|
| jlaisbett |
| Posted: Thu Feb 02, 2012 7:20 pm Post subject: |
|
|
Apprentice
Joined: 27 Nov 2009
Posts: 39
|
Extending MbJavaComputeNode is completely fine if for example you want to have a parent class for several JCN's but instantiating a class that extends it is not.
Brokers class loaders have very specific rules about instantiating instances of MbJavaComputeNode that can cause you grieve if you try to instantiate it yourself, the recommendation is that all classes that extend MbJavaComputeNode should only ever be instatiated by broker. |
|
| Back to top |
|
|
| er_pankajgupta84 |
| Posted: Thu Feb 02, 2012 7:51 pm Post subject: |
|
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
So my first part is right
| Quote: |
public class BrokerEnvironmentDetails extends MbJavaComputeNode {
public void evaluate(MbMessageAssembly arg0) throws MbException {}
public String getExectionGroupName() {
MbExecutionGroup mbEgName = null;
try {
mbEgName = getExecutionGroup();
}
catch (MbException e) {}
return mbEgName.getName();
} |
but second part is not recommended as per best practices.
| Quote: |
BrokerEnvironmentDetails brokerEnvDtls = new BrokerEnvironmentDetails();
egName = brokerEnvDtls.getExectionGroupName(); |
What if I make my class (BrokerEnvironmentDetails ) as singleton? Is it acceptable?
Also.. can I get some information or proof from any ibm specified source that say you cannot/shouldnot instantiate classes extended from JavaComputeNode. I still don't get the reason why should not we do this.
[/quote] |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Fri Feb 03, 2012 12:17 am Post subject: Re: Extending JavaCompute Node |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| er_pankajgupta84 wrote: |
| Is it advisable to extend Java Compute node and create a customised java class. |
MbJavaComputeNode is an abstract class. The only way to use it is to create a customized java class that extends it. But it's not advisable to do that outside of a JavaCompute node.
| er_pankajgupta84 wrote: |
| If we should not do something like this then why? |
The documentation for the JavaCompute node advises against it:
| Quote: |
| Restriction: Do not try to create another instance of a JavaCompute node from Java code; this is not supported. |
The documentation for the CREATE FUNCTION and CREATE PROCEDURE statements advise against it: (MbJavaComputeNode extends MbNode)
| Quote: |
| Restrictions on Java routines: Java methods that are called from ESQL must not use the MbNode class. Therefore, they cannot create objects of type MbNode, or call any of the methods on an existing MbNode object. |
There are likely undocumented dependencies between these two classes and the broker runtime, hence the restrictions.
| er_pankajgupta84 wrote: |
| MbJavaComputeNode is deployed as a singleton class. |
The MbJavaComputeNode class is technically not a singleton. |
|
| Back to top |
|
|
| er_pankajgupta84 |
| Posted: Fri Feb 03, 2012 7:33 am Post subject: |
|
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
I am good on this.
Anyone can extend MbJavaComputeNode but those classes should only be used for JavaComputeNode.
Instantiate a class extended from MbJavaComputeNode will not give any compile time error. One should never instantiate a class extended from MbJavaComputeNode. This will cause Execution Group to abend.
I also tried by making the class "BrokerEnvironmentDetails" as singleton but that also caused EG abend.
Thanks for your help - rekarm01,jlaisbett. |
|
| Back to top |
|
|
| er_pankajgupta84 |
| Posted: Fri Mar 30, 2012 6:55 am Post subject: |
|
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
I got the broker and Execution Group details by extending & initiating MbNode instead of MbJavaComputeNode.
Here is what I did:
Created a class:
| Code: |
| public class BrokerEnvironmentDetails extends MbNode |
Create a utility class (non JCN compute node) & instantiated BrokerEnvironmentDetails and invoke various methods to get broker & execution details.
I don't face any issue.
Earlier when I tried this with MbJavaComputeNode then my EG abends.
Just wanted to share the summary so posted this. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Mar 30, 2012 7:01 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| er_pankajgupta84 wrote: |
I don't face any issue.
Earlier when I tried this with MbJavaComputeNode then my EG abends.
Just wanted to share the summary so posted this. |
I have 3 questions, rooted deep in my extensive Java knowledge (!):
- what value does doing this add given that WMB != WAS?
- how extensive was the testing in which you didn't face any issues, i.e did you test it under load, with multiple flow instances, etc, etc?
- given that the documentation seems to discourage the use of MbNode, how certain are you that this is an IBM supported configuration?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Mar 30, 2012 7:02 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You don't remotely need to extend these classes to get the info you need.
Your JavaCompute node class extends MBNode already, and for example
| Quote: |
| MbBroker provides access to various broker related information such as broker name, queue manager name. An instance of this class is returned by the getBroker method of MbNode. |
So you can just
| Code: |
MbBroker thisBroker = getBroker();
String brokerName = thisBroker.getName(); |
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Mar 30, 2012 7:06 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Hrm.
Let me clarify and reexplain.
All JavaCompute node classes must extend MBNode and must implement MBNodeInterface.
Once you have done this, there is no reason to create a utility class that also does this. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Mar 30, 2012 1:31 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
And by the way, look up the documentation, you can also retrieve some of those values in ESQL
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Sat Mar 31, 2012 8:54 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| mqjeff wrote: |
You don't remotely need to extend these classes to get the info you need.
Your JavaCompute node class ... |
The question was whether it was advisable to extend these classes outside of a JavaCompute node.
| er_pankajgupta84 wrote: |
Create a utility class (non JCN compute node) & instantiated BrokerEnvironmentDetails and invoke various methods to get broker & execution details.
I don't face any issue ... |
... yet. Even if it seems to work for the moment, it's still ill-advised, unsupported, and unnecessary. |
|
| Back to top |
|
|
| er_pankajgupta84 |
| Posted: Mon Apr 02, 2012 11:28 am Post subject: |
|
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
@vitor - We have tested this several times with production load testing with multiple instance. (Tested under 47 TPS for hours)
@jeff - We are using one existing framework implemented in java for DB2 connection pooling. For having proper monitoring thru logs & JConsole we need to have broker & EG details.
I am aware of ESQL & JCN functions to get Broker & EG information.
As I mentioned, Extending JavaCompute didn't work for us but extending MbNode (Outside JCN) worked. We are doing testing for the same.
So far no issues.
But after reading all the coments I think I will ask team to get this reviewed by IBM consultant. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 02, 2012 11:45 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| er_pankajgupta84 wrote: |
| @vitor - We have tested this several times with production load testing with multiple instance. (Tested under 47 TPS for hours) |
47 TPS is not load. 47 TPS is "busy".
| er_pankajgupta84 wrote: |
| We are using one existing framework implemented in java for DB2 connection pooling. |
Why?
| er_pankajgupta84 wrote: |
| For having proper monitoring thru logs & JConsole we need to have broker & EG details. |
So this has no business value? Just technical value
| er_pankajgupta84 wrote: |
| But after reading all the coments I think I will ask team to get this reviewed by IBM consultant. |
Be sure that's a "works for IBM" consultant rather than a "works with IBM" consultant.
I'd be more inclined to raise a PMR and get an official assurance that this is a supported configuration.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| er_pankajgupta84 |
| Posted: Mon Apr 02, 2012 11:52 am Post subject: |
|
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
| Quote: |
er_pankajgupta84 wrote:
For having proper monitoring thru logs & JConsole we need to have broker & EG details.
So this has no business value? Just technical value |
YES.
| Quote: |
| I'd be more inclined to raise a PMR and get an official assurance that this is a supported configuration. |
 |
|
| Back to top |
|
|
|
|
