How to shutdown btrace? - btrace

I'm using btrace to instrument an application. What Btrace does is inject bytecode into the running JVM to trace the target application. It also sets up a socket connection to communicate between the tracer client and the application.
When I stop the tracer client it does not remove the code injected into the application. It continues to trace and send back the results over this port. Since client is no longer there any attempts to send trace results generate exception:
java.net.SocketException: Connection reset by peer: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
at java.net.SocketOutputStream.write(SocketOutputStream.java:153)
at java.io.ObjectOutputStream$BlockDataOutputStream.writeBlockHeader(ObjectOutputStream.java:1894)
at java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1875)
at java.io.ObjectOutputStream$BlockDataOutputStream.setBlockDataMode(ObjectOutputStream.java:1786)
at java.io.ObjectOutputStream.reset(ObjectOutputStream.java:500)
at com.sun.btrace.agent.RemoteClient.onCommand(RemoteClient.java:137)
at com.sun.btrace.BTraceRuntime$ConsumerWrapper.accept(BTraceRuntime.java:169)
at com.sun.btrace.BTraceRuntime$ConsumerWrapper.accept(BTraceRuntime.java:157)
at com.sun.btrace.org.jctools.queues.MpscChunkedArrayQueue.drain(MpscChunkedArrayQueue.java:624)
at com.sun.btrace.BTraceRuntime$4.run(BTraceRuntime.java:443)
at java.lang.Thread.run(Thread.java:745)
How can I un-instrument the application and gracefully shutdown btrace after connecting it to an application?

Related

Access static file cause "Connection reset by peer" exception

I use StaticHandler in vertx-web to serve all static resource(css js mp4 files),
rootRouter.get("/static/*").handler(StaticHandler.create());
I use <video> tag to access the mp4 file in my page:
<video muted="muted" autoplay="autoplay" loop="loop" src="/static/img/factory.mp4"></video>
When I access the page which contained the mp4 file from Chrome, the server side will report a exception:
03:04:17.893 [vert.x-eventloop-thread-3] ERROR i.vertx.core.net.impl.ConnectionBase - Connection reset by peer
java.io.IOException: Connection reset by peer
at java.base/sun.nio.ch.FileChannelImpl.transferTo0(Native Method)
at java.base/sun.nio.ch.FileChannelImpl.transferToDirectlyInternal(FileChannelImpl.java:501)
at java.base/sun.nio.ch.FileChannelImpl.transferToDirectly(FileChannelImpl.java:566)
at java.base/sun.nio.ch.FileChannelImpl.transferTo(FileChannelImpl.java:678)
at io.netty.channel.DefaultFileRegion.transferTo(DefaultFileRegion.java:130)
at io.netty.channel.socket.nio.NioSocketChannel.doWriteFileRegion(NioSocketChannel.java:362)
at io.netty.channel.nio.AbstractNioByteChannel.doWriteInternal(AbstractNioByteChannel.java:238)
at io.netty.channel.nio.AbstractNioByteChannel.doWrite0(AbstractNioByteChannel.java:212)
at io.netty.channel.socket.nio.NioSocketChannel.doWrite(NioSocketChannel.java:400)
at io.netty.channel.AbstractChannel$AbstractUnsafe.flush0(AbstractChannel.java:934)
at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.forceFlush(AbstractNioChannel.java:361)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:708)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:829)
But when I use Firefox, there will be no problem.
And other static resources work normal, only the mp4 file will cause this exception.
Does anyone know what's going on? What should I do?
Connection reset by peer
is a response by the remote server (or firewall between them) stating that it will not proceed with completing this request.
So the other side has abruptly aborted the connection in midst of a transaction.
There are many possible reasons for this. It may well be a firewall denial, an SSL handshake failure, a VPN issue, slow internet, a proxy problem or even an HTTP failed request.
PS: this and this were helpful.
Updating the vert.x version in use could also print less of such messages as stated here.

Milo: Connect to (public) OPC-UA-Server

