| Author |
Message
|
| sfari |
 Posted: Tue Mar 21, 2006 9:19 am Post subject: Performance Problem with Java Send Exit |
 |
|
Centurion
Joined: 15 Apr 2003
Posts: 144
|
Hi,
Already since around one Year we are using a SendExit in all our JMS Applications to set the logged in UserID (UserID from the Java Context) into the message UserID header. To achive this I manipulate the first segment and let the others without any manipulation through the exit. We need to have the userid in the messages for auditing reasons.
This works fine as long as the messages are small. We have now a new application which puts and gets messages up to 50 MB.
I have seen that having such messages a Java Send exit has a massive impact on the performance, even if it does nothing.
My Tests putting and getting a 20 MB message...
without an Exit: 18s
with an empty Exit, just returning the same buffer: 66s
As far as I know there is no other possibility to set a userid from JMS into the message header. Or is it?
Thanks, Silvano |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Mar 21, 2006 10:48 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Well I'd have a little different question:
What do you really need the user id for?
Could it be just recorded on the RFH2 header as a property?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| wschutz |
| Posted: Tue Mar 21, 2006 10:53 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
or put into the MQMD.UserId field?
_________________
-wayne |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Mar 21, 2006 11:03 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| wschutz wrote: |
| or put into the MQMD.UserId field? |
Not in JMS. In JMS the send operation always sets the UserID to the user for the connection.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Mar 21, 2006 9:46 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
The standard JMS way to set the UserID and password is:
| Code: |
QueueConnection qc = qcf.createQueueConnection("myUserId",null);
// or
QueueConnection qc = qcf.createQueueConnection("myUserId","myPassword"); |
Surprisingly, this works too:
| Code: |
| MQEnvironment.userID = "myUserId"; |
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| sfari |
| Posted: Tue Mar 21, 2006 10:46 pm Post subject: |
|
|
Centurion
Joined: 15 Apr 2003
Posts: 144
|
It is a policy in our company to pass the originator within each message. Since we are also sending messages to the mainframe from J2EE applications we need to do it in the UserID MQMD field. It is comfortable to have it in that header because you can access it on every platform with every programming language without knowing anything about the content format.
As jefflowrey mentioned in JMS it is not possible to set this into the message since the JMS provider will always overwrite it.
@Roger, your suggestion works fine as long as for each user session a new connection will be created. But what about if a container is creating a fix connection pool and shares them between the different user sessions.
For that reasons the only possibility that came into my mind is to set it directly into the message buffer in a Send Exit. But since this is a big performance issue I am looking again for alternatives.
Any more ideas? |
|
| Back to top |
|
|
| wschutz |
| Posted: Wed Mar 22, 2006 2:30 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Did you try increasing the jvm's heap size?
_________________
-wayne |
|
| Back to top |
|
|
| sfari |
| Posted: Wed Mar 22, 2006 6:45 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2003
Posts: 144
|
Thanks wschutz! Good idea!
I had following seetings before:
It took: 66s
Now I have:
It takes: 37s
This is a great improvement but still double than without SendExit, then it takes only: 18s
The mentioned times are the duration of putting and getting a 20MB Message. Any Idea how to improve even more? |
|
| Back to top |
|
|
| wschutz |
| Posted: Wed Mar 22, 2006 12:55 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Well, I don't know much about jvm tuning, but does 640M help or hurt? (arggg...640K used to be the maximum on pc's, didn't it?)
_________________
-wayne |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Mar 22, 2006 1:02 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I think if you try Roger's code, it may work and not require the send exit.
Otherwise, you need to consider that your code basically needs many different copies of the message buffer - at least one in the application and and at least two in the exit - one before and one after the change.
And so consequently, you need to ensure that your JVM has as much available heap to cover all the size you're using for your messages.
Also consider upgrading your MQ Client to the most recent codebase for the verison your using (v5.3 FP12 or 6.0 RP1). There are almost always speed and memory improvements for the java classes in a FP/RP.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Mar 22, 2006 8:00 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I would still like to question your setup.
There is a support pack called XMS out there that will allow you to receive full JMS messages and interpret the RFH header in non JMS langages (C etc...)
Why go to the trouble if you can set the user id just as a message property in the user "tags" of the RFH header.
If you use a broker or a simple non JMS message to recode from the RFH header you can then set the MQMD property. And this should be way faster even then your exit...
At the same time I would like to question your need for messages of such a big size. What are you really trying to do? Could there be a conceptuel problem causing such big messages?
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| sfari |
| Posted: Thu Mar 23, 2006 4:00 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2003
Posts: 144
|
Thanks for all the answers guys 
@jefflowrey: No the code doesn't work because the container makes the connections in advance and not for each logged in user, so you can not set individual userids.
@fjb_saper: We are providing a distributed application platform. MQ is running on solaris, z/os, windows. Different programming languages are used in many different applications running on this platform. We have kind of principal propagation over the whole platform. Applications on the mainframe are usually setting the userid into the MQMD header and in my opinion this header is exactly designed for that. So we thought to do it eqally on all other platforms and programming languages too. Some applications need the userid, some are only logging it for auditing reasons. About the big messages, i totally agree with you. It is a misconcept but the buisiness wants it even knowing that it is not a proper use of MQ. So we from the infrastructure have to enable it!
I am wondering is there nobody else which is propagating principals in the message header? What are you doing with the MQMD userid field and what is the real purpose of it it it's not propagating principals? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Mar 23, 2006 5:03 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| sfari wrote: |
| I am wondering is there nobody else which is propagating principals in the message header? What are you doing with the MQMD userid field and what is the real purpose of it it it's not propagating principals? |
Well the question is really what do you do with it. I know the MF reacts a little bit different and you can use the Id for RAC authentication on transactions.
But on most of the distributed environments the message is consumed with the authority of the consumer and this field would only serve as logging info? Check as well what happens to it if the channel is using an MCAUSER...
Now if you add any of the MQ report features you might be shooting yourself in the foot as the target QM is trying to use that authority to send you the report... Having to fix one is much easier than having to create every web user there...
Enjoy
| sfari wrote: |
| About the big messages, i totally agree with you. It is a misconcept but the buisiness wants it even knowing that it is not a proper use of MQ. So we from the infrastructure have to enable it! |
Sorry, Tough luck 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| iceage |
| Posted: Wed Apr 12, 2006 7:14 pm Post subject: |
|
|
Acolyte
Joined: 12 Apr 2006
Posts: 68
|
Here is a long shot , if you are still looking for answers ...
Check whether have you turned on any debugging statements in your program ?
If so , i suspect your exit is printing out the contents of your message everytime .... hence bigger the message , worse the performance .. |
|
| Back to top |
|
|
|
|
