[
https://issues.apache.org/jira/browse/CXF-8926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18090145#comment-18090145
]
mircea edited comment on CXF-8926 at 6/19/26 11:08 AM:
-------------------------------------------------------
[^client-run.log] [^mtom-slow-server-demo.zip][^server-run.log]
I have made an demo MTOM example (server side and client side) begining from
example inside project at path
distribution/src/main/release/samples/mtom
The example is in attachment in zip archive.
The basics of example are as follows:
Client is a MTOM client that uploads a large amount of bytes.
Server is a MTOM server intentionally made slower with
Thread.sleep(TIME_PARAM);
The ideea is that the server will always be slower than the client because it
is supposed to make a hard processing.
So the Thread.sleep on server side abstracts any kind of processing.
But the server does not fully hang, it just read slower than the client writes.
This application demo should be ok to finish properly even after long period of
time (e.g. 5 minutes) on server side and also on client side.
But the client fails after 60 seconds even if receive timeout was set to zero
as client code shows:
HTTPConduit conduit = (HTTPConduit) cxfClient.getConduit();
HTTPClientPolicy policy = new HTTPClientPolicy();
policy.setConnectionTimeout(connectTimeout);
policy.setReceiveTimeout(receiveTimeout);
policy.setAllowChunking(true);
conduit.setClient(policy);
In attachment I have put to run logs of server side and the run logs of client
side with catched exception.
This is a real test scenario that reveals the problem.
The run was on windows platform.
The java version can be seen in logs.
was (Author: JIRAUSER313715):
[^client-run.log]
[^mtom-slow-server-demo.zip][^server-run.log]client-run.log{^}!/jira/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!{^}
I have made an demo MTOM example (server side and client side) begining from
example inside project at path
distribution/src/main/release/samples/mtom
The example is in attachment in zip archive.
The basics of example are as follows:
Client is a MTOM client that uploads a large amount of bytes.
Server is a MTOM server intentionally made slower with
Thread.sleep(TIME_PARAM);
The ideea is that the server will always be slower than the client because it
is supposed to make a hard processing.
So the Thread.sleep on server side abstracts any kind of processing.
But the server does not fully hang, it just read slower than the client writes.
This application demo should be ok to finish properly even after long period of
time (e.g. 5 minutes) on server side and also on client side.
But the client fails after 60 seconds even if receive timeout was set to zero
as client code shows:
HTTPConduit conduit = (HTTPConduit) cxfClient.getConduit();
HTTPClientPolicy policy = new HTTPClientPolicy();
policy.setConnectionTimeout(connectTimeout);
policy.setReceiveTimeout(receiveTimeout);
policy.setAllowChunking(true);
conduit.setClient(policy);
In attachment I have put to run logs of server side and the run logs of client
side with catched exception.
This is a real test scenario that reveals the problem.
The run was on windows platform.
The java version can be seen in logs.
> MTOM - Lock while processing attachment
> ---------------------------------------
>
> Key: CXF-8926
> URL: https://issues.apache.org/jira/browse/CXF-8926
> Project: CXF
> Issue Type: Bug
> Reporter: wilfried
> Assignee: Freeman Yue Fang
> Priority: Major
> Attachments: MTOMAttachmentStallTest.java, client-run.log,
> mtom-example.pcap, mtom-slow-server-demo.zip, server-run.log
>
>
> I'm currently implementing a SOAP client to send document with CXF 4.0.1 (the
> application is quarkus based).
> My client is working fine when firewall is open between my machine and the
> target server, but in case firewall is closed (for QA environment for
> example), I was expecting to get a timeout, but it's not the case. The SOAP
> client stops its execution to the interceptor *AttachmentOutEndingInterceptor
> *and waits indefinitely.
> After profiling the application, I found out a lock as shown by the below
> thread dump:
> {code:java}
> "executor-thread-2" #296 daemon prio=5 os_prio=0 cpu=31.25ms elapsed=201.04s
> tid=0x0000019f9cd475d0 nid=0x5cf8 in Object.wait() [0x0000009645dfe000]
> java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait([email protected]/Native Method)
> - waiting on <no object reference available>
> at
> java.io.PipedInputStream.awaitSpace([email protected]/PipedInputStream.java:273)
> at
> java.io.PipedInputStream.receive([email protected]/PipedInputStream.java:231)
> - locked <0x0000000613854b08> (a java.io.PipedInputStream)
> at
> java.io.PipedOutputStream.write([email protected]/PipedOutputStream.java:150)
> at
> org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:51)
> at
> org.apache.cxf.io.AbstractThresholdOutputStream.write(AbstractThresholdOutputStream.java:69)
> at
> org.apache.cxf.io.CacheAndWriteOutputStream.write(CacheAndWriteOutputStream.java:81)
> at jakarta.activation.DataHandler.writeTo(DataHandler.java:283)
> at
> org.apache.cxf.attachment.AttachmentSerializer.writeAttachments(AttachmentSerializer.java:318)
> at
> org.apache.cxf.interceptor.AttachmentOutInterceptor$AttachmentOutEndingInterceptor.handleMessage(AttachmentOutInterceptor.java:126)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> - locked <0x0000000613856e30> (a
> org.apache.cxf.phase.PhaseInterceptorChain)
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:528)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:439)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:354)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:312)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:140)
> at jdk.proxy7.$Proxy235.addMessage(jdk.proxy7/Unknown Source)
> at
> lu.etat.ci.fwt.soap.SOAPTestController.callSaySomethingMtomSecuredCIDUT(SOAPTestController.java:138)
> at
> lu.etat.ci.fwt.soap.SOAPTestController$quarkusrestinvoker$callSaySomethingMtomSecuredCIDUT_1b14f2d5ed1a4d42c824e7582903a9f19063cae3.invoke(Unknown
> Source)
> at
> org.jboss.resteasy.reactive.server.handlers.InvocationHandler.handle(InvocationHandler.java:29)
> at
> io.quarkus.resteasy.reactive.server.runtime.QuarkusResteasyReactiveRequestContext.invokeHandler(QuarkusResteasyReactiveRequestContext.java:141)
> at
> org.jboss.resteasy.reactive.common.core.AbstractResteasyReactiveContext.run(AbstractResteasyReactiveContext.java:145)
> at
> io.quarkus.vertx.core.runtime.VertxCoreRecorder$14.runWith(VertxCoreRecorder.java:576)
> at
> org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2513)
> at
> org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1512)
> at
> org.jboss.threads.DelegatingRunnable.run(DelegatingRunnable.java:29)
> at
> org.jboss.threads.ThreadLocalResettingRunnable.run(ThreadLocalResettingRunnable.java:29)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run([email protected]/Thread.java:833)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
