| Author |
Message
|
| jhalstead |
 Posted: Fri May 19, 2006 3:49 am Post subject: JMS, sending a message & setting the JMSTimestamp |
 |
|
Master
Joined: 16 Aug 2001
Posts: 258
Location: London
|
Just a quick one, I've got a colleague who is taking a message off a queue & putting on to another. He's using JMS to do this. The crux of his problem is that the JMSTimestamp is getting reset when the message is put. In the usual MQI world you get around this with the message context settings - however I couldn't see anything similar in the JMS docs. I see there is a setJMSTimestamp method - however by the looks of things this gets overwritten by the send method.
Can aybody confirm of deny this for my me?
I guess the alternative is to get him using the JAVA API, however this is a bit of a departure as everything else they've done uses JMS....
Thanks
Jamie |
|
| Back to top |
|
 |
| EddieA |
| Posted: Fri May 19, 2006 8:09 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
Looking in the manual:
| Quote: |
setJMSTimestamp
public void setJMSTimestamp(long timestamp) throws JMSException;
Sets the message timestamp.
Providers set this field when a message is sent. This operation can be used to change the value of a message that has been received
|
Based on the comments, I'd say it worked like MessageID. The set only affects messages you've already read, and not messages you're trying to put.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| wschutz |
| Posted: Fri May 19, 2006 8:45 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Quote: |
This operation can be used to change the value of a message that has been received
|
so why would anyone want to do that?
_________________
-wayne |
|
| Back to top |
|
|
| jhalstead |
| Posted: Fri May 19, 2006 10:00 am Post subject: |
|
|
Master
Joined: 16 Aug 2001
Posts: 258
Location: London
|
As I understand it all that the involved component is required to do is to get a message off a queue and put it to another queue. The reason for this components existence is to provide throttling functionality (i.e. configure the pool sizes in app server to control maximum throughput) the aim being to avoid backend getting mashed if a DOS attack is somehow initiated.
As I understand it an MDB is picking up the message and subsequently putting it to a queue using JMS. A fundamental requirment is that the underlying date and time stamps in the headers remain the same. However the behaviour he is experiencing is that he cannot pass the input messages timestamp on to the output message.
I hope this puts the initial question in context a little further.
Does this sound like its unachievable using JMS?
Thanks for your help and consideration so far.
Jamie |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat May 20, 2006 5:36 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It sounds like JMS is just overkill. Use the plain MQ api.
Also, I've had to do this kind of throttleing before. It was a bad idea then, and it's a bad idea now.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jhalstead |
| Posted: Sun May 21, 2006 5:37 am Post subject: |
|
|
Master
Joined: 16 Aug 2001
Posts: 258
Location: London
|
Thanks Jeff. The reason that JMS is in the mix is that all the other message based interfaces implemented as part of his work use JMS... In this context I guess it make sense for them to try and stick to JMS if they can.
I've already pointed him at the Java API. I guess the pros of JMS - open, standard based, vendor/platform neutral introduce some cons - for instnace less control over functionality provided by the underlying message transport provider.
If anybody has a flash of JMS inspiration and thinks that controlling the JMS timestamp when sending a message is possible - please do post!
Thanks Again!
Jamie |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sun May 21, 2006 5:41 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Are you really willing to introduce an extra put and an extra get into the business flow, in order to protect against a (should normally be extremely rare) DOS type of flood of messages?
Is there a queue manager that the WAS applications talk to, that is different than the backend queue manager?
If so, you may be able to tune (well, maybe detune!) your channels such that they will provide the same kinds of "slow things down" measures that you're after.
Or a channel exit could do it, definitely.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jhalstead |
| Posted: Sun May 21, 2006 7:35 am Post subject: |
|
|
Master
Joined: 16 Aug 2001
Posts: 258
Location: London
|
Thanks for all your concern about the design. I will of course pass this on to my colleague when I speak to him on Monday.
The historry as I understand it was that the client required a mechanism to limit throughput, expecially where services were exposed to web channels - obviously many precations are already in place to ensure the authorisation and authentication of any consumers.
Now this throttler (already in place) is sadly changing the date stamps on the messages - which is a problem ... hence the request to see if anyone knew how to preserve the JMSTimestamp (or set it when putting a message!).
Love the ideas about controlling throughput with WMQ config, however - with the very greatest respect - I'm not trying to give this guy new ways to do things - I'm just trying to help him fix what he's already got. (Aren't I short sighted!) |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun May 21, 2006 7:59 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
If it is just a concern about passing the information to the destination his program could use a user folder in the RFH2 to do that.
You could then compare the two values -- original one vs the one set by the move utility...
Yes it would mean changing a little bit the programing and the logic and handling the fact when the user defined property is not on the message...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| briancop |
| Posted: Mon May 22, 2006 2:10 am Post subject: |
|
|
Apprentice
Joined: 04 Apr 2005
Posts: 28
Location: Hursley, UK
|
A JMS message producer can be configured to disable message timestamping (typically to save the overhead of generating them). This is a hint to a JMS provider which it can choose to accept or ignore, but you could try it. Call MessageProducer.setDisableMessageTimestamp(true) when you create your producer and see if that changes anything. The result could be:
1) Exactly what you want - message timestamp is unchanged from whatever is already in the message
2) Message timestamp is set back to 0
3) Message timestamp is set to current time (i.e. hint is ignored)
but it is worth a try.
Other than that, I don't know of a way of preventing MQ from setting the timestamp when using JMS.
Brian |
|
| Back to top |
|
|
| jhalstead |
| Posted: Fri May 26, 2006 8:51 am Post subject: |
|
|
Master
Joined: 16 Aug 2001
Posts: 258
Location: London
|
Forgot to close the loop on this one. Sadly using the setDisableMessageTimestamp(true) approach made no discernable difference... Ayway - Java API was used, and he had to build MQRFH & assocaited JMS folders to make it look like a propper JSM message. Such is life.
Thanks for the suggestions.
Jamie |
|
| Back to top |
|
|
|
|
