HTTP transport -- no exception on server side when client has reset TCP connection
I'm posting this here rather than on the users list as it's a bit technical, and I suspect it might indicate a bug in either CXF or at a lower level. However, I'm really not sure how to simulate it in a way that would make a convenient JIRA entry. I'm happy to bundle up some example code, if someone could suggest a way to make the conditions realistic. The scenario is as follows: One of our collaborators at a remote site, using Metro, wrote a client for a JAXB-JAXWS service here that runs long jobs, but synchronously. (Not my design decision...) We were getting some weird behaviour on larger requests, where my web method was returning a value, but his client was just hanging indefinitely, waiting for the data. Eventually we tracked it down using Wireshark to a TCP RST packet coming from his end after 30mins -- or more specifically, from the proxy server all his outbound requests were going through. This was causing the TCP connection from the proxy to here to be torn down, but apparently the proxy wasn't closing the connection on the other side, so Metro thought it was still open and kept waiting. However! What worries me is that when my CXF method returned the JAXB object, no exception seems to have been raised, even though the TCP connection between me and the proxy was closed long before. (I verified this with netstat.) I couldn't see anything in the CXF or Tomcat logs that suggested anything unusual had happened. Is this normal behaviour? Cheers, Andrew. -- View this message in context: http://www.nabble.com/HTTP-transportno-exception-on-server-side-when-client-has-reset-TCP-connection-tp24182294p24182294.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: HTTP transport -- no exception on server side when client has reset TCP connection
PS I should have mentioned: JDK 1.6.0_06-b02, Tomcat/6.0.16, Centos 5.3, CXF 2.2.2 -- View this message in context: http://www.nabble.com/HTTP-transportno-exception-on-server-side-when-client-has-reset-TCP-connection-tp24182294p24183358.html Sent from the cxf-dev mailing list archive at Nabble.com.
JAX-RS benchmark application?
I was in a discussion with Chris Blythe yesterday about a common application for JAX-RS benchmarking. Geronimo has the DayTrader application that is purely Java EE 5 based and can be run on any platform. Having something similar for JAX-RS would be beneficial. Does anyone know if a similar application exists in other communities? Or, should we look at adapting the DayTrader application to support JAX-RS? -Nick Nicholas Gallardo WebSphere - REST & WebServices Development nlgal...@us.ibm.com Phone: 512-286-6258 Building: 903 / 5G-016
Re: JAX-RS benchmark application?
Just wanted to add my two cents... So, whenever we discuss "benchmarks", there are always two different directions to go... micro-level benchmarks that focus on a single component and end-2-end, full workload benchmarks that stress the interactions between multiple components. Typically, the micro-benchmarks are more useful for performance improvement work and the full end-2-end applications are better suited for relaying performance expectations for "real" applications. At this stage of the Wink project, I would lean more heavily on the micro-benchmarks because... - Focuses on specific feature and function within the JAX-RS runtime (aka. performance isn't over-shadowed by heavier components like JPA database access, etc.) - Easier to port/deploy to other implementations for comparison purposes - Easier to drive performance tests Simple function-based samples are pretty easy to use a micro-benches. Chris Christopher Blythe Software Engineer, IBM WebSphere Performance cjbly...@us.ibm.com (919) 486-2105 t/l 526-2105 From: Nicholas L Gallardo/Austin/i...@ibmus To: wink-...@incubator.apache.org Cc: dev@cxf.apache.org Date: 06/24/2009 10:26 AM Subject: JAX-RS benchmark application? I was in a discussion with Chris Blythe yesterday about a common application for JAX-RS benchmarking. Geronimo has the DayTrader application that is purely Java EE 5 based and can be run on any platform. Having something similar for JAX-RS would be beneficial. Does anyone know if a similar application exists in other communities? Or, should we look at adapting the DayTrader application to support JAX-RS? -Nick Nicholas Gallardo WebSphere - REST & WebServices Development nlgal...@us.ibm.com Phone: 512-286-6258 Building: 903 / 5G-016
Re: JAX-RS benchmark application?
Chris, I would agree that micro-benchmarks make more sense right now. So, to that end, should we just focus on having a set of simple samples that can be bundled up to accomplish this? Or would you rather see a dedicated application that examines specific paths? -N Nicholas Gallardo WebSphere - REST & WebServices Development nlgal...@us.ibm.com Phone: 512-286-6258 Building: 903 / 5G-016 Christopher J Blythe/Raleigh/IB m...@ibmusTo wink-...@incubator.apache.org 06/24/2009 09:58 cc AMdev@cxf.apache.org, wink-...@incubator.apache.org Subject Please respond to Re: JAX-RS benchmark application? d...@cxf.apache.or g Just wanted to add my two cents... So, whenever we discuss "benchmarks", there are always two different directions to go... micro-level benchmarks that focus on a single component and end-2-end, full workload benchmarks that stress the interactions between multiple components. Typically, the micro-benchmarks are more useful for performance improvement work and the full end-2-end applications are better suited for relaying performance expectations for "real" applications. At this stage of the Wink project, I would lean more heavily on the micro-benchmarks because... - Focuses on specific feature and function within the JAX-RS runtime (aka. performance isn't over-shadowed by heavier components like JPA database access, etc.) - Easier to port/deploy to other implementations for comparison purposes - Easier to drive performance tests Simple function-based samples are pretty easy to use a micro-benches. Chris Christopher Blythe Software Engineer, IBM WebSphere Performance cjbly...@us.ibm.com (919) 486-2105 t/l 526-2105 From: Nicholas L Gallardo/Austin/i...@ibmus To: wink-...@incubator.apache.org Cc: dev@cxf.apache.org Date: 06/24/2009 10:26 AM Subject: JAX-RS benchmark application? I was in a discussion with Chris Blythe yesterday about a common application for JAX-RS benchmarking. Geronimo has the DayTrader application that is purely Java EE 5 based and can be run on any platform. Having something similar for JAX-RS would be beneficial. Does anyone know if a similar application exists in other communities? Or, should we look at adapting the DayTrader application to support JAX-RS? -Nick Nicholas Gallardo WebSphere - REST & WebServices Development nlgal...@us.ibm.com Phone: 512-286-6258 Building: 903 / 5G-016
Re: How to add wsdl extension for SOAP/JMS.
Hmm... I'm not really sure. I don't think there IS a schema that would work properly for this. My gut feeling was something like: but I know that doesn't work. This will probably need some changes to CXF wsdl processing to really get this to work well. Actually, this could provide a good opportunity to cleanup the JAXB WSDL extension mechanism to NOT require that the schema extends the wsdl:tExtensibilityElement type. I'm actually thinking a xjc plugin that would make all the generated types automatically implement the wsdl4j ExtensibiltyElement interface and add the methods/fields for that. That can significantly cleanup the CXF schemas for all the extensors. It would be completely automatic. Dan On Tue June 23 2009 11:51:43 am liucong wrote: > Hi, > I want to add wsdl extension for SOAP/JMS according to > http://www.w3.org/TR/2008/WD-soapjms-20081121/#wsdl-extensions. > > For example, I want add wsdl extension for DeliveryMode property. I edit > the wsdl file like[1]: > > transport="http://www.w3.org/2008/07/soap/bindings/JMS/"/> > > PERSISTENT > > > > > > > > > > > ... > > > If I add the extension schema like this[2]: > > > > > > > > > > > > > > > > > > > > > But I can't get the extension in the wsdl. > If I change the wsdl like this[3]: > > transport="http://www.w3.org/2008/07/soap/bindings/JMS/"/> > > PERSISTENTe> > > > > > > > > > > > ... > > > I'll get the result of deliveryMode extension. > I think the wsdl extension just can add attributes, element to a > extension element in CXF. But I can't get the extension element's value. > Is it right? > > My question is: how to get the extension information in [1]. What does > the extension schema look like? > > thanks. > Liu -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: HTTP transport -- no exception on server side when client has reset TCP connection
Interesting. Not sure what to say. We would just be writing to the OutputStream obtained from response.getOutputStream(). If it's not throwing an IOException, I'm not sure what we could do. Any chance you could try with Jetty? Maybe Jetty does something different. Don't really know. :-( Dan On Wed June 24 2009 6:29:38 am Andrew Clegg wrote: > I'm posting this here rather than on the users list as it's a bit > technical, and I suspect it might indicate a bug in either CXF or at a > lower level. > > However, I'm really not sure how to simulate it in a way that would make a > convenient JIRA entry. I'm happy to bundle up some example code, if someone > could suggest a way to make the conditions realistic. > > The scenario is as follows: > > One of our collaborators at a remote site, using Metro, wrote a client for > a JAXB-JAXWS service here that runs long jobs, but synchronously. (Not my > design decision...) > > We were getting some weird behaviour on larger requests, where my web > method was returning a value, but his client was just hanging indefinitely, > waiting for the data. > > Eventually we tracked it down using Wireshark to a TCP RST packet coming > from his end after 30mins -- or more specifically, from the proxy server > all his outbound requests were going through. This was causing the TCP > connection from the proxy to here to be torn down, but apparently the proxy > wasn't closing the connection on the other side, so Metro thought it was > still open and kept waiting. > > However! > > What worries me is that when my CXF method returned the JAXB object, no > exception seems to have been raised, even though the TCP connection between > me and the proxy was closed long before. (I verified this with netstat.) > > I couldn't see anything in the CXF or Tomcat logs that suggested anything > unusual had happened. > > Is this normal behaviour? > > Cheers, > > Andrew. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: Whiteboard pattern for JAX-RS services
On Tue, Jun 23, 2009 at 8:46 AM, Sergey Beryozkin wrote: > Hi Josh > > > > I've got some code that allows OSGI bundles to use the whiteboard pattern >> to >> register restful services. When a service is registered with a specific >> property, say, "jaxrs.resource=true" the JAX-RS implementation registers >> that service as a JAX-RS resource. The same could be done with message >> body >> readers and writers, too. In my implementation, the JAX-RS servlet is >> registered under the "/rest/*" URL, and all of the JAX-RS resources fall >> below that, so /rest/foo can be provided by one bundle and /rest/bar could >> be provided by another. >> > > I'd like to ask your opinion about providing JAXRS providers through this > pattern. > In DOSGi we can now handle the registration of services and expose them as > web services using whatever style/frontend is needed (ws/rs). > As far as JAX-RS providers are concerned, we can only handle at the moment > a limited number of them, specifically JAXB/Aegis > MessageBodyReaders/Writers. It would be easy to add shortcuts for other > ones, say if a databinding property says 'atom' or 'xmlbeans' then we can > figure out what to do. > But in JAX-RS we can also have exception mappers, CXF specific exception > mappers which are used to handle exceptions on the client side, filters, > etc, they all can act as providers. Now, one option would be to scan an > implementation bundle for provider classes, those which have @Provider > annotation. > This may or may not always work as these providers may actually come from > some other bundle, say from some bundle acting as a providers repository. > So my thinking is that it should possible to supply provider instances > during the service registration or lookup from a given activator, as an > array value of some service property. This will make it possible to > configure individual provider instances too. > > Does it make sense ? Any other ideas ? > > cheers, Sergey > > I'm not sure how CXF keeps track of these providers now, but I assume there's a registry of some kind. Are the providers tied to specific jax-rs resources, or are they "global"? If it's a global registry, it should be trivial to add a service tracker that watches for new services that are registered with the osgi container under the MessageBodyReader, MessageBodyWriter, or ExceptionMapper interfaces. The service tracker would add or remove the providers from the internal CXF provider registry. That's what I did with the resteasy spi, but I am not as familiar with how CXF keeps track of providers. Oh, and sorry to hijack the thread, but I've been using the jax-rs frontend for DOSGi and I'm very happy with it... thanks for all of your work in this area. Job well done! Thanks, Josh
Re: Integrating JAX-RS runtime into DOSGi
Sergey, Thanks again for the detailed documentation you've provided in this thread. I was able to easily convert from JAX-WS to JAX-RS, which (I think) will make our lives even easier. Once we've got the ability to expose a single service with both of these frontends, I'll make use of that as well. I agree that the jaxrs.resource property is no longer needed, as you can simply register jaxrs resources as a dosgi services. Josh On Sat, Jun 20, 2009 at 11:10 AM, Sergey Beryozkin wrote: > Hi, > > I've applied your patch and I've completed the initial integration of > JAX-RS into DOSGi RI. As it often happens I underestimated a bit how > long it would take me to do it :-) but I'm quite happy now with what has > been done so far. > > I haven't got a chance to write JAX-WS system tests yet - I was a bit > constrained in time but judging from the code you did JAXWS/databindings > should be working nicely now - please feel free to add a system test, or > either of us will do it asap. > > Now, the property names have actually changed and differ from those you > provided in the patch. As David noted, it was recommended that DOSGI > providers would use reverse domain names as prefixes to their custom > configuration types, such as 'pojo' in case of DOSGI RI. Furthermore, > 'pojo' was a bit constraining in that it did not reflect the fact that > say SOAP or RS services were supported. Additionally, the DOSGI way is > to associate additional properties qualifying a given config type with > the config type property, for ex, if it's 'pojo' then it really should > be 'pojo.frontend', etc. > > What David changed on the trunk was that he introduced new properties, > while still maintaining the old ones for now. So, 'org.apache.cxf.ws' is > equivalent to old 'pojo' soap-based services, while 'org.apache.cxf.rs' > identifies a handler capable of exposing pojos as RESTful services. > > Now, frontends and databindings for SOAP services can be selected by the > following properties : 'org.apache.cxf.ws.frontend' & > 'org.apache.cxf.ws.databinding'. For JAX-RS (org.apache.cxf.rs) services > there's no need to configure frontends though databindings can be > configured too. > > Address & servlet context properties have also changed, with either > org.apache.cxf.ws/rs replacing 'pojo'. Please check the DOSGi docs - > David will also provide more feedback. > > It may be that global databinding and some other properties can still be > introduced for them be shared between soap & jaxrs services. Lets > discuss it more and see what can be done. > > David has also updated the trunk so that multiple config types can be > applied to a given service registration. There's a minor update still > needs to be done (something like AggregatePojoConfigurationHandler needs > to be added) but it's really nearly there. So for now please register > your bean twice to make them work with JAXWS & JAXRS, but it will be > fixed soon. I think the new properties will also let us do pretty > advanced combinations (like jaxb for soap but atom and aegis for jaxrs), > etc. > > There's something else David is thinking of doing shortly, possibly next > week or so. At the moment one has to configure DOSGI properties on the > individual service basis, either from the code or from the xml. David is > thinking of introducing wildcards such that for ex a given set of > (dosgi) properties can apply to a potentially unlimited number of > services - that will scale in terms of configuration dramatically. David > is traveling but he will clarify as soon as he can. > > For now I did not add the support for a jaxrs.resource property Aaron > and yourself talked about - this would be a non-standard property anyway > and may be you can live for now with using the DOSGI props. You'll be > abale to move all the dosgi properties away from your Activators once > David finishes his work on supporting wildcards. > > Now, as far as the JAX-RS integration is concerned. It works both ways, > on the client and on the server. Have a look please at > samples/greeter_rest, it's basically identical to greeter demo, except > that its GreeterService has JAX-RS annotations and it also introduces > GreeterService2 interface which has no JAX-RS annotations but will be > supported by the JAX-RS runtime, a model file in OSGI-INF/cxf/jaxrs > resource folder in the greeter-rest/interface bundle enables it. Note > that in this case the model enables the interface only so all the > implementation objects will be supported as the result. The > GreeterService2Impl registration code in the greeter-rest/impl Activator > is commented at the moment as the cxf 2.2.3-SNAPSHOT needs another > build. > > The only issue I haven't solved yet is that the restful client proxies > are created only in case of single-distribution, I could not figure out > why it was not working in case of the multibundle one. Will fix in due > course. > > So that is it for now - please try the latest trunk (though I'll ping > yo
Re: How to add wsdl extension for SOAP/JMS.
Hi, Dan, Thank you very much for your advice. By some experiments for the WSDL extension. I think it is right that this WSDL extension needs some changes to CXF wsdl processing. And the CXF wsdl processing will supoort the entension in SOAP/JMS. I think this kind of extension is necessary for CXF wsdl processing. Are there any documents which help me finish this kind of extension? thank you! :-) Liu Daniel Kulp wrote: Hmm... I'm not really sure. I don't think there IS a schema that would work properly for this. My gut feeling was something like: but I know that doesn't work. This will probably need some changes to CXF wsdl processing to really get this to work well. Actually, this could provide a good opportunity to cleanup the JAXB WSDL extension mechanism to NOT require that the schema extends the wsdl:tExtensibilityElement type. I'm actually thinking a xjc plugin that would make all the generated types automatically implement the wsdl4j ExtensibiltyElement interface and add the methods/fields for that. That can significantly cleanup the CXF schemas for all the extensors. It would be completely automatic. Dan On Tue June 23 2009 11:51:43 am liucong wrote: Hi, I want to add wsdl extension for SOAP/JMS according to http://www.w3.org/TR/2008/WD-soapjms-20081121/#wsdl-extensions. For example, I want add wsdl extension for DeliveryMode property. I edit the wsdl file like[1]: http://www.w3.org/2008/07/soap/bindings/JMS/"/> PERSISTENT ... If I add the extension schema like this[2]: But I can't get the extension in the wsdl. If I change the wsdl like this[3]: http://www.w3.org/2008/07/soap/bindings/JMS/"/> PERSISTENT ... I'll get the result of deliveryMode extension. I think the wsdl extension just can add attributes, element to a extension element in CXF. But I can't get the extension element's value. Is it right? My question is: how to get the extension information in [1]. What does the extension schema look like? thanks. Liu
Re: SOAP/JMS specification for CXF [Project Status]
Hi all, I have submitted a patch for my work in transport-jms. https://issues.apache.org/jira/browse/CXF-2253. It is not complete, and I'll continue to work on it to make it complete. Any suggests are welcome! liu liucong wrote: > Hi all, > > Project Description: > SOAP over JMS specification (http://www.w3.org/TR/soapjms/) is aimed at > a set of standards for the transport of SOAP messages over JMS (Java > Message Service). The main purpose is to ensure interoperability between > the implementations of different Web services vendors. > CXF does support SOAP over JMS, but it does not meet the current draft > specification defined at http://www.w3.org/TR/soapjms/ and instead uses > some proprietary formats, headers, URL formats, etc. This project would > update the SOAP/JMS support in CXF to be completely specification > compliant. > Any advice or help are welcome! > > Project Information: > 1.Project Status: http://wiki.apache.org/general/soapjms4cxf > 2.Project Code: http://github.com/liucong/jms4cxf2/tree/master > 3.Project JIRA task: https://issues.apache.org/jira/browse/CXF-2253 > > What I have done: > 1.Implement a simple JMS URI > (http://tools.ietf.org/html/draft-merrick-jms-uri-05 ) > 2.Integrate the JMS URI into current jms-transport. It is compatible > with the specification. > 3.Modify the JMS Header Properties and JMS Properties and make it > compatible with the specification. > 4.Modify some code about SOAP fault and MEPs. > > Liu > > >