First of all: I'm a newbie to OPCUA. :)
I'm trying to connect an Milo Client to our Server but don't really understand whats going wrong. The sample Client and Server work fine together, but when I try to connect the client sample with one of the public OPC-UA-Test-Servers I get those exceptions:
15:48:34.729 [ua-netty-event-loop-0] DEBUG
org.eclipse.milo.opcua.stack.client.handlers.UaTcpClientAcknowledgeHandler
- Sent Hello message on channel=[id: 0xc22800c2, L:/10.22.19.217:58947 - R:opcua.demo-this.com/52.233.134.134:51210]. 15:48:34.729 [ua-netty-event-loop-0] WARN io.netty.channel.DefaultChannelPipeline -
An exceptionCaught() event was fired, and it reached at the tail of
the pipeline. It usually means the last handler in the pipeline did
not handle the exception. java.io.IOException: An existing connection
was forcibly closed by the remote host at
sun.nio.ch.SocketDispatcher.read0(Native Method) at
sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43) at
sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) at
sun.nio.ch.IOUtil.read(IOUtil.java:192) at
sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380) at
io.netty.buffer.PooledUnsafeDirectByteBuf.setBytes(PooledUnsafeDirectByteBuf.java:221)
at
io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:898)
at
io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:242)
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:119)
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:528)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:485)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:399)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:371) at
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
at java.lang.Thread.run(Thread.java:745) 15:48:39.612
[ForkJoinPool.commonPool-worker-1] DEBUG
org.eclipse.milo.opcua.stack.client.ClientChannelManager - Channel
bootstrap failed: timed out waiting for acknowledge
org.eclipse.milo.opcua.stack.core.UaException: timed out waiting for
acknowledge at
org.eclipse.milo.opcua.stack.client.handlers.UaTcpClientAcknowledgeHandler.lambda$startHelloTimeout$4(UaTcpClientAcknowledgeHandler.java:156)
at
org.eclipse.milo.opcua.stack.client.handlers.UaTcpClientAcknowledgeHandler$$Lambda$27/469017260.run(Unknown
Source) at
io.netty.util.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:581)
at
io.netty.util.HashedWheelTimer$HashedWheelBucket.expireTimeouts(HashedWheelTimer.java:655)
at
io.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:367)
at java.lang.Thread.run(Thread.java:745) 15:48:39.613 [main] ERROR
org.eclipse.milo.examples.client.ClientExampleRunner - Error running
example: UaException: status=Bad_Timeout, message=timed out waiting
for acknowledge java.util.concurrent.ExecutionException: UaException:
status=Bad_Timeout, message=timed out waiting for acknowledge at
java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357)
at
java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1887)
at
org.eclipse.milo.examples.client.ClientExampleRunner.createClient(ClientExampleRunner.java:56)
at
org.eclipse.milo.examples.client.ClientExampleRunner.run(ClientExampleRunner.java:103)
at
org.eclipse.milo.examples.client.BrowseExample.main(BrowseExample.java:40)
Caused by: org.eclipse.milo.opcua.stack.core.UaException: timed out
waiting for acknowledge at
org.eclipse.milo.opcua.stack.client.handlers.UaTcpClientAcknowledgeHandler.lambda$startHelloTimeout$4(UaTcpClientAcknowledgeHandler.java:156)
at
org.eclipse.milo.opcua.stack.client.handlers.UaTcpClientAcknowledgeHandler$$Lambda$27/469017260.run(Unknown
Source) at
io.netty.util.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:581)
at
io.netty.util.HashedWheelTimer$HashedWheelBucket.expireTimeouts(HashedWheelTimer.java:655)
at
io.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:367)
at java.lang.Thread.run(Thread.java:745) 15:48:42.842
[threadDeathWatcher-2-1] DEBUG io.netty.buffer.PoolThreadCache - Freed
2 thread-local buffer(s) from thread: ua-netty-event-loop-0
I took the sample-Code and removed the Certificate/Keypair and changed the URL to opc.tcp://opcua.demo-this.com:51210/UA/SampleServer since the public server doesn't need authorization:
SecurityPolicy securityPolicy = clientExample.getSecurityPolicy();
EndpointDescription[] endpoints = UaTcpStackClient.getEndpoints("opc.tcp://opcua.demo-this.com:51210/UA/SampleServer").get();
EndpointDescription endpoint = Arrays.stream(endpoints)
.filter(e -> e.getSecurityPolicyUri().equals(securityPolicy.getSecurityPolicyUri()))
.findFirst().orElseThrow(() -> new Exception("no desired endpoints returned"));
logger.info("Using endpoint: {} [{}]", endpoint.getEndpointUrl(), securityPolicy);
loader.load();
OpcUaClientConfig config = OpcUaClientConfig.builder()
.setApplicationName(LocalizedText.english("eclipse milo opc-ua client"))
.setApplicationUri("urn:eclipse:milo:examples:client")
//.setCertificate(loader.getClientCertificate())
//.setKeyPair(loader.getClientKeyPair())
.setEndpoint(endpoint)
.setIdentityProvider(clientExample.getIdentityProvider())
.setRequestTimeout(uint(5000))
.build();
return new OpcUaClient(config);
What am I missing?
Greetings and thanks in advance :)
Buried in that stack trace is the real problem: UaException: timed out waiting for acknowledge.
Maybe your firewall or network setup is blocking it, or maybe the server didn't send it back, but the problem is that the client never received the Acknowledge message in response to its Hello.
FWIW, I can run the ReadExample against that public server with no issue. In ReadExample I overrode getSecurityPolicy() and returned SecurityPolicy.None and in ClientExampleRunner just replaced the endpoint URL.

