2012/4/23 Daniel Kulp <[email protected]>: > On Monday, April 23, 2012 10:50:05 PM Aki Yoshida wrote: >> 2012/4/23 Daniel Kulp <[email protected]>: >> > This is "proper" behavior as per spec. In a one way, the client just >> > knows that the message was posted, that's it. As an example, if using >> > JMS, the client just posts the message to the queue and returns. There >> > is absolutely no way to get any information about whether the request >> > was able to be parsed or processed back from the server. >> > >> > In 2.6.0, Aki did add a "robust in-only" mode (set the >> > "org.apache.cxf.oneway.robust" property on the endpoint to true) which >> > would allow returning faults to the client. This is against spec and >> > transports like JMS I don't think can handle it (not really sure, >> > Aki?), but but it may work for you. >> >> A good question. I don't know. Is the JMS endpoint using the fault >> observer? If it uses the fault observer, it could react to this >> situation. > > Well, I assume there is a fault observer on the server side, the issue is on > the client side. For a one way, the client would send the message to the > JMS queue and then continue on it's merry way. There wouldn't be anything > setup to listen for a fault. Honestly, I'm not really sure what would be a > proper thing to do in this case. If the client treats the "robust oneway" > calls as a two way and sets up a listener, then the server would have to > send back a response of some sort. I guess a "jms fake 202" could be sent > or something. But it's really getting into proprietary things at this > point. I guess I should go back to the SOAP/JMS spec and see if it > addresses the WSDL 2 robust cases at all.
Hi Dan, I think the robust property makes sense for the server side but not for the client side. The problem of the HTTP transport with oneway is that the client doesn't know if the message reaches the target service and that no component is taking the responsibility of making the service receiving the message behind that oneway asynchronous boundary. In the robust mode, the HTTP client will not get an HTTP 202 response if something goes wrong at the server side. So if it does not receive an HTTP 202 response, it can at least choose to resend the message until it receives an HTTP202 response (this resend could potentially lead to a duplicate invocation of the service but this can be filtered out if each message carries a unique identifier). In contrast, in the JMS case, the server (or the queue) is taking the responsibility of making the service receives the message once the message is placed in the queue. So, if the client can send out a message to the queue, it can assume that he doesn't need to worry about the message (or there is nothing he can do). regards, aki > >> But I am now confused with what Hervé wants. Should the soap fault be >> returned or suppressed? I thought he wanted it to be suppressed. If he >> wanted it to be returned, yes, he could use the robust property. > > I thought it WAS suppressed (and only the 202 is heading back) but he wanted > the mustunderstand fault to go back to the client. I could likely be > confused as well. > > Dan > > > >> >> regards, aki >> >> > Dan >> > >> > On Tuesday, April 17, 2012 03:55:55 PM Hervé BARRAULT wrote: >> >> Hi, >> >> I'm trying to use CXF with both WS-Addressing and One Way. >> >> >> >> My client send a message (not with CXF) with the following SOAP Header: >> >> <soapenv:Header> >> >> <wsa:Action soapenv:mustUnderstand="1"> >> >> http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify >> >> </wsa:Action> >> >> </soapenv:Header> >> >> >> >> In my logs, I had : >> >> 14:10:31,210 | WARN | ault-workqueue-2 | >> >> PhaseInterceptorChain | >> >> org.apache.cxf.common.logging.LogUtils 369 | >> >> - - | Interceptor for { >> >> http://example.com/test1}StatusBrokerService#{http://docs.oasis-open.or >> >> g/w sn/brw-2}Notifyhas thrown exception, unwinding now >> >> org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{ >> >> http://www.w3.org/2005/08/addressing}Action] are not understood. >> >> at >> >> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$Ultim >> >> ate >> >> ReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandIntercep >> >> tor. java:225) at >> >> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$Ultim >> >> ate >> >> ReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandIntercep >> >> tor. java:199) at >> >> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptor >> >> Cha in.java:243) at >> >> org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain >> >> .ja va:218) at >> >> org.apache.cxf.interceptor.OneWayProcessorInterceptor$1.run(OneWayProce >> >> sso rInterceptor.java:105) at >> >> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$2.run(AutomaticWorkQueu >> >> eIm pl.java:332) at >> >> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecut >> >> or. java:886) at >> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.j >> >> ava>> >> >> :908) at java.lang.Thread.run(Thread.java:662) >> >> >> >> And there was a classical 202/Accepted for a One Way message (fault not >> >> returned as it is one way). >> >> >> >> >> >> >> >> So, I found an interesting topics which says, enable the ws-addressing >> >> feature (to avoid this fault) : >> >> I added the feature >> >> <cxf:features> >> >> <wsa:addressing/> >> >> </cxf:features> >> >> >> >> Now when i receive a message, an answer is automatically sent (which i >> >> guess is no more compliant with the One Way): >> >> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";> >> >> <soap:Header> >> >> <MessageID xmlns="http://www.w3.org/2005/08/addressing >> >> ">urn:uuid:67074ee9-455b-4488-b48d-e2a9b16a7c1b</MessageID> >> >> <To xmlns="http://www.w3.org/2005/08/addressing";> >> >> http://www.w3.org/2005/08/addressing/anonymous</To> >> >> <ReplyTo xmlns="http://www.w3.org/2005/08/addressing";> >> >> <Address>http://www.w3.org/2005/08/addressing/none</Address> >> >> </ReplyTo> >> >> </soap:Header> >> >> <soap:Body/> >> >> </soap:Envelope> >> >> >> >> I know, i use an old version of CXF : 2.2.12-fuse-00-00 but i have not >> >> seen a related JIRA (and a post said that 2.4.0 had the same behavior). >> >> (I am using also the PAYLOAD mode) >> >> >> >> I am doing it the right way ? >> >> Is this behavior normal ? >> >> >> >> Thanks for answers >> >> Regards >> >> Hervé >> > >> > -- >> > Daniel Kulp >> > [email protected] - http://dankulp.com/blog >> > Talend Community Coder - http://coders.talend.com > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com >
