| Author |
Message
|
| KIT_INC |
 Posted: Wed Nov 12, 2014 9:46 am Post subject: JMSInput for durable subscription |
 |
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
We are running WMB 7 on Linux
We have developed a Pub/Sub application using JMSInput node to subscribe. We already have a sample working with no problem. We have a couple of question that need your opinions.
1. The JMSInput node is subscribing to a topic and we are doing durable subscription. Does it mean that a subscription will be done every time the message flow runs. If message flow is kick off 5 time/sec , there will be 5 subscriptions to the topic per second. We know that MQ pub/sub is smart to know that it is the same subscription because we only see one subscription during our testing. But is this efficient ? If not what should be the alternative ?
2. We are doing durable subscription and persistent messages, we noticed a queue called SYSTEM.MANAGED.DURABLE.5436720F20007E03 created for the message flow to pick up the publication. if this is a durable subscription, I expect this Q to stay as long as the subscription is there. The subscription has expiry unlimited. But during our tests in last month, we noticed that the Q has changed (i.e. the last string of number is different). Unless my expectation is wrong, can some one help on this ? |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Nov 12, 2014 10:03 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Why are you using JMS to receive messages from a queue manager?
You can create an administrative subscription that points to a queue and then use an MQInput. |
|
| Back to top |
|
|
| KIT_INC |
| Posted: Wed Nov 12, 2014 10:09 am Post subject: |
|
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
Unfortunately message flow are developed by 3rd party. We just want to make sure that it works and works efficiently.
We are just using JMSInput node to subscribe. Publications put out to SYSTEM.MANAGED.DURABLE.5436720F20007E03 are picked up by another flow probably using MQInput node. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Nov 12, 2014 10:31 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Why would you run the flow 5 times a second?
Is the "client identifier" identical each time?
Seems unnecessary when an admin sub to a permanent queue is so much better (and safer).
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| KIT_INC |
| Posted: Wed Nov 12, 2014 10:51 am Post subject: |
|
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
| Quote: |
| Why would you run the flow 5 times a second? |
This is just a sample test. But A JMSInput node when using as an inout node to receive JMS messages , it can receive a lot more than 5 message /sec.
You may want to ask why IBM allow us to use JMSInput node for subscription. If that is not the case, we would just do a static subscription once and be done with it.
Since the flow is developed by 3rd party and they have not done anything unsupported, we have to accept it unless we have a good reason to reject (even not the best practice can be a good enough reason). That's why I need your help. |
|
| Back to top |
|
|
| KIT_INC |
| Posted: Wed Nov 12, 2014 11:04 am Post subject: |
|
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
| Quote: |
| Why would you run the flow 5 times a second? |
Just one more point on this, the flow was actually driven by a timer which can have a very long interval or a short interval. If the interval is 1 sec, than the subscription is done once a second. 5 times a second is a little exaggerated. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Nov 12, 2014 11:19 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The JMSInput node isn't going to recreate it's subscription every time it goes to read a message. Nor do I believe it creates one subscription for each instance of the flow/instance in the node pool.
Otherwise, the JMSInput node is going to act like any other JMS Subscriber, when it comes to the objects it uses on the queue manager. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Nov 12, 2014 12:22 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Surely a subscription would normally be kept open and messages received as they are published?
There is no need for a timer design with MQ, if messages are directed to a queue then the MQinput node will start the flow immediately a message arrives without any need to poll (which wastes resources).
It's possible to construct appalling designs using "supported" functions in MQ or broker.
Keep it simple, event driven (not timer driven), transactional and MQ based and you won't go wrong.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
|
|
