| Author |
Message
|
| Tanesh |
 Posted: Fri Aug 28, 2009 1:53 am Post subject: JavaCompute and Compute Node Design Considerations |
 |
|
Newbie
Joined: 29 Jun 2009
Posts: 8
|
Hi,
While designing the MB solution, what would be the factors to use either Compute node or JavaCompute node ?
I mean to say when do we prefer Compute node over JavaCompute node and vice-versa ? What are the pros and cons of using these nodes ?
Thanks,
Tanesh. |
|
| Back to top |
|
 |
| WMBDEV1 |
| Posted: Fri Aug 28, 2009 2:06 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
Compute nodes perform better than java nodes when doing pure transformations.
I tend to only use java nodes over compute nodes for stuff that cant be achieve with ESQL for example compressing the contents of messages.
If its a simple bit of functionality in java that doesnt warrant a compute node you may also choose to just call a particular java method from within ESQL. |
|
| Back to top |
|
|
| Luke |
| Posted: Fri Aug 28, 2009 2:57 am Post subject: |
|
|
Centurion
Joined: 10 Nov 2008
Posts: 128
Location: UK
|
I think a major consideration would be what skills your developers have, and are likely to have going forward (for maintenance).
My understanding is that Java compute nodes were introduced to help out people who have Java skills. What you can actually do with them was intended to mirror the things you can do in ESQL compute nodes. |
|
| Back to top |
|
|
| ovasquez |
| Posted: Fri Aug 28, 2009 3:11 am Post subject: |
|
|
Centurion
Joined: 09 Dec 2005
Posts: 141
Location: Lima, Peru
|
| Luke wrote: |
I think a major consideration would be what skills your developers have, and are likely to have going forward (for maintenance).
My understanding is that Java compute nodes were introduced to help out people who have Java skills. What you can actually do with them was intended to mirror the things you can do in ESQL compute nodes. |
Maybe, but for use JavaCompute is necesary kwow Java+API Java for NodeJavaCompute too, I know SQL and Java, in my case is more easy use ESQL than Java for transformation. 
_________________
Oscar Vásquez Flores |
|
| Back to top |
|
|
| Tanesh |
| Posted: Thu Sep 03, 2009 6:32 am Post subject: |
|
|
Newbie
Joined: 29 Jun 2009
Posts: 8
|
But using Java eventually leads to poor performance as compared to ESQL. Moreover using the JVM with Message Broker Server created severe problems in our production environment when dealing with huge messages.
Also as there are memory leak problems with JVM, does making use of Java in MB lead to frequent schedulded downtimes ?
Please let me know your views on this. |
|
| Back to top |
|
|
| jbanoop |
| Posted: Thu Sep 03, 2009 6:40 am Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
you have multiple ways of dealing with JVM memory issues including increasing the JVM heap size and if required the memory allocated to each execution group.
It would also depend on how optimally you have coded your message flows to handle referencing elements in the message.
I am aware of a number of projects with a java implementation that are processing large sized messages successfully.
I do admit though that coding a flow in ESQL has seemed much more straightforward, easier and readable in many cases (personally). |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Sep 03, 2009 6:53 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Tanesh wrote: |
| But using Java eventually leads to poor performance as compared to ESQL. Moreover using the JVM with Message Broker Server created severe problems in our production environment when dealing with huge messages. |
You seem to have answered your own original post. Though despite my aversion to Java I'm surprised it has problems with large messages. I'd be more suspicious of your Java code than Java code in general. There are a number of discussions on this forum on how to deal with huge messages (which if processed with badly written ESQL cause problems as well).
| Tanesh wrote: |
Also as there are memory leak problems with JVM, does making use of Java in MB lead to frequent schedulded downtimes ?
Please let me know your views on this. |
My view is that if the broker JVM leaks you should raise a PMR.
Apart from that, I agree and endorse the comments of previous posters.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Thu Sep 03, 2009 6:58 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| Tanesh wrote: |
Moreover using the JVM with Message Broker Server created severe problems in our production environment when dealing with huge messages.
|
You have to write the code specifically to handle large messages to do this (as you do in ESQL). You may also have to increase the JVM size but it should be possible to do it.
| Quote: |
Also as there are memory leak problems with JVM, does making use of Java in MB lead to frequent schedulded downtimes ?
|
Where is your proof?
| Quote: |
Please let me know your views on this. |
Sounds odd to me... I've used Java to handle large messages (200MB compressed to about 40MB) without issue. |
|
| Back to top |
|
|
|
|