SOAPFaultException:Failed to send request while using the SOAP webservice

java.rmi.RemoteException: SOAP Fault:javax.xml.rpc.soap.SOAPFaultException: Failed to send request
Detail:
<detail><bea_fault:stacktrace xmlns:bea_fault="http://www.bea.com/servers/wls70/webservice/fault/1.0.0">java.net.ConnectException: Connection timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:559)
at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.connect(BaseSSLSocketImpl.java:141)
at sun.net.NetworkClient.doConnect(NetworkClient.java:163)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:394)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:529)
at sun.net.www.protocol.https.HttpsClient.<init>(HttpsClient.java:272)
at sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:329)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:172)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:911)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:158)
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1014)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:230)
at weblogic.webservice.binding.http11.Http11ClientBinding.send(Http11ClientBinding.java:438)
at weblogic.webservice.core.handler.ClientHandler.handleRequest(ClientHandler.java:38)
at weblogic.webservice.core.HandlerChainImpl.handleRequest(HandlerChainImpl.java:144)
at weblogic.webservice.core.ClientDispatcher.send(ClientDispatcher.java:235)
at weblogic.webservice.core.ClientDispatcher.dispatch(ClientDispatcher.java:146)
at weblogic.webservice.core.DefaultOperation.invoke(DefaultOperation.java:449)
at weblogic.webservice.core.DefaultOperation.invoke(DefaultOperation.java:435)
at weblogic.webservice.core.rpc.StubImpl._invoke(StubImpl.java:306)
at com.cengage.ips.IPSInquiryWebServiceSoap_Stub.itemInquiry(IPSInquiryWebServiceSoap_Stub.java:64)
at main.java.com.cengage.ips.ServiceManager.getItemResponse(ServiceManager.java:57)
at main.java.com.cengage.ips.process.ResponseHandler.itemResponseHandler(ResponseHandler.java:49)
at main.java.com.cengage.ips.IPSIntegration.process(IPSIntegration.java:63)
at main.java.com.cengage.ips.IPSIntegration.run(IPSIntegration.java:37)
at main.java.com.cengage.ips.IPSIntegration.main(IPSIntegration.java:28)
</bea_fault:stacktrace></detail>; nested exception is:
javax.xml.rpc.soap.SOAPFaultException: Failed to send request
at com.cengage.ips.IPSInquiryWebServiceSoap_Stub.itemInquiry(IPSInquiryWebServiceSoap_Stub.java:69)
at main.java.com.cengage.ips.ServiceManager.getItemResponse(ServiceManager.java:57)
at main.java.com.cengage.ips.process.ResponseHandler.itemResponseHandler(ResponseHandler.java:49)
at main.java.com.cengage.ips.IPSIntegration.process(IPSIntegration.java:63)
at main.java.com.cengage.ips.IPSIntegration.run(IPSIntegration.java:37)
at main.java.com.cengage.ips.IPSIntegration.main(IPSIntegration.java:28)
Caused by: javax.xml.rpc.soap.SOAPFaultException: Failed to send request
at weblogic.webservice.core.ClientDispatcher.receive(ClientDispatcher.java:317)
at weblogic.webservice.core.ClientDispatcher.dispatch(ClientDispatcher.java:147)
at weblogic.webservice.core.DefaultOperation.invoke(DefaultOperation.java:449)
at weblogic.webservice.core.DefaultOperation.invoke(DefaultOperation.java:435)
at weblogic.webservice.core.rpc.StubImpl._invoke(StubImpl.java:306)
at com.cengage.ips.IPSInquiryWebServiceSoap_Stub.itemInquiry(IPSInquiryWebServiceSoap_Stub.java:64)
... 5 more
Am trying to use one SOAP web service. I have tried executing this application in my local windows machine using some cmd script file. Its working fine. But when i try in Unix server with shell script am getting the above error. Can someone please suggest the solution?

