CAA-WS behavior for connection failures

[Paul Glezen]

I have an outbound node with protocol set to java/ws-client.  The Inbound Data tab is set to Outbound Only.  I’m attempting to account for the ways a web service request can fail and handle them accordingly.  At the moment I’m working on connection failures (the web service provider returns connection refused).  When the Apache CXF layer receives the ConnectionException from the socket layer, it bubbles up to the TPS layer and invokes my Tcl proc registered in Send Fail Procs.  At the moment I simply log the occurrence.

From inspecting the logs, I see the request is retried over the appropriate interval as specified in the Retries and Interval.  Finally the request message is tossed into the error DB.

I was hoping that I could have the message tossed into the recovery DB instead of the error DB.  That way, when the web service provider eventually starts the web service, the messages could flow once more.  Is there a message disposition that would cause this?  Or perhaps a preferred alternative?

I considered setting the disposition to PROTO which, according the documentation, sends the message to the “head of the Outbound Post-TPS Queue.”  But I’m afraid if I try that, it will result in an infinite loop and crash the site rather than simply place it in recovery.

Topic

[Paul Glezen]

After some experimenting, reading, and contemplation, I think I’ve been able to answer my original post.  My desire to have the connections ultimately end up in the recovery DB instead of the error DB was a result of my misunderstanding of how things generally work in Cloverleaf.  I thought I knew of other cases (with raw TCP) where connection failures resulted in the message always being re-queued into the recovery DB.  But upon closer inspection of those configurations, the retry count was set to -1.  Reaching the retry count is what sends the message to the error DB.  With no retry limit, no error DB (at least not for connection timeouts).  I’m not sure unlimited retries is the best practice.  But at least I understand why the TCP cases behaved that way at my location and that its behavior is consistent with the CAA-WS case.

I still wonder about other ways a web service can fail.  For example, the request could reach the server, but the server returns a fault or a 500 return code for some other reason.  In the reply TPS, I could send the reply payload to the error DB.  But I wouldn’t be able to correlate it with the original request (ostensibly still sitting in my SMAT DB).

Or would I?

Would the inbound reply message metadata contain any clues by which I could correlate it to the original request message sitting in the SMAT DB?

[Jim Kosloskey]

The msgId in the metadata should be the same in the SMAT I think.

You might want to take a more pro-active approach and in your reply handling have something to notify on-call of the issue or something like that. You could even have different actions dependent on the error returned if that is warranted. One of the options would be to send to the DB but you should be able to add USERDATA with maybe some information about the message which engendered the response.

Just some thoughts…

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Author]

Replies