Quaranteed delivery from queue to DB in service

Marko,

which Sonic verison are you using? if 7.6 then you can use the service life cycle interface and put the service into a stopped state while the db is unavailable. Once the db connection is up again you can start it. This will achieve what you need, e.g. messages queuing.

Thomas

Thanks Thomas

I am using 7.6.2.

This solution is option, but I'd like to get closer to perfect solution

How could I avoid losing 1..N messages which are dequeued atuomatically when service() is invoked?

Since connection losses are rare and short I'd prefer not to stop service but try again after while.

Seems that these requirements force using a

- loopback enqueing through ESB process  of dequeued messages

or 

- creating JMS connection to Entry queue  sending messages back in service() after a little delay()

Marko

Marko,

your solution will also work, but I guess we can also agree on disagreeing. E.g. I would argue that using the stop/abort of a service instance is favourable because you will not

• loose message order
• you don't have to manually maintain this "loop"
• you don't have to artificially introduce a wait state (e.g. you don't want to resubmit from the fault/rme to the entry ep immediately).

With the life cycle manager calls in place you can still retry after a while and just start the service again once the db is up.

My 2 cents

Thomas

Ok, I'am convinced 

I'll stop service.

Last question.

If I understand correctly, then I still loose a message.

Message witch invoked service() method and caused jdbc exception.

Or is the message kept in queue  when I execute stop() in the middle of service().

Marko

To not "loose" a message (read as go to RME) you need to catch the exception and must leave the service() method gracefully.

You still need to decide if you want to use stop or abort. From the docs:

• Stop the service — Stopping the service             terminates all of the service's listener threads and closes             the underlying JMS consumer. The listener threads that are             processing messages when the stop was called, wait until the             service() method returns. An attempt is made to             deliver all outstanding messages in the service's             outbox/faultbox/Reject endpoint and acknowledge the incoming             message. If the underlying JMS session is closed, message             delivery to the outbox/faultbox/Reject endpoint may fail. If  the             QoS is at least once, the incoming message             is not acknowledged and the system tries to redeliver the  message when the             service is started again. If QoS is exactly once,             the incoming transaction is not committed and the system  tries to                redeliver the message when the service is started again. Once a  service             shuts down successfully, it does not consume any further  messages             from its entry endpoint until the container is restarted or  the             service starts itself. If another service that is yet to be             stopped calls a stopped service using intra-container  messaging,             the message is delivered to the stopped service.
• Abort the service — Aborting the service             terminates the service's listener threads and closes the             underlying JMS consumer. The listener threads that are  processing             messages when the abort was called wait until the             service() method returns. All messages in the             outbox, faultbox, or Rejected message endpoint as a result  of the             service execution are not delivered, and the incoming  message is             not acknowledged. Once a service shuts down successfully it  does             not consume any further messages from its entry endpoint  until             the container is restarted. If another service that is yet  to be             aborted calls an aborted service using intra-container  messaging,             the aborted service does not process such requests. Aborting  a             service uses the same state transitions as that of a service             stop. The only difference is that in the case of abort a special             flag is set in the Service Lifecycle Manager, so that it is             possible to distinguish between a stop and an abort. You can also check                whether a service is aborting by calling the isServiceAborting() method.

Thank you Thomas.

This solution is perfect. I'll use abort.

Marko