PAX Exam integration test REST client call to REST service fails with Caused by: java.net.SocketTimeoutException: Read timed out

I have an integration test that injects a rest client into the test class. When that rest client calls a rest service being hosted by the same pax exam test container everything stops for about a minute until I get a long list of Socket Read Timeout exceptions and connection refused exceptions. If I inject a rest client that calls a rest service in another container everything works fine. It almost seems like the rest service isn't given a thread to execute in. If I start up the pax exam container manually I can verify that the rest service has started correctly. And if I inject the OSGi service into the test class everything works correctly. Using PaxExam 3.6 and Apache ServiceMix (4.5.3)
Stack Trace:
2015-04-22 17:10:02,211 | WARN | ion(1)-127.0.0.1 | PhaseInterceptorChain | 123 - org.apache.cxf.cxf-api - 2.6.6 | Interceptor for {http://rest.mediation.velocity.randomness.com/}mediationService has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Could not send Message.
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64)[123:org.apache.cxf.cxf-api:2.6.6]
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262)[123:org.apache.cxf.cxf-api:2.6.6]
at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:530)[139:org.apache.cxf.cxf-rt-frontend-jaxrs:2.6.6]
at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:205)[139:org.apache.cxf.cxf-rt-frontend-jaxrs:2.6.6]
at com.sun.proxy.$Proxy156.getmediations(Unknown Source)
at com.randomness.velocity.mediation.rest.client.mediationClient.getmediations(mediationClient.java:90)[282:mediation-rest-client:3.1.0.SNAPSHOT]
at com.randomness.velocity.mediation.rest.client.mediationClient.getmediations(mediationClient.java:97)[282:mediation-rest-client:3.1.0.SNAPSHOT]
at com.randomness.velocity.itest.client_management.DataCleanupTests.verifyvelocityClientManagementStarts(DataCleanupTests.java:123)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_75]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_75]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_75]
at java.lang.reflect.Method.invoke(Method.java:606)[:1.7.0_75]
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)[313:org.ops4j.pax.tipi.junit:4.11.0.1]
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)[313:org.ops4j.pax.tipi.junit:4.11.0.1]
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)[313:org.ops4j.pax.tipi.junit:4.11.0.1]
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)[313:org.ops4j.pax.tipi.junit:4.11.0.1]
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)[313:org.ops4j.pax.tipi.junit:4.11.0.1]
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)[313:org.ops4j.pax.tipi.junit:4.11.0.1]
at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:67)
at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:37)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)[313:org.ops4j.pax.tipi.junit:4.11.0.1]
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)[313:org.ops4j.pax.tipi.junit:4.11.0.1]
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)[313:org.ops4j.pax.tipi.junit:4.11.0.1]
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)[313:org.ops4j.pax.tipi.junit:4.11.0.1]
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)[313:org.ops4j.pax.tipi.junit:4.11.0.1]
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)[313:org.ops4j.pax.tipi.junit:4.11.0.1]
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)[313:org.ops4j.pax.tipi.junit:4.11.0.1]
at org.junit.runner.JUnitCore.run(JUnitCore.java:138)[313:org.ops4j.pax.tipi.junit:4.11.0.1]
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:124)
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.findAndInvoke(JUnitProbeInvoker.java:97)
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.call(JUnitProbeInvoker.java:73)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_75]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_75]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_75]
at java.lang.reflect.Method.invoke(Method.java:606)[:1.7.0_75]
at org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)[311:org.ops4j.pax.exam.rbc:3.6.0]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_75]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_75]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_75]
at java.lang.reflect.Method.invoke(Method.java:606)[:1.7.0_75]
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)[:1.7.0_75]
at sun.rmi.transport.Transport$2.run(Transport.java:202)[:1.7.0_75]
at sun.rmi.transport.Transport$2.run(Transport.java:199)[:1.7.0_75]
at java.security.AccessController.doPrivileged(Native Method)[:1.7.0_75]
at sun.rmi.transport.Transport.serviceCall(Transport.java:198)[:1.7.0_75]
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:567)[:1.7.0_75]
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828)[:1.7.0_75]
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.access$400(TCPTransport.java:619)[:1.7.0_75]
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$1.run(TCPTransport.java:684)[:1.7.0_75]
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$1.run(TCPTransport.java:681)[:1.7.0_75]
at java.security.AccessController.doPrivileged(Native Method)[:1.7.0_75]
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:681)[:1.7.0_75]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_75]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_75]
at java.lang.Thread.run(Thread.java:745)[:1.7.0_75]
Caused by: java.net.SocketTimeoutException: SocketTimeoutException invoking https://127.0.0.1:7103/mediation/patient/ff8081814ce1299a014ce142cb410065?materialization=Full: Read timed out
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)[:1.7.0_75]
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)[:1.7.0_75]
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)[:1.7.0_75]
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)[:1.7.0_75]
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1469)[135:org.apache.cxf.cxf-rt-transports-http:2.6.6]
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1454)[135:org.apache.cxf.cxf-rt-transports-http:2.6.6]
at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)[123:org.apache.cxf.cxf-api:2.6.6]
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:659)[135:org.apache.cxf.cxf-rt-transports-http:2.6.6]
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)[123:org.apache.cxf.cxf-api:2.6.6]
... 54 more
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)[:1.7.0_75]
at java.net.SocketInputStream.read(SocketInputStream.java:152)[:1.7.0_75]
at java.net.SocketInputStream.read(SocketInputStream.java:122)[:1.7.0_75]
at sun.security.ssl.InputRecord.readFully(InputRecord.java:442)[:1.7.0_75]
at sun.security.ssl.InputRecord.read(InputRecord.java:480)[:1.7.0_75]
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:934)[:1.7.0_75]
at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:891)[:1.7.0_75]
at sun.security.ssl.AppInputStream.read(AppInputStream.java:102)[:1.7.0_75]
at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)[:1.7.0_75]
at java.io.BufferedInputStream.read1(BufferedInputStream.java:275)[:1.7.0_75]
at java.io.BufferedInputStream.read(BufferedInputStream.java:334)[:1.7.0_75]
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:687)[:1.7.0_75]
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:633)[:1.7.0_75]
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1324)[:1.7.0_75]
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:468)[:1.7.0_75]
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:338)[:1.7.0_75]
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1606)[135:org.apache.cxf.cxf-rt-transports-http:2.6.6]
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1532)[135:org.apache.cxf.cxf-rt-transports-http:2.6.6]
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1440)[135:org.apache.cxf.cxf-rt-transports-http:2.6.6]
I figured out what was going on. I added an osgi:service to a spring config in the integration test project that exposed the rest client as an osgi service so I could inject the client into the test class. By doing that I created a second service in the osgi container that was advertised via the same interface that the rest service was using to look up the real osgi service implementation. So the rest service was actually getting the rest client injected into it instead of the osgi service impl, this created an infinite loop that finally crashed out and threw tons of connection refused and socket read timeout exceptions to my console. Good stuff

