Re: A defect of JAXWS of RPC Literal operation which has xsd:Element message part?
Thanks Dan.
Thanks your help;
- Original Message -
From: "Daniel Kulp"
To:
Cc: "xuhb"
Sent: Monday, January 16, 2012 11:51 PM
Subject: Re: A defect of JAXWS of RPC Literal operation which has xsd:Element
message part?
> On Monday, January 16, 2012 5:37:23 PM xuhb wrote:
>> By the way, I am not sure if JAXWS specification support a RPC-Literal
>> Operation whose message part point to a xsd:element, not to a xsd:type.
>> Does anyone know about it ?
>
> WS-I Basic profile, the parts in an RPC-Literal style WSDL MUST point to a
> type, not an element:
>
> R2203 An rpc-literal binding in a DESCRIPTION MUST refer, in its
> soapbind:body
> element(s), only to wsdl:part element(s) that have been defined using the
> type
> attribute.
>
> Thus, such a wsdl as you describe is not WS-I Basic Profile compliant and
> thus
> would really be outside the scope of JAX-WS and CXF (and pretty much any
> other
> modern toolkit).
>
>
> Dan
>
>
>> - Original Message -
>> From: "xuhb"
>> To:
>> Sent: Monday, January 16, 2012 5:17 PM
>> Subject: A defect of JAXWS of RPC Literal operation which has xsd:Element
>> message part?
>
>>
>>
>> > Hi:
>> >
>> >
>> > CXF support RPC Literal operation which has message part point to a
>> > xsd:element;
> But it seems there is a defect;
>> >
>> >
>> >
>> > First I generate a JAXWS interface from such a wsdl, and publish the
>> > JAXWS as service;
>>
>> >
>> >
>> > If I doesn't specifiy the origical wsdl's location and force CXF
>> > create WSDL only from JAXWS interface. then the new wsdl's message
>> > part point to a xsd:type, but not a xsd:element;
>>
>> >
>> > for example:
>> >
>> > Original wsdl:
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Generate JAXWS-Interface:
>> >
>> >public interface RpcLiteralType {
>> >
>> >
>> >
>> >@WebResult(name = "rpcEInOutReturn", targetNamespace =
>> >"http://anyxml.samples/";, partName = "rpcEInOutReturn")
>> >@WebMethod
>> >public SymbolType rpcEInOut(
>> >
>> >@WebParam(partName = "rpcEInOutArg", name =
>> >"rpcEInOutArg")
>> >java.lang.String rpcEInOutArg
>> >
>> >);
>> >
>> > }
>> >
>> > Created WSDL from JAXWS-interface:
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > > > name="rpcEInOutResponse" />
>>
>> >
>> >
>> >
>> >
>> >
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
Re: A defect of JAXWS of RPC Literal operation which has xsd:Element message part?
By the way, I am not sure if JAXWS specification support a RPC-Literal
Operation whose message part point to a xsd:element, not to a xsd:type.
Does anyone know about it ?
- Original Message -
From: "xuhb"
To:
Sent: Monday, January 16, 2012 5:17 PM
Subject: A defect of JAXWS of RPC Literal operation which has xsd:Element
message part?
> Hi:
>
> CXF support RPC Literal operation which has message part point to a
> xsd:element;
> But it seems there is a defect;
>
> First I generate a JAXWS interface from such a wsdl, and publish the JAXWS
> as service;
>
> If I doesn't specifiy the origical wsdl's location and force CXF create
> WSDL only from JAXWS interface. then the new wsdl's message part point to a
> xsd:type, but not a xsd:element;
>
> for example:
>
> Original wsdl:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Generate JAXWS-Interface:
>public interface RpcLiteralType {
>
>@WebResult(name = "rpcEInOutReturn", targetNamespace =
> "http://anyxml.samples/";, partName = "rpcEInOutReturn")
>@WebMethod
>public SymbolType rpcEInOut(
>@WebParam(partName = "rpcEInOutArg", name = "rpcEInOutArg")
>java.lang.String rpcEInOutArg
>);
> }
>
> Created WSDL from JAXWS-interface:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
A defect of JAXWS of RPC Literal operation which has xsd:Element message part?
Hi:
CXF support RPC Literal operation which has message part point to a
xsd:element;
But it seems there is a defect;
First I generate a JAXWS interface from such a wsdl, and publish the JAXWS
as service;
If I doesn't specifiy the origical wsdl's location and force CXF create WSDL
only from JAXWS interface. then the new wsdl's message part point to a
xsd:type, but not a xsd:element;
for example:
Original wsdl:
Generate JAXWS-Interface:
public interface RpcLiteralType {
@WebResult(name = "rpcEInOutReturn", targetNamespace =
"http://anyxml.samples/";, partName = "rpcEInOutReturn")
@WebMethod
public SymbolType rpcEInOut(
@WebParam(partName = "rpcEInOutArg", name = "rpcEInOutArg")
java.lang.String rpcEInOutArg
);
}
Created WSDL from JAXWS-interface:
Re: Does CXF support multiple endpoint for single wsdl now?
I known, thanks a lot; If I really need one service with multiply port enabled, I think I could wrote a custom proxy service which just manipulate the WSDL and mapping the ports's address to different endpoint published by CXF; Thanks a lot; - Original Message - From: "Glen Mazza" To: Sent: Wednesday, December 28, 2011 10:43 PM Subject: Re: Does CXF support multiple endpoint for single wsdl now? > Yes, Endpoint.publish() takes only one port's endpoint, and so if you > want to have multiple endpoints running simultaneously, you need to have > multiple Endpoint.publish() commands.Alternatively, for Tomcat or > similar deployment, you would declare multiple > elements[1]. As Endpoint.publish() is part of the JAX-WS > specification[2], GlassFish Metro, CXF's main competitor, presumably > does the same thing. > > As each port can specify its own transport method (JMS or HTTP), SOAP > message format, additional SOAP header elements, and security policy, it > could become a major source of bugs were CXF to allow multiple ports to > be active for a single Endpoint.publish() (assuming we could do so and > still be JAX-WS compliant.) Be careful what you wish for. :) > > Glen > > [1] http://www.jroller.com/gmazza/entry/web_service_tutorial#WFstep6 > [2] http://docs.oracle.com/javase/6/docs/api/javax/xml/ws/Endpoint.html > > On 12/28/2011 09:03 AM, xuhb wrote: >> - Original Message - >> From: "Glen Mazza" >> To: >> Sent: Wednesday, December 28, 2011 9:25 PM >> Subject: Re: Does CXF support multiple endpoint for single wsdl now? >> >> >>> Within the same configuration file, can't you specify two separate >>> services, one with each port you wish to activate? That may be CXF's >>> way of supporting "multiport at runtime". >> I want to got a wsdl which contains a service with two active port >> simultaneously. >> But it seems cannot,I have tried the CXF's system test >> "org/apache/cxf/systest/ws/security/server.xml " which configure two >> seperate services. But the cxf actually do is just publish two service, and >> each service only activate one port; I cannot got a wsdl which activate >> two port simultaneously? >> >>> Glen >>> >>> On 12/28/2011 04:07 AM, xuhb wrote: >>>> - Original Message - >>>> From: "Willem Jiang" >>>> To: >>>> Sent: Wednesday, December 28, 2011 4:29 PM >>>> Subject: Re: Does CXF support multiple endpoint for single wsdl now? >>>> >>>> >>>>> In this case you need to specify the two endpoint and publish them >>>>> separately. >>>>> >>>> Yes, this is the only way I can do; and this is why I say the old version >>>> CXF doesn't support multi-port at runtime; >>>> >>>>> The port of the wsdl is band to the CXF endpoint, you may need to do >>>>> some addition work to check the WSDL if you want to publish the service >>>>> from the WSDL automatically. >>>>> >>>> I still have no idea about how to do; >>>> >>>> After hacking some code of CXF 2.3.3(not the latest version), I found it's >>>> very hard to support the feature I want, for example: the >>>> org.apache.cxf.service.invoke.Invoker is binding to >>>> org.apache.cxf.service.Service; so I am very hard to extending CXF to >>>> enable service to support mult-port, because if so, the invoker may not >>>> binding to service, it should be binding to port or endpoint; >>>> >>>>> On 12/28/11 3:53 PM, xuhb wrote: >>>>>> Thanks willem and Glen: >>>>>> >>>>>> I have tried, it seems I can only make CXF to publish a service with >>>>>> single port , I still cannot make CXF to publish a service with >>>>>> multi-port taking effect at same time; >>>>>> >>>>>> Also I have tried the example of CXF systest which support >>>>>> multiport(systests\ws-security\src\test\java\org\apache\cxf\systest\ws\security\Server.java) >>>>>> >>>>>> Following is the CXF systest 's wsdl, which contains 2 port. But the >>>>>> published service only has single port take effect; >>>>>> >>>>>>>>>>>name="TimestampSignEncryptPort" >>>>>>binding="tns:Gre
Re: Does CXF support multiple endpoint for single wsdl now?
- Original Message - From: "Glen Mazza" To: Sent: Wednesday, December 28, 2011 9:25 PM Subject: Re: Does CXF support multiple endpoint for single wsdl now? > Within the same configuration file, can't you specify two separate > services, one with each port you wish to activate? That may be CXF's > way of supporting "multiport at runtime". I want to got a wsdl which contains a service with two active port simultaneously. But it seems cannot,I have tried the CXF's system test "org/apache/cxf/systest/ws/security/server.xml " which configure two seperate services. But the cxf actually do is just publish two service, and each service only activate one port; I cannot got a wsdl which activate two port simultaneously? > Glen > > On 12/28/2011 04:07 AM, xuhb wrote: >> - Original Message - >> From: "Willem Jiang" >> To: >> Sent: Wednesday, December 28, 2011 4:29 PM >> Subject: Re: Does CXF support multiple endpoint for single wsdl now? >> >> >>> In this case you need to specify the two endpoint and publish them >>> separately. >>> >> Yes, this is the only way I can do; and this is why I say the old version >> CXF doesn't support multi-port at runtime; >> >>> The port of the wsdl is band to the CXF endpoint, you may need to do >>> some addition work to check the WSDL if you want to publish the service >>> from the WSDL automatically. >>> >> I still have no idea about how to do; >> >> After hacking some code of CXF 2.3.3(not the latest version), I found it's >> very hard to support the feature I want, for example: the >> org.apache.cxf.service.invoke.Invoker is binding to >> org.apache.cxf.service.Service; so I am very hard to extending CXF to enable >> service to support mult-port, because if so, the invoker may not binding to >> service, it should be binding to port or endpoint; >> >>> On 12/28/11 3:53 PM, xuhb wrote: >>>> Thanks willem and Glen: >>>> >>>> I have tried, it seems I can only make CXF to publish a service with >>>> single port , I still cannot make CXF to publish a service with multi-port >>>> taking effect at same time; >>>> >>>> Also I have tried the example of CXF systest which support >>>> multiport(systests\ws-security\src\test\java\org\apache\cxf\systest\ws\security\Server.java) >>>> >>>> Following is the CXF systest 's wsdl, which contains 2 port. But the >>>> published service only has single port take effect; >>>> >>>> >>> name="TimestampSignEncryptPort" >>>> binding="tns:Greeter_SOAPBinding"> >>>> >>> >>>> location="http://localhost:9000/GreeterService/TimestampSignEncryptPort"; >>>> /> >>>> >>>> >>> name="UsernameTokenPort" >>>> binding="tns:Greeter_SOAPBinding"> >>>> >>> >>>> location="http://localhost:9000/GreeterService/UsernameTokenPort"; >>>> /> >>>> >>>> >>>> >>>> When I run the example, I found when I trying to retrieve wsdl from >>>> http://mycomputername:9000/GreeterService/TimestampSignEncryptPort?wsdl >>>> only the TimestampSignEncryptPort will take effect (the address will be >>>> replaced as a correct url by cxf), >>>> and also retrieve wsdl from >>>> http://mycomptername:9000/GreeterService/UsernameTokenPort?wsdl , only the >>>> UsernameTokenPort will take effect; >>>> >>>> >>>> It seems the CXF doesn't publish a service for 2 port at same time, but >>>> just published two different service, and each service make one port >>>> taking effect and leave another aside >>>> >>> >>> -- >>> Willem >>> -- >>> FuseSource >>> Web: http://www.fusesource.com >>> Blog:http://willemjiang.blogspot.com (English) >>> http://jnn.javaeye.com (Chinese) >>> Twitter: willemjiang >>> Weibo: willemjiang >>> >> > > > > -- > Glen Mazza > Talend Community Coders > http://coders.talend.com > blog: http://www.jroller.com/gmazza > >
Re: Does CXF support multiple endpoint for single wsdl now?
- Original Message - From: "Willem Jiang" To: Sent: Wednesday, December 28, 2011 4:29 PM Subject: Re: Does CXF support multiple endpoint for single wsdl now? > In this case you need to specify the two endpoint and publish them > separately. > Yes, this is the only way I can do; and this is why I say the old version CXF doesn't support multi-port at runtime; > The port of the wsdl is band to the CXF endpoint, you may need to do > some addition work to check the WSDL if you want to publish the service > from the WSDL automatically. > I still have no idea about how to do; After hacking some code of CXF 2.3.3(not the latest version), I found it's very hard to support the feature I want, for example: the org.apache.cxf.service.invoke.Invoker is binding to org.apache.cxf.service.Service; so I am very hard to extending CXF to enable service to support mult-port, because if so, the invoker may not binding to service, it should be binding to port or endpoint; > On 12/28/11 3:53 PM, xuhb wrote: >> Thanks willem and Glen: >> >> I have tried, it seems I can only make CXF to publish a service with single >> port , I still cannot make CXF to publish a service with multi-port taking >> effect at same time; >> >> Also I have tried the example of CXF systest which support >> multiport(systests\ws-security\src\test\java\org\apache\cxf\systest\ws\security\Server.java) >> >> Following is the CXF systest 's wsdl, which contains 2 port. But the >> published service only has single port take effect; >> >> > name="TimestampSignEncryptPort" >> binding="tns:Greeter_SOAPBinding"> >> > >> location="http://localhost:9000/GreeterService/TimestampSignEncryptPort"; >> /> >> >> > name="UsernameTokenPort" >> binding="tns:Greeter_SOAPBinding"> >> > >> location="http://localhost:9000/GreeterService/UsernameTokenPort"; >> /> >> >> >> >> When I run the example, I found when I trying to retrieve wsdl from >> http://mycomputername:9000/GreeterService/TimestampSignEncryptPort?wsdl only >> the TimestampSignEncryptPort will take effect (the address will be replaced >> as a correct url by cxf), >> and also retrieve wsdl from >> http://mycomptername:9000/GreeterService/UsernameTokenPort?wsdl , only the >> UsernameTokenPort will take effect; >> >> >> It seems the CXF doesn't publish a service for 2 port at same time, but >> just published two different service, and each service make one port taking >> effect and leave another aside >> > > > -- > Willem > -- > FuseSource > Web: http://www.fusesource.com > Blog:http://willemjiang.blogspot.com (English) > http://jnn.javaeye.com (Chinese) > Twitter: willemjiang > Weibo: willemjiang > >
Re: Does CXF support multiple endpoint for single wsdl now?
Thanks Willem: I think I haven't explained what I want clearly; I want CXF to publish a single service with multiply port taking effect simultaneously at runtime. I am not sure if CXF could or not; - Original Message - From: "Willem Jiang" To: Sent: Tuesday, December 27, 2011 9:21 PM Subject: Re: Does CXF support multiple endpoint for single wsdl now? > Hi, > > I didn't quite get your meaning. CXF should support this kind feature > long time ago. > > You can specify the endpoint Qname of the WSDL when publish the service > from CXF. It means CXF supports to create the service module from the > WSDL which has multiple ports. > > On 12/27/11 12:12 PM, xuhb wrote: >> Hi: >> I remembered old version CXF doesn't support multiple port(endpoint) >> for single service of wsdl. >> Does the latest version support this feature? >> Thanks any suggestion > > > -- > Willem > -- > FuseSource > Web: http://www.fusesource.com > Blog:http://willemjiang.blogspot.com (English) > http://jnn.javaeye.com (Chinese) > Twitter: willemjiang > Weibo: willemjiang >
Re: Does CXF support multiple endpoint for single wsdl now?
Thanks willem and Glen: I have tried, it seems I can only make CXF to publish a service with single port , I still cannot make CXF to publish a service with multi-port taking effect at same time; Also I have tried the example of CXF systest which support multiport(systests\ws-security\src\test\java\org\apache\cxf\systest\ws\security\Server.java) Following is the CXF systest 's wsdl, which contains 2 port. But the published service only has single port take effect; http://localhost:9000/GreeterService/TimestampSignEncryptPort"; /> http://localhost:9000/GreeterService/UsernameTokenPort"; /> When I run the example, I found when I trying to retrieve wsdl from http://mycomputername:9000/GreeterService/TimestampSignEncryptPort?wsdl only the TimestampSignEncryptPort will take effect (the address will be replaced as a correct url by cxf), and also retrieve wsdl from http://mycomptername:9000/GreeterService/UsernameTokenPort?wsdl , only the UsernameTokenPort will take effect; It seems the CXF doesn't publish a service for 2 port at same time, but just published two different service, and each service make one port taking effect and leave another aside
Does cxf support xsd:any?
Hi: I am using camel 's payload CXF component; Now I want publish a service which doesn't constraint any xml schema, and client can post any xml element to this webservice; so I define the wsdl which input message's element is xsd:any; it looks like: wsdl:operation name="AnyPort"> But CXF doesn't support it now; I wonderring if this usage is valid to webservice specification? And should CXF support it or not?
Re: Concurrent Problem of CXF on tomcat?
thanks Jiang; As your suggest, I have tried sync mode, it works well; async will dead lock, dumping the stack trace when dead locked, most threads 's stack trace as following: "http-8090-57" daemon prio=10 tid=0x09c35000 nid=0x44d5 waiting on condition [0xaf487000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0xe321c210> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:207) at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:120) at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:85) at org.apache.camel.component.cxf.CxfConsumer$1.syncInvoke(CxfConsumer.java:121) at org.apache.camel.component.cxf.CxfConsumer$1.invoke(CxfConsumer.java:71) at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:106) - locked <0xe331d838> (a org.apache.cxf.interceptor.ServiceInvokerInterceptor$2) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263) - locked <0xe323ce38> (a org.apache.cxf.phase.PhaseInterceptorChain) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:206) at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:218) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:200) at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:114) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:184) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:107) at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:163) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain. - Original Message - From: "Willem Jiang" To: Sent: Friday, October 14, 2011 5:42 PM Subject: Re: Concurrent Problem of CXF on tomcat? > camel-cxf producer will use the async invocation by default, It's more > like an issue of CXF client async invocation. > It could be more helpful if you can show us the stack trace or where > the code is blocked. > On Fri Oct 14 16:42:24 2011, xuhb wrote: >> Sorry forget to say proxy: >> the proxy act as a web service to receive request from client and redirect >> to another existing webservice, and send the reponse from existing >> web-service back to original client; >> >> here in my test the client is Load Runner; >> the rout of proxy is just like: >> >> >> >> >> - Original Message - >> From: "xuhb" >> To: >> Sent: Friday, October 14, 2011 3:32 PM >> Subject: Concurrent Problem of CXF on tomcat? >> >> >>> Hi: >>> I build a simple proxy with cxf(2.4.3)& camel(2.8.1) on tomcat, and >>> trying to test the performance with HP LoadRunner; >>> the proxy program is build with pay-load model of camel-cxf; >>> >>> If the concurrent client is only 1, there is nothing wrong, the >>> throughput capacity is very stable (about 150 hits/second) >>> If I increasei concurrent clients (etc to 40) , the throughput >>> capacity doesn't increased, but drop down to a very slow number; (the >>> hits/second is only serval number); >>> >>> when concurrent clients is 40, at first the speed of cxf proxy is very >>
Re: Concurrent Problem of CXF on tomcat?
Sorry forget to say proxy: the proxy act as a web service to receive request from client and redirect to another existing webservice, and send the reponse from existing web-service back to original client; here in my test the client is Load Runner; the rout of proxy is just like: - Original Message - From: "xuhb" To: Sent: Friday, October 14, 2011 3:32 PM Subject: Concurrent Problem of CXF on tomcat? > Hi: >I build a simple proxy with cxf(2.4.3) & camel(2.8.1) on tomcat, and > trying to test the performance with HP LoadRunner; >the proxy program is build with pay-load model of camel-cxf; > >If the concurrent client is only 1, there is nothing wrong, the > throughput capacity is very stable (about 150 hits/second) >If I increasei concurrent clients (etc to 40) , the throughput capacity > doesn't increased, but drop down to a very slow number; (the hits/second is > only serval number); > >when concurrent clients is 40, at first the speed of cxf proxy is very > fast, but after a serveral seconds there are serveral > "java.net.SocketException: Unexpected end of file from server" occurs , and > then the speed of proxy will drop to very slow; > > Tthe camel-cxf will share same cxf-client in multi threads ( I have ask a > question of CXF client concurrents, accoding to CXF FAQ , it is thread safe > in my test usage), > and is there other issues cause such a concurrent problem ? > >Thanks for any suggestion;
Concurrent Problem of CXF on tomcat?
Hi: I build a simple proxy with cxf(2.4.3) & camel(2.8.1) on tomcat, and trying to test the performance with HP LoadRunner; the proxy program is build with pay-load model of camel-cxf; If the concurrent client is only 1, there is nothing wrong, the throughput capacity is very stable (about 150 hits/second) If I increasei concurrent clients (etc to 40) , the throughput capacity doesn't increased, but drop down to a very slow number; (the hits/second is only serval number); when concurrent clients is 40, at first the speed of cxf proxy is very fast, but after a serveral seconds there are serveral "java.net.SocketException: Unexpected end of file from server" occurs , and then the speed of proxy will drop to very slow; Tthe camel-cxf will share same cxf-client in multi threads ( I have ask a question of CXF client concurrents, accoding to CXF FAQ , it is thread safe in my test usage), and is there other issues cause such a concurrent problem ? Thanks for any suggestion;
Re: Caused by: java.net.SocketException: Unexpected end of file from server
Thanks for William Jiang. I also encounter such a problem. maxIdleTime works well; Will cxf support to configure maxIdleTime for jetty-transport ? - Original Message - From: "Willem Jiang" To: Sent: Wednesday, September 28, 2011 5:35 PM Subject: Re: Caused by: java.net.SocketException: Unexpected end of file from server Just one comment for the maxIdleTime. Jetty use this parameter to check the underlayer stream's states, the timeout timer will be reset when there is any read or write operation on the stream. On Wed Sep 28 13:39:03 2011, Freeman Fang wrote: > Hi, > > I've encounter similar exception lately(with Cxf 2.4.2), client > exception like > org.apache.cxf.interceptor.Fault: Could not send Message. > at > org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64) > > > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263) > > > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:519) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:449) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:352) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:304) > at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:88) > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:134) > at $Proxy34.sayHi(Unknown Source) > at > org.apache.servicemix.examples.cxf.HelloWorld_HelloWorldImplPort_Client.main(HelloWorld_HelloWorldImplPort_Client.java:78) > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > > > at java.lang.reflect.Method.invoke(Method.java:597) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:283) > at java.lang.Thread.run(Thread.java:680) > Caused by: java.net.SocketException: SocketException invoking > http://localhost:8181/cxf/HelloWorld: Unexpected end of file from server > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > > > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > > > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1426) > > > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1411) > > > at > org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) > at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:644) > at > org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62) > > > ... 15 more > Caused by: java.net.SocketException: Unexpected end of file from server > at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:769) > at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632) > at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:766) > at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632) > at > sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1195) > > > at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1531) > > > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1489) > > > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1397) > > > ... 18 more > > though I've seen this exception when deploy cxf service in OSGi > container which use http-osgi service, but the underlying http server > is still jetty(pax-web is based on jetty), so I believe that's the > same case for standalone cxf http transport. The key reason of this > exception is that on the server side the service process take a very > long time, let's say 10 mins, so the connection between client and > server become kinda of idle, for me in this case only configure client > side connectionTimeout and receiveTimeOut isn't enough, we also need > configure jetty server connector to set a longer maxIdleTime which can > honor this long connection idle, for pax-web, the standard jetty.xml > configuration is acceptable so it's just like > 300 > For cxf jetty server, I believe the httpj:connector here[1] should > also work > > [1]http://cxf.apache.org/docs/jetty-configuration.html > > Freeman > On 2011-8-19, at 下午7:54, Blue Diamond wrote: > >> *Please let me know if this issue was resolved in later versions of >> 2.3.x.* >> >> I am facing a sock
A question about CXF chain interceptor mechanism
Hi:
CXF Chain Interceptor is simple and good mechanism for protocol interpret;
But sometimes it seem "Chain Interceptor " mechanism is not very suitable for
things such as system resource release; To illustrate this, following is a
sample:
1) Recently I am using CXF to expose an existing system as a webservice;
When asking for data from the existing system , it will generate a temporary
file and return it as a result; That's to say: when I expose it as a
webservice, the temporary file must be deleted after the webservice response is
sent over(no mattacher successfully or fault);
At first, I think the it's simple and easy by using a interceptor to delete the
temporary file; and configure it in Out & FaultOut Chains;
But actually, things is not some simple. Because what I really want is some
mechanism which is like "try{interceptor-chains}finally
{do-some-system-resource-release}" ; Chain Interceptors may be aborted by some
internal failure (and it should be so because it's designed for protocol
interpret) . So if I use interceptor to delete the temporary file, sometimes
the temporary file cannot be deleted (for example: network break down while
sending soap-response, the Out Chain will be aborted, and temporary file cannot
be deleted);
So I wonderring if CXF support mechanism suitable for such a usage beside just
using interceptors ?
2) Maybe following is another sample:
Recently while I looking into CXF's source, it seems some interceptor of CXF
also do something which like system-resource release. If so , I guess,
sometimes this will also cause issues.
For example:
OutgoingChainInterceptor.handleMessage(){
if (null != bin && null != bin.getOperationInfo() &&
bin.getOperationInfo().isOneWay()) {
closeInput(message);
return;
}
}
OutgoingChainInterceptor will release system resources relate to input stream
for one-way operation, but it's not always be guaranteed invoked;
For example if the one-way business logical throw a runtime-exception , it will
breaked the interceptor chain, and OutgoingChainInterceptor will not be called.
So the input stream's underly system resource may not be released; (I have show
a real problem relate to OutgoingChainInterceptor in another issue
CXF-3750's comments).
Re: A mysteriously deadlock of CXF OnewayProcessorInterceptor(A question about CXF chain interceptor mechanism)
Hi, Dan
Unfortunately, the fixed for CXF-3750 may cause another question. which I am
not sure if it's a issuem of CXF or things the user should take care;
Details I have comments in CXF-3750;
- Original Message -
From: "xuhb"
To:
Sent: Monday, August 22, 2011 11:06 AM
Subject: Re: A mysteriously deadlock of CXF OnewayProcessorInterceptor
> Thanks Dan:
>
> I tried, it's ok now;
> thanks to your rapid fix;
>
> - Original Message -
> From: "Daniel Kulp"
> To:
> Cc: "xuhb"
> Sent: Saturday, August 20, 2011 1:21 AM
> Subject: Re: A mysteriously deadlock of CXF OnewayProcessorInterceptor
>
>
>>
>> I just committed a fix to trunk (pulling back to 2.4.x now as well). When
>> you get a chance, can you give it a try to see if it fixes your issue?
>> Threading things like these are hard to really test.
>>
>> Dan
>>
>>
>> On Friday, August 19, 2011 2:32:03 PM xuhb wrote:
>>> Maybe it is becuase before chain.wait() return, the sync of chain will be
>>> re-locked, so it will block untill chain.resume() finished;
>>
>>> - Original Message -
>>> From: "xuhb"
>>> To:
>>> Sent: Friday, August 19, 2011 1:39 PM
>>> Subject: Re: A mysteriously deadlock of CXF OnewayProcessorInterceptor
>>>
>>>
>>>
>>> > Sorry, I foget post the issue link:
>>> >
>>> > https://issues.apache.org/jira/browse/CXF-3750
>>> >
>>> > - Original Message -
>>> > From: "xuhb"
>>> > To:
>>> > Sent: Friday, August 19, 2011 1:34 PM
>>> > Subject: A mysteriously deadlock of CXF OnewayProcessorInterceptor
>>> >
>>> >
>>> >
>>> >> Hi:
>>> >>
>>> >>Recently when I am checking/testing CXF , there is a
>>> >>mysteriously deadlock of CXF Oneway Process; Normally CXF
>>> >>engine will invoke the one way bussiness logical asynchronized
>>> >>,, so the servlet handle will finished and return back to
>>> >>servlet engine immediately;
>>>>
>>> >>
>>> >>
>>> >>But sometime, I noticed that the servlet
>>> >>handle(JettyHTTPHandler) at server side doesn't return back to
>>> >>servlet engine(Jetty) immediately , it will waiting until the
>>> >>asynchrouse business logical finished;
>> After dig source of
>>> >>CXF, I find it 's relate to OnewayProcessorInterceptor;But
>>> >>until now I can only show when will the deadlock occurs, but I
>>> >>still can not explain why;>>
>>> >>
>>> >> Following is details:
>>> >> OnewayProcessInterceptor.handleMessage{
>>> >> synchronized (chain) {
>>> >> message.getExchange().get(Bus.class).getExtension(WorkQueueManager.cla
>>> >> ss)
>> .getAutomaticWorkQueue().execute(new Runnable() {
>>> >>
>>> >>public void run() {
>>> >>synchronized (chain) {
>>> >>
>>> >>System.out.println("--notify all");
>>> >>chain.notifyAll();
>>> >>
>>> >>}
>>> >>
>>> >>chain.resume(); //if chain.resume is called before chain.wait
>>> >>finished , the dead lock will occurs; It seems as
>>> >>chain.resume is synchronized, so it will relock on chain
>>> >>object, so the chain.wait() will deadlocked (... I feel
>>> >>confused for this, because jdk doesn't say so...) ;After
>>> >>chain.resume finished, locking on chain is released, deadlock
>>> >>of chain.wait() is also released; but I don't think this is
>>> >>problem of CXF , maybe it's jdk's problem ?? I feels confused;
>>>>
>>> >> }
>>> >>
>>> >> });
>>> >>
>>> >> System.out.println("--wait begin");
>>> >> chain.wait(20);
>>> >> System.out.println("--wait end");
>>> >>
>>> >> }
>>> >> }
>>> >> syncrhonized PhaseInterceptorChain.resume(){
>>> >>
>>> >> System.out.println("--api chain resume&q
Re: A mysteriously deadlock of CXF OnewayProcessorInterceptor
Thanks Dan:
I tried, it's ok now;
thanks to your rapid fix;
- Original Message -
From: "Daniel Kulp"
To:
Cc: "xuhb"
Sent: Saturday, August 20, 2011 1:21 AM
Subject: Re: A mysteriously deadlock of CXF OnewayProcessorInterceptor
>
> I just committed a fix to trunk (pulling back to 2.4.x now as well). When
> you get a chance, can you give it a try to see if it fixes your issue?
> Threading things like these are hard to really test.
>
> Dan
>
>
> On Friday, August 19, 2011 2:32:03 PM xuhb wrote:
>> Maybe it is becuase before chain.wait() return, the sync of chain will be
>> re-locked, so it will block untill chain.resume() finished;
>
>> - Original Message -
>> From: "xuhb"
>> To:
>> Sent: Friday, August 19, 2011 1:39 PM
>> Subject: Re: A mysteriously deadlock of CXF OnewayProcessorInterceptor
>>
>>
>>
>> > Sorry, I foget post the issue link:
>> >
>> > https://issues.apache.org/jira/browse/CXF-3750
>> >
>> > - Original Message -
>> > From: "xuhb"
>> > To:
>> > Sent: Friday, August 19, 2011 1:34 PM
>> > Subject: A mysteriously deadlock of CXF OnewayProcessorInterceptor
>> >
>> >
>> >
>> >> Hi:
>> >>
>> >>Recently when I am checking/testing CXF , there is a
>> >>mysteriously deadlock of CXF Oneway Process; Normally CXF
>> >>engine will invoke the one way bussiness logical asynchronized
>> >>,, so the servlet handle will finished and return back to
>> >>servlet engine immediately;
>>>
>> >>
>> >>
>> >>But sometime, I noticed that the servlet
>> >>handle(JettyHTTPHandler) at server side doesn't return back to
>> >>servlet engine(Jetty) immediately , it will waiting until the
>> >>asynchrouse business logical finished;
> After dig source of
>> >>CXF, I find it 's relate to OnewayProcessorInterceptor;But
>> >>until now I can only show when will the deadlock occurs, but I
>> >>still can not explain why;>>
>> >>
>> >> Following is details:
>> >> OnewayProcessInterceptor.handleMessage{
>> >> synchronized (chain) {
>> >> message.getExchange().get(Bus.class).getExtension(WorkQueueManager.cla
>> >> ss)
> .getAutomaticWorkQueue().execute(new Runnable() {
>> >>
>> >>public void run() {
>> >>synchronized (chain) {
>> >>
>> >>System.out.println("--notify all");
>> >>chain.notifyAll();
>> >>
>> >>}
>> >>
>> >>chain.resume(); //if chain.resume is called before chain.wait
>> >>finished , the dead lock will occurs; It seems as
>> >>chain.resume is synchronized, so it will relock on chain
>> >>object, so the chain.wait() will deadlocked (... I feel
>> >>confused for this, because jdk doesn't say so...) ;After
>> >>chain.resume finished, locking on chain is released, deadlock
>> >>of chain.wait() is also released; but I don't think this is
>> >>problem of CXF , maybe it's jdk's problem ?? I feels confused;
>>>
>> >> }
>> >>
>> >> });
>> >>
>> >> System.out.println("--wait begin");
>> >> chain.wait(20);
>> >> System.out.println("--wait end");
>> >>
>> >> }
>> >> }
>> >> syncrhonized PhaseInterceptorChain.resume(){
>> >>
>> >> System.out.println("--api chain resume");
>> >>
>> >>...
>> >>
>> >> }
>> >>
>> >> if the execute sequence as following, every thing is ok. there is no
>> >> dead lock;
>>>
>> >>chain.wait enter
>> >>chian.notify invoked
>> >>chain.wait return;
>> >>chain.resume(); //resume also synchronzed on chain object;
>> >>
>> >>
>> >> if the execute sequence as following , dead lock will occurs:
>> >>
>> >>chain.wait enter
>> >>chain.notify
>> >>chain.resume// ..now waiting on chain will blocked until
>> >>chain.resume finished(release sync on chain)
>
Re: A mysteriously deadlock of CXF OnewayProcessorInterceptor
Maybe it is becuase before chain.wait() return, the sync of chain will be
re-locked, so it will block untill chain.resume() finished;
- Original Message -
From: "xuhb"
To:
Sent: Friday, August 19, 2011 1:39 PM
Subject: Re: A mysteriously deadlock of CXF OnewayProcessorInterceptor
> Sorry, I foget post the issue link:
>
> https://issues.apache.org/jira/browse/CXF-3750
>
> - Original Message -
> From: "xuhb"
> To:
> Sent: Friday, August 19, 2011 1:34 PM
> Subject: A mysteriously deadlock of CXF OnewayProcessorInterceptor
>
>
>> Hi:
>>Recently when I am checking/testing CXF , there is a mysteriously
>> deadlock of CXF Oneway Process; Normally CXF engine will invoke the one
>> way bussiness logical asynchronized ,, so the servlet handle will finished
>> and return back to servlet engine immediately;
>>
>>But sometime, I noticed that the servlet handle(JettyHTTPHandler) at
>> server side doesn't return back to servlet engine(Jetty) immediately , it
>> will waiting until the asynchrouse business logical finished;
>>After dig source of CXF, I find it 's relate to
>> OnewayProcessorInterceptor;But until now I can only show when will the
>> deadlock occurs, but I still can not explain why;
>>
>> Following is details:
>> OnewayProcessInterceptor.handleMessage{
>> synchronized (chain) {
>> message.getExchange().get(Bus.class).getExtension(WorkQueueManager.class)
>> .getAutomaticWorkQueue().execute(new Runnable() {
>>public void run() {
>>synchronized (chain) {
>>System.out.println("--notify all");
>>chain.notifyAll();
>>}
>>
>>chain.resume(); //if chain.resume is called before chain.wait finished ,
>> the dead lock will occurs; It seems as chain.resume is synchronized, so it
>> will relock on chain object, so the chain.wait() will deadlocked (... I feel
>> confused for this, because jdk doesn't say so...) ;After chain.resume
>> finished, locking on chain is released, deadlock of chain.wait() is also
>> released; but I don't think this is problem of CXF , maybe it's jdk's
>> problem ?? I feels confused;
>> }
>> });
>> System.out.println("--wait begin");
>> chain.wait(20);
>> System.out.println("--wait end");
>> }
>> }
>> syncrhonized PhaseInterceptorChain.resume(){
>> System.out.println("--api chain resume");
>>...
>> }
>>
>> if the execute sequence as following, every thing is ok. there is no dead
>> lock;
>>chain.wait enter
>>chian.notify invoked
>>chain.wait return;
>>chain.resume(); //resume also synchronzed on chain object;
>>
>> if the execute sequence as following , dead lock will occurs:
>>chain.wait enter
>>chain.notify
>>chain.resume// ..now waiting on chain will blocked until chain.resume
>> finished(release sync on chain)
>>chain.wait return;
>>
>> following dump on console indicate the above sequence:
>>
>> No DeadLock dump :
>> --wait begin
>> --notify all
>> --wait end
>> --api chain resume
>> product service begin Fri Aug 19 12:10:28 CST 2011 //a lone time(10 seconds)
>> one way business logical begin
>> product service end Fri Aug 19 12:10:38 CST 2011.//a lone time(10
>> seconds) one way business logical end;
>>
>>
>> DeadLock Dump:
>> --wait begin
>> --notify all
>> --api chain resume
>> product service begin Fri Aug 19 12:10:40 CST 2011
>> product service end Fri Aug 19 12:10:50 CST 2011
>> --wait end
>>
>>
>> Until now I am not sure if problem is CXF's or JDK's, or something which I
>> don't know cause such a deadlock;
>> I also wrote a simple program to simulate the execute sequnce which
>> causeddead lock in CXF, but the simple program never dead lock;
>>
>> I tried CXF 2.3.3 version && Jetty transport && (JDK1.5_22 || JDK 1.6_17) &&
>> Windows XP system;
>>
>> I also post this question as a JIRA issue:
>>
Re: A mysteriously deadlock of CXF OnewayProcessorInterceptor
Sorry, I foget post the issue link:
https://issues.apache.org/jira/browse/CXF-3750
- Original Message -
From: "xuhb"
To:
Sent: Friday, August 19, 2011 1:34 PM
Subject: A mysteriously deadlock of CXF OnewayProcessorInterceptor
> Hi:
>Recently when I am checking/testing CXF , there is a mysteriously deadlock
> of CXF Oneway Process; Normally CXF engine will invoke the one way
> bussiness logical asynchronized ,, so the servlet handle will finished and
> return back to servlet engine immediately;
>
>But sometime, I noticed that the servlet handle(JettyHTTPHandler) at
> server side doesn't return back to servlet engine(Jetty) immediately , it
> will waiting until the asynchrouse business logical finished;
>After dig source of CXF, I find it 's relate to
> OnewayProcessorInterceptor;But until now I can only show when will the
> deadlock occurs, but I still can not explain why;
>
> Following is details:
> OnewayProcessInterceptor.handleMessage{
> synchronized (chain) {
> message.getExchange().get(Bus.class).getExtension(WorkQueueManager.class)
> .getAutomaticWorkQueue().execute(new Runnable() {
>public void run() {
>synchronized (chain) {
>System.out.println("--notify all");
>chain.notifyAll();
>}
>
>chain.resume(); //if chain.resume is called before chain.wait finished ,
> the dead lock will occurs; It seems as chain.resume is synchronized, so it
> will relock on chain object, so the chain.wait() will deadlocked (... I feel
> confused for this, because jdk doesn't say so...) ;After chain.resume
> finished, locking on chain is released, deadlock of chain.wait() is also
> released; but I don't think this is problem of CXF , maybe it's jdk's
> problem ?? I feels confused;
> }
> });
> System.out.println("--wait begin");
> chain.wait(20);
> System.out.println("--wait end");
> }
> }
> syncrhonized PhaseInterceptorChain.resume(){
> System.out.println("--api chain resume");
>...
> }
>
> if the execute sequence as following, every thing is ok. there is no dead
> lock;
>chain.wait enter
>chian.notify invoked
>chain.wait return;
>chain.resume(); //resume also synchronzed on chain object;
>
> if the execute sequence as following , dead lock will occurs:
>chain.wait enter
>chain.notify
>chain.resume// ..now waiting on chain will blocked until chain.resume
> finished(release sync on chain)
>chain.wait return;
>
> following dump on console indicate the above sequence:
>
> No DeadLock dump :
> --wait begin
> --notify all
> --wait end
> --api chain resume
> product service begin Fri Aug 19 12:10:28 CST 2011 //a lone time(10 seconds)
> one way business logical begin
> product service end Fri Aug 19 12:10:38 CST 2011.//a lone time(10
> seconds) one way business logical end;
>
>
> DeadLock Dump:
> --wait begin
> --notify all
> --api chain resume
> product service begin Fri Aug 19 12:10:40 CST 2011
> product service end Fri Aug 19 12:10:50 CST 2011
> --wait end
>
>
> Until now I am not sure if problem is CXF's or JDK's, or something which I
> don't know cause such a deadlock;
> I also wrote a simple program to simulate the execute sequnce which
> causeddead lock in CXF, but the simple program never dead lock;
>
> I tried CXF 2.3.3 version && Jetty transport && (JDK1.5_22 || JDK 1.6_17) &&
> Windows XP system;
>
> I also post this question as a JIRA issue:
>
A mysteriously deadlock of CXF OnewayProcessorInterceptor
Hi:
Recently when I am checking/testing CXF , there is a mysteriously deadlock
of CXF Oneway Process; Normally CXF engine will invoke the one way bussiness
logical asynchronized ,, so the servlet handle will finished and return back to
servlet engine immediately;
But sometime, I noticed that the servlet handle(JettyHTTPHandler) at server
side doesn't return back to servlet engine(Jetty) immediately , it will waiting
until the asynchrouse business logical finished;
After dig source of CXF, I find it 's relate to
OnewayProcessorInterceptor;But until now I can only show when will the
deadlock occurs, but I still can not explain why;
Following is details:
OnewayProcessInterceptor.handleMessage{
synchronized (chain) {
message.getExchange().get(Bus.class).getExtension(WorkQueueManager.class)
.getAutomaticWorkQueue().execute(new Runnable() {
public void run() {
synchronized (chain) {
System.out.println("--notify all");
chain.notifyAll();
}
chain.resume(); //if chain.resume is called before chain.wait finished ,
the dead lock will occurs; It seems as chain.resume is synchronized, so it
will relock on chain object, so the chain.wait() will deadlocked (... I feel
confused for this, because jdk doesn't say so...) ;After chain.resume finished,
locking on chain is released, deadlock of chain.wait() is also released; but
I don't think this is problem of CXF , maybe it's jdk's problem ?? I feels
confused;
}
});
System.out.println("--wait begin");
chain.wait(20);
System.out.println("--wait end");
}
}
syncrhonized PhaseInterceptorChain.resume(){
System.out.println("--api chain resume");
...
}
if the execute sequence as following, every thing is ok. there is no dead
lock;
chain.wait enter
chian.notify invoked
chain.wait return;
chain.resume(); //resume also synchronzed on chain object;
if the execute sequence as following , dead lock will occurs:
chain.wait enter
chain.notify
chain.resume// ..now waiting on chain will blocked until chain.resume
finished(release sync on chain)
chain.wait return;
following dump on console indicate the above sequence:
No DeadLock dump :
--wait begin
--notify all
--wait end
--api chain resume
product service begin Fri Aug 19 12:10:28 CST 2011 //a lone time(10 seconds)
one way business logical begin
product service end Fri Aug 19 12:10:38 CST 2011.//a lone time(10 seconds)
one way business logical end;
DeadLock Dump:
--wait begin
--notify all
--api chain resume
product service begin Fri Aug 19 12:10:40 CST 2011
product service end Fri Aug 19 12:10:50 CST 2011
--wait end
Until now I am not sure if problem is CXF's or JDK's, or something which I
don't know cause such a deadlock;
I also wrote a simple program to simulate the execute sequnce which
causeddead lock in CXF, but the simple program never dead lock;
I tried CXF 2.3.3 version && Jetty transport && (JDK1.5_22 || JDK 1.6_17) &&
Windows XP system;
I also post this question as a JIRA issue:
Re: NULL Pointer Exception while processing attachments
Thanks Dan: Yes , it is; While mapping attachment to byte[], if attachment is big, the sun's decoder will increase buffer and read from middle of buffer. This is corrected in CXF-3582. Thanks a lot > original - > Sender: Daniel Kulp [mailto:dk...@apache.org] > Date: 2011/8/9 22:13 > Receiver: users@cxf.apache.org > : Re: NULL Pointer Exception while processing attachments > > On Tuesday, August 09, 2011 11:36:56 AM xuhb wrote: > > Thanks Jim > > > > I just tried the latest version of CXF 2.4.1. This problem doesn't occurs > in > > this version; > > I think maybe some issue fixed in 2.4.1 has fix the problem. But I am not > > know which one is.; > > Likely CXF-3582. > > Dan > > > > > > > original - > > > Sender: Jim Ma [mailto:mail2ji...@gmail.com] > > > Date: 2011/8/9 11:03 > > > Receiver: users@cxf.apache.org > > > Subject: Re: NULL Pointer Exception while processing attachments > > > > > > From the information you provided, we can not tell if it's really a > > > CXF issue. Can you file a jira issue with your test case to help > > > reproduce ? > > > > > > Cheers > > > Jim > > > > > > On Tue, Aug 9, 2011 at 10:43 AM, xuhb wrote: > > > > Hi: > > > > When I use cxf webservice at following situation, there always a > > > > null > > > > pointer exception occurs > > > > > > > > 1)MTOM enabled, and multi attachments sent. > > > > 2)The first attachment is big enough (etc 2M). and the second > > > > attachments > > > > > is > > > > > > > very small (etc: several bytes); > > > > 3)the MTOM attachment is mapped to a byte[] attribute (not > > > > DataHandler). > > > > > > > > At such a situation, the server side of cxf can only find the first > > > > attachments, And the second attachment cannot be found , so a > > > > NullPointer > > > > > > exception occurs > > > > > > > > Stack: > > > > Java.lang.NullPointerException > > > >At > > > > > > > org.apache.cxf.attachment.LazyDataSource.getContentType(LazyDataSource.j > > > av> > > > a: > > > > 61) > > > > > > > > Is it a bug? > -- > Daniel Kulp > dk...@apache.org > http://dankulp.com/blog > Talend - http://www.talend.com
Re: NULL Pointer Exception while processing attachments
Thanks Jim I just tried the latest version of CXF 2.4.1. This problem doesn't occurs in this version; I think maybe some issue fixed in 2.4.1 has fix the problem. But I am not know which one is.; > original - > Sender: Jim Ma [mailto:mail2ji...@gmail.com] > Date: 2011/8/9 11:03 > Receiver: users@cxf.apache.org > Subject: Re: NULL Pointer Exception while processing attachments > > From the information you provided, we can not tell if it's really a > CXF issue. Can you file a jira issue with your test case to help > reproduce ? > > Cheers > Jim > > On Tue, Aug 9, 2011 at 10:43 AM, xuhb wrote: > > Hi: > > When I use cxf webservice at following situation, there always a null > > pointer exception occurs > > > > 1)MTOM enabled, and multi attachments sent. > > 2)The first attachment is big enough (etc 2M). and the second attachments > is > > very small (etc: several bytes); > > 3)the MTOM attachment is mapped to a byte[] attribute (not DataHandler). > > > > At such a situation, the server side of cxf can only find the first > > attachments, And the second attachment cannot be found , so a NullPointer > > exception occurs > > > > Stack: > > Java.lang.NullPointerException > > At > > > org.apache.cxf.attachment.LazyDataSource.getContentType(LazyDataSource.jav > a: > > 61) > > > > Is it a bug? > > > > > > > > > >
NULL Pointer Exception while processing attachments
Hi: When I use cxf webservice at following situation, there always a null pointer exception occurs 1)MTOM enabled, and multi attachments sent. 2)The first attachment is big enough (etc 2M). and the second attachments is very small (etc: several bytes); 3)the MTOM attachment is mapped to a byte[] attribute (not DataHandler). At such a situation, the server side of cxf can only find the first attachments, And the second attachment cannot be found , so a NullPointer exception occurs Stack: Java.lang.NullPointerException At org.apache.cxf.attachment.LazyDataSource.getContentType(LazyDataSource.java: 61) Is it a bug?
Does CXF support WSDL1.1 HTTP-Binding?
Hi: When I got a WSDL which contains a HTTP-BINDING. 1)Could I write a client to invoke such a webservice using HTTP-BINDING as simple as SOAP Binding? 2)Could I write a service and publish it with a WSDL use HTTP-Binding as simple as SOAP Binding? Thanks any suggestion.
Re: Does CXF support Webservice Http binding?
Thanks Jinglong Wang, I have tried, your suggestion cannot works, there always a Exception( Caused by: org.apache.cxf.BusException: No binding factory for namespace http://schemas.xmlsoap.org/wsdl/http/ registered. ); I have check the CXF's Http-Binding 's online document, take a look at the source code of CXF's http-binding also. It seems the CXF's http-binding do not suppor the WSDL1.1's HTTP-Binding specification(xmlns = "http://schemas.xmlsoap.org/wsdl/http/";). Does anyone can confirm that if CXF http-binding support WSDL1.1's HTTP-Binding or nor? Thanks any suggestion. > -Original- > Sender: Jinglong Wang [mailto:nogr...@gmail.com] > Date: 2011/7/19 10:05 > Receiver: users@cxf.apache.org > Subject: Re: Does CXF support Webservice Http binding? > > maybe another... > > serviceClass="demo.services.IRestPort" > address="/restws" wsdlLocation="classpath:restful.wsdl" > bindingId="http://apache.org/cxf/binding/http";> > > On Sun, Jul 17, 2011 at 3:54 PM, xuhb wrote: > > > Hi: > > > > Axis2 & .net could publish a PortType with Http-Binding in WSDL. > > That's to say: when user write a service business logical, the user could > > choose to publish the service interface to be a Soap-Binding Webservice or > > a > > Http-Binding Webservice without changed the definition of java /.net source > > code > > > > > > > > I have checked the online document of CXF HTTP-Binding. But it seems > > the cxf 's http binding contract is defined by Annotation of java code, > > but not WSDL. So I am wondering if CXF support to publish a JAVA Interface > > to be a Http-Binding WebService (the http-binding contract is defined in > > WSDL , but not in JAVA Code)? > > > > > > > > > > > > It' s usage may looks like as following: > > > > 1) predefined wsdl : > > > > > > > > > > > > > > > > > > > > . > > > > > > > > > > > > > name="httpBindingEndpoint"/> > > > > > > > > > > > > 2) publish the java service with existing wsdl > > > > > > > >> > > endpoint="s:httpBindingEndpoint" > > > > serviceName="s:httpBindingService > > > > wsdlLocation="classpath:http-binding-hello.wsdl"> > > > > > > > > > > > > > > > > Thanks any suggestion > > > > > > > -- > 命运并不是不可战胜的，平等需要自己去争取，平等不会白白让你取得。想要平等， > 必须有劳动，有付出，有汗水，有坚定的信念。
Does CXF support Webservice Http binding?
Hi: Axis2 & .net could publish a PortType with Http-Binding in WSDL. That's to say: when user write a service business logical, the user could choose to publish the service interface to be a Soap-Binding Webservice or a Http-Binding Webservice without changed the definition of java /.net source code I have checked the online document of CXF HTTP-Binding. But it seems the cxf 's http binding contract is defined by Annotation of java code, but not WSDL. So I am wondering if CXF support to publish a JAVA Interface to be a Http-Binding WebService (the http-binding contract is defined in WSDL , but not in JAVA Code)? It' s usage may looks like as following: 1) predefined wsdl : . 2) publish the java service with existing wsdl Thanks any suggestion
Exception(Unexpected end of file from server) of CXF
Recently I always encounter a "Unexpected end of file from server" Exception at CXF client side. it seems this exception is caused by the CXF Serverside has unexcepted release the http connection ; I tried some effort to to use a simple test case to regenerate such a exception; Following is a simple test case which will cause such a exception. keypoint of the test case: 1)MTOM enabled; 2)Using Jetty-Transport at serverside, and using SUN JDK's http client at client side; 3)the service logical is simple: first consume all attachment and close it; then wait for a long time (about 10 miniutes); In practice, there is no such a service which will block for so long time, but in the simple test case, I must use such a long time to force such a exception occurs; 4)set the client side 's receiveTime to a infinite time(almost) to avoid receive time out exception. then the client will block to wait service , but after about 7 minutes a ""Unexpected end of file from server" Exception will raised at client side; Other key points I have tried: 1)At first I guess maybe this is the jetty-server's problem: I guess it will release connection silently while the servlet-handler execute too long time; But unfortunately it 's not so . Because I tried another simple test case, which doesnt generate such a exception . The only difference is: there is no attachment in xml data; Also the service will wait a very long time( 10minutes, 20minutes I have tried) . And the client will blocking util service returned; Ps: the stack of the Exception is : org.apache.cxf.interceptor.Fault: Could not send Message. at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64) ... Caused by: java.net.SocketException: SocketException invoking http://localhost:9000/service/moreattachmentsrpcliteral: Unexpected end of file from server ... at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1385) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1370) ... Caused by: java.net.SocketException: Unexpected end of file from server at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:763) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:626) at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:760) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:626) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:983) at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:367) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1490) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1448) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1356) ... 35 more
