glassfishrobot
commented
15 years ago Reported by joe_roberts_z@java.net
Closed glassfishrobot closed 14 years ago
glassfishrobot
commented
15 years ago Reported by joe_roberts_z@java.net
glassfishrobot
commented
15 years ago joe_roberts_z@java.net said: Created an attachment (id=978) WCF client, use the following command to test: run soap=1.1 ini=gendefxml.ini userm=true
glassfishrobot
commented
15 years ago joe_roberts_z@java.net said: I tried to upload the WAR for tomcat but it was too large 1.6 MB for the site. If there is an alternate upload site that will work please let me know.
glassfishrobot
commented
15 years ago joe_roberts_z@java.net said: I am creating a better example based on the addNumbers example so it can be used as a test case. Please disregard the previous attachment. I will have another one today.
glassfishrobot
commented
15 years ago joe_roberts_z@java.net said: Created an attachment (id=979) This zip file contains the project to build the tomcat WAR and the csharp client
glassfishrobot
commented
15 years ago joe_roberts_z@java.net said: Created an attachment (id=980) Place this jar file in the Tomcat6 lib directory
glassfishrobot
commented
15 years ago joe_roberts_z@java.net said: The problem seems related to having attachments when using WS-RM and also to the file of the attachments. If I use an 8kb file that is returned by Metro. The WCF client gets the response but Metro returns this at the end:
--[HTTP response 500]--
<?xml version='1.0' encoding='UTF-8'?><s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:a="http://www.w3.org/2005/08/addressing">
If I use a 54KB file the WCF client never gets the response and keeps trying to send the request until the session is closed:
--[HTTP request]-- Host: localhost:8080 Content-type: multipart/related; type="application/xop+xml";start="<http://tempuri.org/0>";boundary="uuid:5359f3a e-e57f-44c6-819e-74ab87e0bfe8+id=1";start-info="text/xml"
Content-length: 907 Connection: Keep-Alive Mime-version: 1.0 Expect: 100-continue Soapaction: "http://schemas.xmlsoap.org/ws/2005/02/rm/CreateSequence"
--uuid:5359f3ae-e57f-44c6-819e-74ab87e0bfe8+id=1 Content-ID: <http://tempuri.org/0> Content-Transfer-Encoding: 8bit Content-Type: application/xop+xml;charset=utf-8;type="text/xml"
--[HTTP response 200]--
<?xml version='1.0' encoding='UTF-8'?><S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
Content-length: 1102 Mime-version: 1.0 Expect: 100-continue Soapaction: "addNumbers"
--uuid:5359f3ae-e57f-44c6-819e-74ab87e0bfe8+id=2 Content-ID: <http://tempuri.org/0> Content-Transfer-Encoding: 8bit Content-Type: application/xop+xml;charset=utf-8;type="text/xml"
--[HTTP request]-- Host: localhost:8080 Content-type: multipart/related; type="application/xop+xml";start="<http://tempuri.org/0>";boundary="uuid:5359f3a e-e57f-44c6-819e-74ab87e0bfe8+id=3";start-info="text/xml"
Content-length: 1102 Mime-version: 1.0 Expect: 100-continue Soapaction: "addNumbers"
--uuid:5359f3ae-e57f-44c6-819e-74ab87e0bfe8+id=3 Content-ID: <http://tempuri.org/0> Content-Transfer-Encoding: 8bit Content-Type: application/xop+xml;charset=utf-8;type="text/xml"
--[HTTP request]-- Host: localhost:8080 Content-type: multipart/related; type="application/xop+xml";start="<http://tempuri.org/0>";boundary="uuid:5359f3a e-e57f-44c6-819e-74ab87e0bfe8+id=4";start-info="text/xml"
Content-length: 1102 Mime-version: 1.0 Expect: 100-continue Soapaction: "addNumbers"
--uuid:5359f3ae-e57f-44c6-819e-74ab87e0bfe8+id=4 Content-ID: <http://tempuri.org/0> Content-Transfer-Encoding: 8bit Content-Type: application/xop+xml;charset=utf-8;type="text/xml"
--[HTTP request]-- Host: localhost:8080 Content-type: multipart/related; type="application/xop+xml";start="<http://tempuri.org/0>";boundary="uuid:5359f3a e-e57f-44c6-819e-74ab87e0bfe8+id=5";start-info="text/xml"
Content-length: 1102 Mime-version: 1.0 Expect: 100-continue Soapaction: "addNumbers"
--uuid:5359f3ae-e57f-44c6-819e-74ab87e0bfe8+id=5 Content-ID: <http://tempuri.org/0> Content-Transfer-Encoding: 8bit Content-Type: application/xop+xml;charset=utf-8;type="text/xml"
--[HTTP request]-- Host: localhost:8080 Content-type: multipart/related; type="application/xop+xml";start="<http://tempuri.org/0>";boundary="uuid:5359f3a e-e57f-44c6-819e-74ab87e0bfe8+id=6";start-info="text/xml"
Content-length: 1102 Mime-version: 1.0 Expect: 100-continue Soapaction: "addNumbers"
--uuid:5359f3ae-e57f-44c6-819e-74ab87e0bfe8+id=6 Content-ID: <http://tempuri.org/0> Content-Transfer-Encoding: 8bit Content-Type: application/xop+xml;charset=utf-8;type="text/xml"
--[HTTP request]-- Host: localhost:8080 Content-type: multipart/related; type="application/xop+xml";start="<http://tempuri.org/0>";boundary="uuid:5359f3a e-e57f-44c6-819e-74ab87e0bfe8+id=7";start-info="text/xml"
Content-length: 984 Mime-version: 1.0 Expect: 100-continue Soapaction: "http://www.w3.org/2005/08/addressing/soap/fault"
--uuid:5359f3ae-e57f-44c6-819e-74ab87e0bfe8+id=7 Content-ID: <http://tempuri.org/0> Content-Transfer-Encoding: 8bit Content-Type: application/xop+xml;charset=utf-8;type="text/xml"
--[HTTP response 500]--
<?xml version='1.0' encoding='UTF-8'?><s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:r="http://schem
as.xmlsoap.org/ws/2005/02/rm">
glassfishrobot
commented
15 years ago joe_roberts_z@java.net said: Use the following updated AddNumbersClient.exe.config content (maxReceiveMessageSize and maxBufferSize increased); it should resolve the issue with the large attachment
<?xml version="1.0" encoding="utf-8"?>
However you will still see this every time:
--[HTTP response 500]--
<?xml version='1.0' encoding='UTF-8'?><s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:a="http://www.w3.org/2005/08/addressing">
glassfishrobot
commented
15 years ago joe_roberts_z@java.net said: On the original application the error is the same, but the 500 server response is returned before the actual payload, I believe because the payload is much larger in this case and this causes for the WCF client to always fail (it never gets the response). So this is a big problem.
glassfishrobot
commented
15 years ago m_potociar@java.net said: Looking into this
glassfishrobot
commented
15 years ago m_potociar@java.net said: Created an attachment (id=991) Communication between C# client and Tomcat-deployed Metro service, captured on the server side
glassfishrobot
commented
15 years ago m_potociar@java.net said: Hi Joe, please see the attachement #991 containing the log of message exchange between .NET client and Metro service. Other than the fact that .NET client fails to close and terminate the RM session, I cannot see any errors.
This is what I get on the client side:
C:\dev\projects__issues\1216-wcf-client-interop\fromwsdl\csharp-client>AddNumbersClient.exe 3 Saving DEFINITIONFILE to disk.
...the file is created and saved and the client terminates without any complains.
Here's my system setup:
Windows 2003 Server with latest updates .NET 3.5 SP1
MacOS X 10.5.8 JavaVM 1.5.0_19-b02-304 Tomcat 6.0.23 Latest Metro nightly build
..I am using Java5, but that should not matter - I do it to avoid the Metro installation into Java endorsed dirs...
Please, provide more info how to reproduce the issue.
glassfishrobot
commented
15 years ago joe_roberts_z@java.net said: Hi Marek,
I read your response today and I am looking at this right now. I went back to
test the sample I provided and it does seem to work now so I am a little
confused...
When I go back to the original application it does not and the
client always gets the 500 server response I submitted before where Action
element in the WS-Addressing headers of the request is not recognized by Metro.
The strange thing is that on the one that doesn't work it seems the 500 response
is returned by metro and then the response payload is returned after that, so it
seems the sequence of exchange messages is a little different. I am not sure if
this is related to having handlers in place or the messages being larger. I
will spent more time today to try to recreate it every time.
glassfishrobot
commented
15 years ago m_potociar@java.net said: As for that SOAP fault being returned from Metro endpoint, if you look more closely you can notice that it is just an "echo" of the original SOAP fault sent from the .NET client to the Metro endpoint. Admittedly, this is strange, but should be filed as a separate issue against Metro core (JAX-WS RI) IMHO.
glassfishrobot
commented
15 years ago joe_roberts_z@java.net said: Hi Marek,
I have gone over my CSharp client example and tunneled the request / response sequence and I have then gone over an example that uses a java metro client and looked at the request / response sequence for it. The difference:
For the java client, here is the sequence:
1 - CreateSequence request 2 - CreateSequence response 3 - Request sent 4 - Response sent 5 - LastMessage request 6 - LastMessage response 7 - TerminateMessage request 8 - TerminateMessage response
For the Csharp client, here is the sequence:
1 - CreateSequence request 2 - CreateSequence response 3 - Request payload sent 4 - Response payload sent 5 - Request sent again 6 - Response payload sent again 7 - Request with fault sent from client complaining about WS-Addressing action 8 - HTTP 500 response echoing the message from the client
I guess the questions I have are the following:
Do you have a test case with a WCF client that uses MTOM and WS-RM to talk to a Metro Web service and that shows the correct sequence and the WCF client doesn't send the request payload twice? That is the root of the problem, but I cannot find an example that shows how to do this and get it to work?
How do you guys test this?
glassfishrobot
commented
15 years ago joe_roberts_z@java.net said: Created an attachment (id=992) See this message sequence with the new jars - it shows everything is fine and works when the first request is submitted after starting tomcat
glassfishrobot
commented
15 years ago joe_roberts_z@java.net said: Created an attachment (id=993) See this message sequence with the new jars - it shows an error - I believe because the client code sends the LastMessage request but Metor doesn't send the LastMessage response...this is the second request after startup...all requests that follow the first one after startup generate the same error...I will attach the new zip file to reproduce this in a second.
glassfishrobot
commented
15 years ago joe_roberts_z@java.net said: Created an attachment (id=994) Here is the project to recreate the issue
glassfishrobot
commented
15 years ago joe_roberts_z@java.net said: More info:
It looks like the WCF client sends a second request payload when proxy.Close() is not called. Furthermore, if proxy.Close() is called, it produces the last sequence i submitted in the following attachment I submitted today:
Fri Aug 28 14:20:00 +0000 2009: second-message-sequence-after-startup-with-new- jars-error
However, if I put a Console.ReadLine() statement before proxy.Close() in the WCF client to force the program to wait for the end user to press enter before calling proxy.Close(), then the sequence terminates correctly every time, so it seems to me that when Proxy.Close() is not called there is problem and when it is called there is a problem. How should I resolve this? How do you guys resolve this when you test? BTW, I also tested with Aug 28, 2009 nightly build and the error is the same.
glassfishrobot
commented
15 years ago joe_roberts_z@java.net said: OK,
I have finally recreated the original issue I reported in my application but with the fromwsdl application. See this last fromwsdl.zip attachment. It contains the code you need to recreate this.
Here is the issue:
When the service implementation takes more than a few milliseconds, lets say a few seconds, the first WS-RM request from the WCF client after startup of Tomcat works. Any request type that comes in thereafter fails because the WCF client ends up sending the request twice.
Summary:
1- Start Tomcat 2 - 1st WCF client request works. 3 - 2nd WCF client request fails and any consecutive request fails. 4 - If I take the sleep call in the service implementation code for metro the WCF client works every time. 5 - If proxy.Close() is used in WCF client there is an exception thrown in Metro. 6 - If proxy.Close() is not used in WCF client, the client never sends LastMessage request and instead sends the request payload again.
Questions:
1 - How do I solve #3 and #4?
2 - How do I solve #5 and #6?
glassfishrobot
commented
15 years ago joe_roberts_z@java.net said: Created an attachment (id=995) Here is the final project to recreate the issue
glassfishrobot
commented
15 years ago m_potociar@java.net said: Hi Joe, I was busy with some different stuff in the end of the last week. Resuming my work on this issue now.
Just a short answer to your question on an example of WCF-Metro RM and MTOM-enabled communication: I am afraid, there's no such example available as of today. As for interop testing with .NET, there is a set of common interoperability tests that we execute. I don't think that any of these RM interop tests involves MTOM, unfortunately.
glassfishrobot
commented
15 years ago m_potociar@java.net said: I have a fix on the main trunk that is tested against the final project that reproduces the issue. With the fix the communication works again.
Problem description:
The issue we saw relates to a set of very specific conditions: 1. client sends a duplicate of the very first application message 2. the server side processing takes relatively long time 3. because of 2, when the duplicate arrives to the service, the response is not available yet
Conditions 1, 2 and 3 imply that when a duplicate message arrives, there is nothing to acknowledge yet. Under these circumstances, when Metro tried to behave according to Replay model ( https://www.wso2.org/library/2792 ) and would send a SequenceAcknowledgement back to the WCF client, it would generate incorrect SequenceAcknowledgement message with a missing SequenceAcknowledgement SOAP header. This would be then refused by WCF client which would generate a SOAP fault and send it to the server. This SOAP fault would then bounce back[1] without ever reaching RM server tube and eventually cause the exception we saw on the WCF client side.
Resolution: The fix makes sure that under conditions described above, Metro RM does not try to generate a sequence acknowledgment, but instead sends back a null (empty) response, which is accepted by the WCF client without any complaints.
As for why the WCF client always sends duplicate messages - I don't know. This seems to be an implementation detail of WCF framework. I will follow up with MS engineers on that.
Marek
[1] This behavior is questionable and I am going to file a separate issue against Metro core.
glassfishrobot
commented
15 years ago m_potociar@java.net said: Filed JAXWS RI issue to cover bouncing SOAP faults off Metro endpoints: https://jax-ws.dev.java.net/issues/show_bug.cgi?id=797
glassfishrobot
commented
14 years ago m_potociar@java.net said: Updated target milestone
glassfishrobot
commented
15 years ago File: csharp-client.zip Attached By: joe_roberts_z@java.net
glassfishrobot
commented
15 years ago File: DocumakerService-Loader-Catalina.jar Attached By: joe_roberts_z@java.net
glassfishrobot
commented
15 years ago File: first-message-sequence-after-startup-with-new-jars Attached By: joe_roberts_z@java.net
glassfishrobot
commented
15 years ago File: fromwsdl.zip Attached By: joe_roberts_z@java.net
glassfishrobot
commented
15 years ago File: fromwsdl.zip Attached By: joe_roberts_z@java.net
glassfishrobot
commented
15 years ago File: fromwsdl.zip Attached By: joe_roberts_z@java.net
glassfishrobot
commented
15 years ago File: message-exchange.txt Attached By: m_potociar@java.net
glassfishrobot
commented
15 years ago File: second-message-sequence-after-startup-with-new-jars-error Attached By: joe_roberts_z@java.net
glassfishrobot
commented
15 years ago Was assigned to m_potociar@java.net
glassfishrobot
commented
7 years ago This issue was imported from java.net JIRA WSIT-1216
glassfishrobot
commented
14 years ago Marked as fixed on Wednesday, June 16th 2010, 7:37:53 pm
When using the latest 2.0 nightly build dated August 20, 2009 with WS-RM from a WCF client, the following sequence and fault is generated which causes for the WCF client to not receive the response from the web service:
--[HTTP request]-- Host: localhost:8080 Content-type: multipart/related; type="application/xop+xml";start="<http://tempuri.org/0>";boundary="uuid:6eb4331 a-497e-4584-8e18-49d8e0db5ec0+id=1";start-info="applicati on/soap+xml" Content-length: 935 Connection: Keep-Alive Mime-version: 1.0 Expect: 100-continue
--uuid:6eb4331a-497e-4584-8e18-49d8e0db5ec0+id=1 Content-ID: <http://tempuri.org/0> Content-Transfer-Encoding: 8bit Content-Type: application/xop+xml;charset=utf-8;type="application/soap+xml"
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"><a:Action
s:mustUnderstand="1">http://schemas.xmlso
ap.org/ws/2005/02/rm/CreateSequence</a:Action>urn:uuid:48f1d67e-
3d73-4e6c-b76d-bca8c7fec3f0</a:MessageID><a:To
s:mustUnderstand="1">http://localhost:8080/Doc
umakerService/DocumakerServiceSoap12WSRM</a:To></s:Header><CreateSequenc
e
xmlns="http://schemas.xmlsoap.org/ws/2005/02/rm">http://www.w
3.org/20
05/08/addressing/anonymous</a:Address> urn:uuid:619d8
3cf-46b5-4773-b322-
459001588442
<?xml version='1.0' encoding='UTF-8'?><S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"><To
xmlns="http://www.w3.org/2005/08/addressing">[http://www](http://www).
w3.org/2005/08/addressing/anonymous<Action
xmlns="http://www.w3.org/2005/08/addressing">[http://schemas.xmlsoap.org/ws/2005/](http://schemas.xmlsoap.org/ws/2005/)
02/rm/CreateSequenceResponse<Mess
ageID xmlns="http://www.w3.org/2005/08/addressing">uuid:ddc05585-0a44-4e3d-8606-
cee7184b5a27<RelatesTo
xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:4
8f1d67e-3d73-4e6c-b76d-
bca8c7fec3f0</S:Header><ns3:CreateSequenceResponse
xmlns:ns2="http://www.w3.org/2005/08/addressing" xmlns:ns3="http://schemas.x
mlsoap.org/ws/2005/02/rm" xmlns:ns4="http://docs.oasis-
open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:ns5="http://docs.oasis-open.org/wss/2004/01/
oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:ns6="http://schemas.microsoft.com/ws/2006/05/rm">uuid:dd66
6eb4-6917-49d8-8f4e-8f1509cfdd23</ns3:Identif
ier>http://localhost:8080/DocumakerService/
DocumakerServiceSoap12WSRM</ns2:Address></ns3:AcksTo></ns3:Accept></ns3:CreateSe
quenceResp
onse></S:Body></S:Envelope>
-uuid:c3802170-ff2a-4030-b78f-15f708f9b3c0---------------------
--[HTTP request]--
Host: localhost:8080
Content-type: multipart/related;
type="application/xop+xml";start="<http://tempuri.org/0>";boundary="uuid:6eb4331
a-497e-4584-8e18-49d8e0db5ec0+id=2";start-info="applicati
on/soap+xml"
Content-length: 1275
Mime-version: 1.0
Expect: 100-continue
--uuid:6eb4331a-497e-4584-8e18-49d8e0db5ec0+id=2 Content-ID: <http://tempuri.org/0> Content-Transfer-Encoding: 8bit Content-Type: application/xop+xml;charset=utf-8;type="application/soap+xml"
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:r="http://schemas.xmlsoap.org/ws/2005/02/rm" xmlns:a="http://www.w3.org/2005/08/addressing">
s:Sendera:ActionNotSupported The action [http://schemas.xmlsoap.org/ws/2005/02/rm/SequenceAcknowledgement](http://schemas.xmlsoap.org/ws/2005/02/rm/SequenceAcknowledgement) is not supported by this endpoint. Only WS-ReliableMessaging February 2 005 messages are processed by this endpoint.