JAX-WS client causes Jetty EofException

I am using an embedded Jetty server to provide Web Services (using Jetty-JAXWS2-SPI to allow Jetty to serve the requests) and I am seeing the following errors when a connection terminates from my JAX-WS test client (generated by wsimport):
11:32:54.544 [pool-1-thread-5] DEBUG com.mycompany.SomeClass - EOF
org.eclipse.jetty.io.EofException: null
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:321) ~[jetty-http-7.3.1.v20110307.jar:7.3.1.v20110307]
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:214) ~[jetty-http-7.3.1.v20110307.jar:7.3.1.v20110307]
at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:411) ~[jetty-server-7.3.1.v20110307.jar:7.3.1.v20110307]
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:526) ~[jetty-io-7.3.1.v20110307.jar:7.3.1.v20110307]
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:41) [jetty-io-7.3.1.v20110307.jar:7.3.1.v20110307]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [na:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [na:1.6.0_24]
at java.lang.Thread.run(Thread.java:662) [na:1.6.0_24]
Even though these are not important errors (logged at DEBUG level) and I only see them from my test client, not from soapUI or the 'real' (.NET client), I would rather not see them at all.
I guess the problem is caused by the socket behavior within the JAX-WS client? Is there any way to influence the socket behavior to avoid this issue?
Other information:
Others have reported this issue on the Jetty mailing list, also when providing Web Services using Jetty-JAXWS2-SPI.
I am using JDK 1.6.0_24 and the JAX-WS implementation it contains.
I am using Jetty 7.3.1-20110307