On Thu January 14 2010 7:30:26 am Pallinger Péter wrote: > Thank you for your fast answer! > > On Wed, 13 Jan 2010 15:56:40 -0500 > > Daniel Kulp <[email protected]> wrote: > > 1) OneWayProcessorInterceptor stuff - not needed. Thats for the the > > server side stuff only. > > Ok, I removed those two interceptors. There was no change in the error, > however. > > > 2) Does the registration method on the IEventService interface have > > the proper @OneWay annotation on it? If not, it wouldn't be > > considered a one way at all. > > It has a @Oneway annotation, using @OneWay generates a compile-time > error (cannot find symbol).
My bad. @Oneway. > > 3) Even with a one way, per spec, we have to wait till the server > > sends back the 200 or 202 response. If the server is not sending > > that back immediately upon receipt of the message, that's a bug on > > the servers side. > > It does not answer anything, I can see that with tcpdump. Is there a > workaround for that, or there is nothing to do to handle .NET's > misbehaviour? That would definitely be a bug on the .NET side. :-( > Does anyone have experience in integrating with one-way MS web > services? Or MS web services in general? > > By the way, I am using cxf 2.2.5. > > Thanks for your answer in advance! Hmm...... Hmmm...... I'm not really sure. :-( The only thing I can think to do is to write an interceptor that would live very late in the interceptor chain that would pause the current chain and push it onto a background thread where it would resume to do the final "send and wait for the response code" thing. You can use the code for the OneWayProcessorInterceptor stuff as a starting point as that's pretty much exactly what it does with one ways on the server side. To get the 200 back ASAP, once we know the incoming message is for a oneway call, we push the actual invoke onto a background thread so the HTTP request thread can return immediately and send back the 200. That's something the .NET server is obviously not doing. -- Daniel Kulp [email protected] http://www.dankulp.com/blog
