Hi Juan, your attachment didn't get to the list. Maybe you should put it at some remote storage that hat the http access.
and how is your client configured? can you make sure that you configured the decoupled endpoint and persistence at the client? regards, aki 2013/5/31 Juan Alberto Lopez Cavallotti <[email protected]> > Hi Aki, > > Thank you for your reponse. > > Yes, I have a decoupled endpoint, I have a standalone client based on > cxf's sample projects (nothing fancy added) which is currently working > fine, I'm killing it randomly so I can handle that kind of outages I'm > aware that you also have a custom interceptor for generating communication > errors. > > My problem context is the following: > > I have exposed a service through Mule ESB facilities (I'm currently trying > to fix a bug in Mule's code) which exposes a service as described on this > section on the doc > http://www.mulesoft.org/documentation/display/current/Building+Web+Services+with+CXF#BuildingWebServiceswithCXF-CreatingaJAX-WSService > . > > Also I have enabled WS-RM on the server via spring configuration file as I > showed before, so in this case Mule is responsible for building and > exposing the server endpoint though HTTP. This facility is powered by our > UniversalConduit (source code link is on the previous comment). > > I also have to note that when is no outage on either the client or the > server side, everything is works perfectly. Server receives the requests > through its endpoint and answers to the client through the decoupled > endpoint. > > Now the problem is: > When there is an outage on the backchannel (I.E client dies) then the > message is put in a retransmission queue (which is actually a good thing) > but for some reason the redelivery queue isn't able to even attempt to > resend the retries and also never gives up. > > Please find attached an execution log in debug level so you get the sense > of what is going on. The last log sentences would repeat at-infinitum until > I kill the server. > > Now, I know there is a bug on our conduit (or any other part of our code) > so I'm trying to understand why I'm having this behavior and hopefully be > able to fix it. > > Please let me know if you need more detailed information. > > About upgrading the version, currently it is not so easy. We have upgraded > to 2.5.9 for our latest release so maybe upgrading to 2.5.10 could be an > option but for future releases. > > Thanks for your help, > > Regards, > Juan > > > > On Fri, May 31, 2013 at 6:00 AM, Aki Yoshida <[email protected]> wrote: > >> Hi Juan, >> I have a couple of questions. >> >> You mention of the backchannel, that means you have configured a decoupled >> endpoint where the server can asynchronously deliver ack messages to? I >> didn't see it at least in your beans.xml file. And you have a >> request-response service right? That means there are application messages >> going in both directions. >> >> And when you say no retry is happening back to the client after restart, >> have you enabled the persistence? If the client didn't persist the >> sequence, it cannot handle the messages sent back on that sequence. I >> didn't see the persistence enabled in your beans.xml. So it's not clear to >> me if that is your entire configuration or you are adding additional stuff >> programatically. >> >> So I still don't know if this is some inconsistent configuration or a >> known >> bug or a new bug/limitation. >> >> regards, aki >> p.s. In 2.6.x, there is an option to set the maximum number of >> retransmission and there is also a way to terminate a message or a >> sequence >> permanently from the persistence over JMX. 2.5.1 is really old. Do you >> need >> to stick to it or can you at least get to a more recent 2.5.10 or to >> 2.6.8? >> >> >> >> 2013/5/29 Juan Alberto Lopez Cavallotti <[email protected]> >> >> > Hi Aki, >> > >> > Thanks for getting back to me, if you wish to see the implementation of >> the >> > conduit, here is a github link for it: >> > >> > >> > >> https://github.com/mulesoft/mule/blob/mule-3.3.2/modules/cxf/src/main/java/org/mule/module/cxf/transport/MuleUniversalConduit.java >> > >> > What I'm trying to do is to make this conduit to handle outages on the >> > backchannel correctly. The CXF version we're using is 2.5.1. The >> scenario >> > is the following: >> > >> > I have WS-RM working, on the happy path: >> > >> > - Client creates a sequence. >> > - Server acknowledges on the backchannel. >> > - Client sends the request. >> > - Server answers on the backchannel. >> > - Client acknowledges the answer. >> > >> > What is happening here is that when I have some outage on the client. >> For >> > example client dies suddenly. The message gets in the redelivery queue >> and >> > it gets stuck forever logging constantly that message. >> > >> > I would like to understand how I can make the redelivery queue to give >> up >> > after a certain amount of retries but I believe currently is not being >> able >> > to retry so, I would like to understand the reason why. >> > >> > Regards, >> > Juan >> > >> > >> > On Wed, May 29, 2013 at 2:50 PM, Aki Yoshida <[email protected]> wrote: >> > >> > > I suppose you are seeing this warning because you have configured no >> > > separate channel (i.e.d, decoupled endpoint) for acks or response >> > delivery. >> > > So when the http response connection is gone, you will get some kind >> of >> > > stuck message until at least the next message comes in. >> > > >> > > Can't say anything about the line 101 if we don't know the cxf >> version. >> > > >> > > In any case, if you don't (or can't configure a decoupled ep because >> of >> > > your firewall rules), you should stick to oneway calls and >> > > setting AcknowledgementInterval to 0 so that you get your request >> ack'ed >> > in >> > > its response. >> > > >> > > If you have further questions, please describe your scenario in more >> > > details (version, req/resp or oneway, etc). And i don't know what your >> > > conduit is doing. So it's really hard what to say based on the info >> you >> > > provided so far. >> > > >> > > >> > > >> > > 2013/5/29 Juan Alberto Lopez Cavallotti <[email protected] >> > >> > > >> > > > Hello, >> > > > >> > > > >> > > > I have a custom conduit implementation which takes care of the >> > > integration >> > > > of CXF and MuleESB. I am able to use the WS-RM functionality on the >> > happy >> > > > path over this conduit but when something goes wrong on the >> > backchannel I >> > > > get the message stuck on the redelivery queue and constantly >> printing >> > the >> > > > following log statement: >> > > > >> > > > WARN 2013-05-27 16:57:33,917 [RMManager-Timer-2051976295] >> > > org.apache.cxf.endpoint.DeferredConduitSelector: >> > > > MessageObserver not found This is actually happening on line: 101 of >> > the >> > > > class org.apache.cxf.endpoint.AbstractConduitSelector >> > > > >> > > > I would like to diagnose the cause of this situation. >> > > > >> > > > Please find attached my configuration file. >> > > > >> > > > Thanks for your help in advance. >> > > > >> > > > Regards, >> > > > Juan Alberto López Cavallotti >> > > > >> > > >> > >> > >
