| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Experience with Java-written exits - anyone can contribute? |
« View previous topic :: View next topic » |
| Author |
Message
|
| HenriqueS |
 Posted: Fri Jul 27, 2007 1:23 pm Post subject: Experience with Java-written exits - anyone can contribute? |
 |
|
Master
Joined: 22 Sep 2006
Posts: 235
|
Folks,
We are porting an MQ-based app from mainframe to a open platform.
We have currently some simple send/receive exits on the mainframe to change some message characteristics and to do some accounting. Well, in the mainframe this code is written in 8070 lines of pure S/390 assembly code.
I wanted to know if anyone is using Java-written exits and how is the performance-wide impact on the execution of such exits. The JVM has an expensive bootstrap even to run a simple "Hello World". Think about this happenning thousands of times per minute...
--------
* For trigger monitors, we created or own java trigger monitor, as a daemon, that monitors an init queue (MQ will put trigger messages there if there is any process watching that queue and there is a process definition setted - in our case the process definition is just blank). This way the trigger monitor is who dispatches the necessary actions, with a preloaded JVM, which save resources. But for an exit() we don´t see any light... |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Jul 27, 2007 1:51 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
The only java written exits I know of are client side exits. The most commonly used would be the security exit.
There are no server side java exits...
What are you trying to do?
Could it be that the J2EE/JMS model suits you better?
I don't see the purpose of writing your own trigger monitor either.
a) the messages are so sparse that trigger time is not a problem
b) the messages come in a short interval. The process does a get with wait ... It gets triggered only once and keeps running until the queue is empty...
Of course you can't use trigger every either...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| HenriqueS |
| Posted: Fri Jul 27, 2007 2:22 pm Post subject: |
|
|
Master
Joined: 22 Sep 2006
Posts: 235
|
Thanks for clarifying about the inexistence of server side exits in Java. So I guess C is the only way to go (I suspected while reading the docs - some keywords as "dllname"...)
I am not an J2EE guy, but message driven beans were discarded because it seems they add complexity for our current channel/queue schema (hub topology in which we are the nucleus, talking to more than 100 financial instituitions). The new app will run under a J2EE context for transaction management benefits, but will use plain JMS (except the exits...).
The own written trigger monitor initiative took place just for incoming message consumption in a continuous task (GET from queue, write to DB2). After this, the J2EE app enter in scene dealing with the DB2 contents and constructing/sending the response messages.
Or we did this or we pointed MQ to a custom trigger, that should be written in Java also (internal affairs apply here), which would rise a new JVM every while. We knew about this method that gets the message and waits for a while, which would shorten the number of JVM launches, but we wrote the custom trigger monitor anyway, it was not hard to code and will give to us a single instance of input processing, which diminishes any concurrency issue.
Thanks for your input. When the project gets ready, I will write a small document for all mqseries.net people to show our effort.
| fjb_saper wrote: |
The only java written exits I know of are client side exits. The most commonly used would be the security exit.
There are no server side java exits...
What are you trying to do?
Could it be that the J2EE/JMS model suits you better?
I don't see the purpose of writing your own trigger monitor either.
a) the messages are so sparse that trigger time is not a problem
b) the messages come in a short interval. The process does a get with wait ... It gets triggered only once and keeps running until the queue is empty...
Of course you can't use trigger every either...
Enjoy |
|
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jul 27, 2007 5:03 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I can't help but think that you are reinventing the wheel in a number of places.
It would take a very peculiar combination of requirements for me to design a solution that approached what you are proposing.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Jul 28, 2007 3:28 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| HenriqueS wrote: |
| Thanks for clarifying about the inexistence of server side exits in Java. So I guess C is the only way to go (I suspected while reading the docs - some keywords as "dllname"...) |
That's right
| HenriqueS wrote: |
| I am not an J2EE guy, but message driven beans were discarded because it seems they add complexity for our current channel/queue schema (hub topology in which we are the nucleus, talking to more than 100 financial instituitions). The new app will run under a J2EE context for transaction management benefits, but will use plain JMS (except the exits...). |
Don't. You loose a lot of functionality there. Message Beans give you out of the box transaction management, scalability, and a number of other benefits that you would have to code for. And they ARE plain JMS...
| HenriqueS wrote: |
The own written trigger monitor initiative took place just for incoming message consumption in a continuous task (GET from queue, write to DB2). After this, the J2EE app enter in scene dealing with the DB2 contents and constructing/sending the response messages.
Or we did this or we pointed MQ to a custom trigger, that should be written in Java also (internal affairs apply here), which would rise a new JVM every while. We knew about this method that gets the message and waits for a while, which would shorten the number of JVM launches, but we wrote the custom trigger monitor anyway, it was not hard to code and will give to us a single instance of input processing, which diminishes any concurrency issue. |
Bad design. Your input goes to the DB. The only concurrency issue you have is the insert command to the DB. You need a unique key. You could use an incremental key or the MessageId...
For speed and scalability you want it as concurrent as possible. Note you should not have any message affinity as this (message affinity) is always a bad design. Message affinity kills your scalability and slows down performance...to the point of sometimes not being able to handle the volume... But then logging the msg in a DB and processing from the DB alleviates most of the concerns about message affinity...
| HenriqueS wrote: |
Thanks for your input. When the project gets ready, I will write a small document for all mqseries.net people to show our effort.
|
Thanks, I'm sure the readers will appreciate your way of solving the challenges they face.
Enjoy
_________________
MQ & Broker admin |
|
| 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
|
|
|
|
