[kconner]

"haagenhasle" wrote:
That's how I'd like it to bee for sync calls as well as async calls.

Unfortunately this is not possible if you are using JMS. The outgoing message will not be visible until after the transaction has committed so there will never be any response. This could also hold with other resources depending on how they handle their transaction isolation.

"haagenhasle" wrote:
I don't claim to have the Solution(TM), I'm sure you guys can come up with something better. But I would very much like us to be able to agree on the fact that for sync calls, a message can be resent be the SI, and that is something we don't want.

At the moment it is a deliberate decision to attempt a resend of the message. We can certainly add an option to raise an exception and allow the application code to handle this if that is what you are suggesting.

As for a solution, our suggestion would be to try and use asynchronous messaging as much as possible and allow other services to continue the work you have started in this one.

Could we start another forum posting around this? Start from what you are trying to achieve and see if we can suggest something? I apologise if you have already covered this in the current posting but it is long and I have not followed most of it.

Kev

[haagenhasle]

"haagenhasle" wrote:

At the moment it is a deliberate decision to attempt a resend of the message. We can certainly add an option to raise an exception and allow the application code to handle this if that is what you are suggesting.

Kev

Yes, that is what I'm suggesting! I would like the ServiceInvoker (or courier, I don't know) to throw a (Courier)TimeoutException, and also cause the ActionProcessingPipeline.notifyException to be called. I'm not sure how this could be done, do you have some sort of context or session that can be used? The ActionProcessingPipeline can check to see if a timeout has occured between each step of processor.process(currentMessage) in the public boolean process(final Message message)-method.

I think I need this, as I have non-idempotent backend-services that I really don't want to risk calling twice. And they don't support transactions either. (Of course, I need the backend services to have a way of reversing an operation, for my idea to work. In most cases I have that, I can call a new operation to undo the one I want reversed.)

I'm sorry I didn't create a new thread this time either. I thought it might be nice to see the history behind my request in this post..

Regards, Haagen

PS. I might have to hack this into the code myself. So I'd be happy if you have any thoughts on how it could be implemented the best way. Does a context/session/singleton-kind of construct exist in the ESB-code?

[haagenhasle]

I'm sorry, I messed up the quote in my last post.

[kconner]

"haagenhasle" wrote:
Yes, that is what I'm suggesting! I would like the ServiceInvoker (or courier, I don't know) to throw a (Courier)TimeoutException, and also cause the ActionProcessingPipeline.notifyException to be called. I'm not sure how this could be done, do you have some sort of context or session that can be used? The ActionProcessingPipeline can check to see if a timeout has occured between each step of processor.process(currentMessage) in the public boolean process(final Message message)-method.

Whether the pipeline sees this or not will depend on the action being executed. The action would have to allow it to propagate out for the pipeline to catch it.

The pipeline would not treat this differently from any other exception.

"haagenhasle" wrote:
I think I need this, as I have non-idempotent backend-services that I really don't want to risk calling twice. And they don't support transactions either. (Of course, I need the backend services to have a way of reversing an operation, for my idea to work. In most cases I have that, I can call a new operation to undo the one I want reversed.)

Unfortunately this may not solve your issue. If the timeout does occur then you will not know whether the original message has been received by the service or not.

I have created a JIRA to track this http://jira.jboss.com/jira/browse/JBESB-1556

[haagenhasle]

That might be true, but I'll be able to know that all the previously invoked actions in my Service can be undone. At least that's something.. :-)

Regards, Haagen