This content has been marked as final. Show 10 replies
I want an OSB service to act as a JMS Producer by sending messages to a consumer, say another OSB service. The consumer, upon picking up the message, should send back an acknowledgment to the OSB service (JMS explicit acknowledgment). What is the configuration required on both the sides?I'm not sure If I understood (JMS explicit acknowledgment) part of your question. Are you implying Session.CLIENT_ACKNOWLEDGE as defined below? It would be wonderful if you can detail you use-case.
In nontransacted sessions, when and how a message is acknowledged depends on the value specified as the second argument of the createQueueSession or createTopicSession method. The three possible argument values are:
* Session.AUTO_ACKNOWLEDGE. The session automatically acknowledges a client's receipt of a message either when the client has successfully returned from a call to receive or when the MessageListener it has called to process the message returns successfully. A synchronous receive in an AUTO_ACKNOWLEDGE session is the one exception to the rule that message consumption is a three-stage process. In this case, the receipt and acknowledgment take place in one step, followed by the processing of the message.
* Session.CLIENT_ACKNOWLEDGE. A client acknowledges a message by calling the message's acknowledge method. In this mode, acknowledgment takes place on the session level: Acknowledging a consumed message automatically acknowledges the receipt of all messages that have been consumed by its session. For example, if a message consumer consumes ten messages and then acknowledges the fifth message delivered, all ten messages are acknowledged.
* Session.DUPS_OK_ACKNOWLEDGE. This option instructs the session to lazily acknowledge the delivery of messages. This is likely to result in the delivery of some duplicate messages if the JMS provider fails, so it should be used only by consumers that can tolerate duplicate messages. (If it redelivers a message, the JMS provider must set the value of the JMSRedelivered message header to true.) This option can reduce session overhead by minimizing the work the session does to prevent duplicates.
OSB JMS proxy will not allow explicit control to set above modes. OSB proxies always work in AUTO_ACKNOWLEDGE mode
Edited by: mneelapu on May 18, 2009 4:17 PM
Edited by: mneelapu on May 19, 2009 3:59 PM
Edited by: mneelapu on May 19, 2009 4:00 PM
I have this scenario: I have a JMS message which has a redelivery limit of 3, redelivery delay of 30 seconds; the JMS message is processed by a Proxy Service, and if any external system invoked by the Proxy Service is down, the transaction is rolled back, the JMS message is NOT acknowledged and is redelivered later.
So far so good.
BUT there are case where I want to consume immediately the JMS message, and at the same time rollback the transaction; for instance if the JMS message payload fails validation - in this case we don't want to redeliver it.
Well, in OSB there doesn't seem to be a way to rollback the transaction and at the same time acknowledge (consume) the JMS message so that it doesn't get redelivered...
Am I missing something, or really I have no leeway to handle the JMS message independently from the transaction?
Use a reply action within the stage error handler where your validation step is..
Is your use case is for gracefully handling poison messages? If yes a simple solution would be to publish the message to a dead letter queue from the stage error handler and do a reply action. This will remove the message from source jms queue, while you get the message in the dead letter queue for alerting..
that's exactly the case, Atheek.... my issue is that I don't want to COMMIT (reply with success) the transaction, because then the error would not show up at monitoring level....
I have been looking into using the Oracle JCA JMS Adapter, because I have noticed that JmsAdapter, instance "eis/wls/Queue", you can also set the AcknowledgeMode (default AUTO_ACKNOWLEDGE).... so I thought of setting it to "CLIENT_ACKNOWLEDGE", and explicitly acknowledge the message independently of the Transaction outcome (commit/rollback).... but OSB doesn't support JMS in the JCA adapter...
sure, you are right, what makes the difference is not "reply with success/error" but issuing a "raise error"....
"raise error" will send back the JMS message to the Queue for redelivery, while "reply with error" doesn't affect the JMS message, which is simply consumed.
Anyway my problem is that I need to commit the transaction in order to consume the JMS message... I would rather fail the transaction (raise error) AND consume the JMS message.
thanks Atheek for your support.
I am using redelivery limit/redelivery delay, to avoid having the poison message being redelivered forever; and I use Error Destination, so that we park all undeliverable messages to an error destination, and we can replay them later once the system has been restored...
this only for "retryable errors" .
My problem is with "non-retryable errors".... I would like to consume the JMS immediately, no redelivery.... and I can only doing it by committing the transaction.... which is simply bothering me, why should I commit the transaction if I have an error....
I would rather "raise error" in all cases, and
- in case of "retryable error" I will not acknowledge the JMS message,
- in case of "non retryable error" I will acknowledge the JMS message so that it's not redelivered
Unfortunately in OSB there is not a "CLIENT_ACKNOWLEDGE" mode, nor a way to explicitly acknowledge a JMS message... not as far as I know, at least. Maybe I am just stupid... ok, remove the "maybe"...