-
45. Re: How to use exceptions
"haagenhasle" wrote:
Do you have any comments to how I can solve the case I have with a non-idempotent back-end WebService?
The only transports that we currently support that could help out-of-the-box are JMS and DB, because you can do the delivery/work within the scope of the same transaction.
For what you need, why not look at using the WS-A header information in the ESB, which is pretty much what it's there for: set the MessageID; set the RelatesTo (if necessary). Have your backend service remember what messages it has processed. The ESB infrastructure will do more along these lines (including retained results) eventually. -
46. Re: How to use exceptions
"mark.little@jboss.com" wrote:
The only transports that we currently support that could help out-of-the-box are JMS and DB, because you can do the delivery/work within the scope of the same transaction.
For what you need, why not look at using the WS-A header information in the ESB, which is pretty much what it's there for: set the MessageID; set the RelatesTo (if necessary). Have your backend service remember what messages it has processed. The ESB infrastructure will do more along these lines (including retained results) eventually.
I'm only using JMS (so far), so that's good. I'll take a look at the transaction-support and the WS-A stuff. (The last time I updated from the CP-branch it seemed like a lot of transaction related code had been added?)
I'm not really in a position to have my backend services do anything new, I'm afraid they're not easy to change..
How does the transactions interact with the redelivery-mechanism? If a sync call times out, does that make the transaction roll back? And if the transaction is rolled back, will the message still be redelivered?
Regards, Haagen -
47. Re: How to use exceptions
If you're using JMS transacted sessions then the message will only go on to the queue if the transaction commits. Likewise, the message will only be removed from the queue if the receipt transaction commits, which could be controlled by your service.
-
48. Re: How to use exceptions
"mark.little@jboss.com" wrote:
If you're using JMS transacted sessions then the message will only go on to the queue if the transaction commits. Likewise, the message will only be removed from the queue if the receipt transaction commits, which could be controlled by your service.
Hm... could you elaborate on that a little bit?
- if the transaction commits, the message will be both put on the queue and removed from the queue? So all JMS-related operations will happen as an atomic operation if the transaction commits, and if it rolls back they won't happen?
- But how does this relate to the redelivery? As far as I've understood, it is somewhere in the ServiceInvoker that the redelivery happens (can you confirm this?), so it is "outside" of the JMS-action?
- What if I use a chain of services, can they still be part of the same transaction?
- I use the ServiceInvoker from a WebService-implementation to call into the ESB. From within one of the actions in the Service I'm calling, I use another ServiceInvoker to call a new Service (one of two possible Services, depending on the user input.) Is this use of the ServiceInvoker compatible with the transacted sessions?
Are there any quickstarts or documentation that describes the transaction handling in more detail?
Regards, Haagen -
49. Re: How to use exceptions
How much about JMS, transacted sessions and transactions do you know ;-)?
-
50. Re: How to use exceptions
"mark.little@jboss.com" wrote:
How much about JMS, transacted sessions and transactions do you know ;-)?
If my questions revealed that there is something I obviously don't know, then please enlighten me! :-) I don't know much about how transactions are supported and used in JBoss ESB, where they begin (or do I control that, and the ESB supports the transaction I begun?) etc..
Regards, Haagen -
51. Re: How to use exceptions
The following code in ServiceInvoker.post makes sure that every message gets delivered at least twice, in case of a timeout.
while (staleEPRCache) {
The funny thing about this is that when I call SI.deliverSync(msg, XX), I expect the SI to return to me after XX milliseconds. But that's not really the case. The first call times out after XX milliseconds, but then the SI tries again (at least once, perhaps several times in case of a clustered system), so the client has to wait XX x2 milliseconds (or more).
During my debugging of this, I've also observered the redelivery-mechanism kick in, although this is a synchronous call. That is clearly a bug, so I guess I should report it somewhere. (But it might have been resolved already, I haven't tried to confirm it with code from the CP-branch.)
I don't really understand the all-or-nothing approach you have chosen either when it comes to determining if the message was delivered or not. The ESB-framework handles the message in between every service and every action in the services. If anything happens in an action that makes the call time-out, the ESB-framework should be able to determine how far in the process/action-chain the message has traveled. Between every action the ESB could log the state of the message, so that it knows when the timeout occurs. Then it could throw a timeout-exception or something, so that the public void processException(final Message message, final Throwable th)-method of every action that has been executed so far can get a chance to clean up.
Just thinking out loud.. :)
Regards, Haagen -
52. Re: How to use exceptions
Make sure you are using 4.2.1CP1 for a start. Sorry can't be more help at the moment, but some of the team are at JBoss World this week.
-
53. Re: How to use exceptions
If this is still an issue, I'll get back to it when I return from JBW as well. Or maybe even if I get a chance en route home.
-
54. Re: How to use exceptions
As previously mentioned, I'm having trouble getting the CP1-code to work. I'm getting exceptions I don't know how to handle.
Have you changed anything (from 4.2.1.GA) that I should know about, the version of JBoss AS, Messaging or something else? Or are there anything I need to deploy or configure to make it work?
Regards, Haagen -
55. Re: How to use exceptions
This thread has gotten way too long. There have been many changes with routing and delivery between 4.2.1 and 4.2.1CP1. Why not create a new topic around the issues you have found with getting 4.2.1CP to build and we can go from there?
-
56. Re: How to use exceptions
Sure, I can do that, I'll start a new thread about CP1. But I've looked at the ServiceInvoker-code from CP1, and it hasn't changed dramatically. All the issues I'm facing are still there, as far as I can tell. So if any of you guys have any thoughts regarding my "thinking out loud" earlier in this thread, that would be much appreciated.
And then we can discuss CP1 in another thread. :)
Regards, Haagen -
57. Re: How to use exceptions
I just wanted to comment a little bit further on a previous post I made in this thread, where I discussed the attemptDelivery-method in the ServiceInvoker.
The thing is, that the way it is now, an async call is considered delivered as long as it, in the case of the JMSCourier, has been put on the JMS queue. The SericeInvoker doesn't know anything about what happens with the message after that, it doesn't care. So why is it so different for sync calls? Why does the ServiceInvoker have to wait until the message has been returned so say that it has been successfully delivered? It really isn't the same thing..
Regards, Haagen -
58. Re: How to use exceptions
We care about:
- not loosing a message
- not delivering a message more then once.
So:
1. You are right that for async calls the SI cares about delivering the message to the queue, or the file system or ftp server. If the message is on the queue, the SI's job is over. JMS will take it from there. Your service will need to take it off the queue, and it will keep the message on the queue until you commit that transaction (so in case of a exception/rollback, the message maybe 'delivered' again.
2. What if the JMS provider is down at the moment the SI wants to drop a msg on it? In this case (and if not other active EPRs can be found for this service), the SI will send the message to the RDLVR store for delivery at a later time (when JMS is up hopefully) See also the bottom of
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossESBStatelessServiceClustering
Note that this mechanism only kicks in for async delivery and that you can turn it off if you don't want it (set org.jboss.soa.esb.dls.redeliver to false, in the jjbossesb-properties.xml)
OK I think so far you're with me right?
3. Now what to do for sync delivery? The only way the SI knows that the message IS somewhere, is when the actual destination replies with an ACK! Only then the SI can know that it's ok to move on. This is why sync calls can cause bottlenecks in your system.
Hopefully we can get this thread to a closure :).
--Kurt -
59. Re: How to use exceptions
Thank you Kurt, for taking the time to reply to my post! I'd like to close up this threas as well :), but I need to point out that the behaviour the ESB is showing now, doesn't match the two goals you wrote down.
Do I understand you correctly if I say that transactions can do the job of "taking care" of the message after it has been put on the JMS queue, so that the SI should only have to worry about putting the message on the queue? Cause I can totally agree with that. That's how I'd like it to bee for sync calls as well as async calls.
My point in this thread is that for sync calls, the SI can easily deliver a message more then once. In fact, if the call times out, it will. Each and every time, and there is nothing I can do about that. It is the failover-functionality that does this, so configuring the org.jboss.soa.esb.dls.redeliver won't help. I've pasted in the code where this happens earlier in this thread.
A sync call consists of two phases, the delivery and the pickup. I would like the SI to mark the message as delivered if the delivery is successful, not if the pickup is successful. If the delivery is successful, the SI shouldn't try to send the message again, cause after that taking care of the message should be the responsibility of a transaction. (So no, I don't agree with you that the only way for the SI to know that the message is somewhere, is to wait for it to come back. If the delivery returns an ack, the SI know that the message is somewhere. It might not know *where* it is, but that is not the same thing.)
So what if the message is delivered but then times out? Well, I would suggest that the ESB turns this into an exception for sync calls, a timeout-exception. Perhaps it would be possible to make this exception occur in the message, so that a transaction would be rolled back, and/or the exception-methods of each action that has been visited so far will be called. Then I can clean up after myself.
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.
Regards, Haagen