| Author |
Message
|
| amigupta1978 |
 Posted: Thu Mar 28, 2002 3:02 pm Post subject: |
 |
|
Centurion
Joined: 22 Jan 2002
Posts: 132
Location: India
|
Hi
I have a query about MQSI pub-sub. Like we can implement durable subscriber in JMS ( i mean publisher will publish the message to subscriber even if say subscriber is down at that time ), is this possible in MQSI.
I tried with a sample flow with MQSI publishing to a particualr TOPIC and a subscriber listening to that queue and evrything worked fine.
I then make the subscriber queue put inhibit (or say due to some error the message was not able to put into the subscriber queue), then in that case the message which MQSI broker will publish will get lost from that subscriber. Can in MQSI in any way we can implement the durable subscriber thing such that when the subscriber is down then after it comes up the Message is put on the subscriber queue.
Thnx
Amit |
|
| Back to top |
|
 |
| kolban |
| Posted: Thu Mar 28, 2002 4:20 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
In WMQI (and MQSeries) the concept of publish and subscribe is that a subscriber names a queue and a topic. When an application publishes a message with a given topic, the message is copied to each queue that has a matching subscription. What this means is that the message will remain on the queue until the subscriber succesfully retrieves it or until the message expires.
In JMS, when the talk about durable and non-durable subscriptions, they basically talk about the life time of the subscription. In JMS, a subscription for a non-durable subscriber is removed when the client application terminates. For a durable subscriber, the subscription persists until told explicitly to be removed. So ... in WMQI, all subscriptions are, by default, durable. If a client application is not running, then the message will be kept until the application retrieves it at a later time.
Your scenario is not an example of durable vs non-durable. It is an example of a broken/poorly configured system vs a working one. Disabling a queue or filling a queue is not the same as an application consuming from that queue terminating. |
|
| Back to top |
|
|
| amigupta1978 |
| Posted: Thu Mar 28, 2002 4:58 pm Post subject: |
|
|
Centurion
Joined: 22 Jan 2002
Posts: 132
Location: India
|
Hi
Thnx Kolban for the reply,
Actually I have posted a similar question again, the real problem is for me is that I have some TOPICs to publish and 3 subscribers listening. All my messages are quite critical which I cant afford to loose. So while in Testing I some how faced this problem that message was unable to put on one of the subscriber queue due to some system error "MQcode 2102 :MQRC_RESOURCE_PROBLEM ", so we had to restart the broker and the Queuemanager. But the problem is that particular message got lost (I mean it was not able to put on the queue).
Can you please suggest some way such that we can work around this problem.
Since I can't afford to loose any message (whatever may be the reason).
The only solution currently I am able to think is to get away with Pub-Sub and use the destination List structure (since it will make full thing under one transaction, such that if the error happens, message will be backed out), but this doen't seems to be quite a good idea.
Thnx
Amit
|
|
| Back to top |
|
|
| kolban |
| Posted: Thu Mar 28, 2002 9:12 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
The most likely cause of the problems are insufficient disk space for the logs or for the files holding the queues. Next time you see this error, quickly look at the disks.
I am assuming you are running on unix so use the "df" command.
You may also want to ensure that your unix kernel parameters are set correctly. This is not a functional problem but a setup-resource problem.
If you ask for durable subscriptions and attempt to publish a large enough number without running a subscriber, something would have to give ... an infinte number of messages can't be stored for retrieval. |
|
| Back to top |
|
|
| Tibor |
| Posted: Fri Mar 29, 2002 1:03 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
A subscriber security question:
How can I separate the users who are coming same username from different systems? For example: a lot of 'oracle' user, because we are using many Oracle server-side application.
|
|
| Back to top |
|
|
| abiram8 |
| Posted: Fri Apr 05, 2002 4:40 am Post subject: |
|
|
Master
Joined: 27 Mar 2002
Posts: 207
Location: India
|
Hi
Ther is one solution Its up to you to adopt you can give diifrent user name
say for Oracle1 Machine Admin1 , for Oracle2 you can give Admin2 etc.,
|
|
| Back to top |
|
|
| Tibor |
| Posted: Sun Apr 07, 2002 10:58 pm Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
| Quote: |
Ther is one solution Its up to you to adopt you can give diifrent user name
say for Oracle1 Machine Admin1 , for Oracle2 you can give Admin2 etc.,
|
OK, but we have a *lot* of applications (50+), well, so this is not the best idea... |
|
| Back to top |
|
|
| Miriam Kaestner |
| Posted: Mon Apr 08, 2002 11:47 am Post subject: |
|
|
Centurion
Joined: 26 Jun 2001
Posts: 103
Location: IBM IT Education Services, Germany
|
"The only solution currently I am able to think is to get away with Pub-Sub and use the destination List structure (since it will make full thing under one transaction, such that if the error happens, message will be backed out), but this doen't seems to be quite a good idea. "
You can actually publish in WMQI under transactional control, you the publishing message flow is a transactional one. This has the effect that either ALL publications are delivered (at least to a transmission queue for the remote system) - or none at all and a rollback occurs.
I am not sure that this is what you wanted to achieve.
The other solution for unreliable subscriber queues would be to use retained publications, and/or subscribers registering with option PubOnReqOnly. That means publications are stored in the broker DB. |
|
| Back to top |
|
|
|
|
