[servicemix-user] Problem with HTTPConnector/HTTPInvoker sequences

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[servicemix-user] Problem with HTTPConnector/HTTPInvoker sequences

Michael Studman-2

Hi,

 

For laughs I decided to extend the basic HTTP example and sequence a number of HTTPConnector/HTTPInvoker pairs terminated by a TraceComponent like this…

 

HTTPClient -> (localhost:8912)HTTPConnector -> HTTPInvoker –> (localhost:8913)HTTPConnector -> HTTPInvoker -> (localhost:8914)HTTPConnector -> TraceComponent

 

…I’m finding this doesn’t work as somewhere along the chain the XML content is being corrupted. I’ve attached the servicemix-longerchain.xml I’m using and the output-longerchain.log that’s generated. After playing around a bit with the following configuration sequence:

 

HTTPClient -> (localhost:8912)HTTPConnector -> HTTPInvoker -> (localhost:8913)HTTPConnector  -> TraceComponent

 

…I’m finding the TraceComponent is receiving what seems to be truncated XML which causes the identity XSLT transformation that does the tracing to fail. The first HTTPConnector seems to receive the XML sent so it looks like it’s either the first HTTPInvoker or the second HTTPConnecter that individually fail in some way or fail together. servicemix-shorterchain.xml and output-shorterchain.log are attached also.

 

Any ideas on this or where I’ve gone wrong?

 

Michael.


servicemix-shorterchain.xml (2K) Download Attachment
output-longerchain.log.zip (2K) Download Attachment
output-shorterchain.log.zip (2K) Download Attachment
servicemix-longerchain.xml (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [servicemix-user] Problem with HTTPConnector/HTTPInvoker sequences

Michael Studman-2

I’ve discovered the problem here: XML truncation because HTTPInvoker does an XML transform that has a side-effect of eliminating insignificant whitespace on the input message but reuses the original HTTP header value for “Content-Length” when sending the transformed XML.

 

Although my example is contrived, I can see this being a problem in real situations. If there is a sequence of services with a HTTPComponent on one end and a HTTPInvoker somewhere in the chain, and all services in-between copy NormalizedMessage properties at each stage then this truncation will occur and be rather hard to diagnose, I imagine.

 

I’ll raise a JIRA issue.

 

Michael.

 


From: Michael Studman [mailto:[hidden email]]
Sent: 02 November 2005 11:23
To: [hidden email]
Subject: [servicemix-user] Problem with HTTPConnector/HTTPInvoker sequences

 

Hi,

 

For laughs I decided to extend the basic HTTP example and sequence a number of HTTPConnector/HTTPInvoker pairs terminated by a TraceComponent like this…

 

HTTPClient -> (localhost:8912)HTTPConnector -> HTTPInvoker –> (localhost:8913)HTTPConnector -> HTTPInvoker -> (localhost:8914)HTTPConnector -> TraceComponent

 

…I’m finding this doesn’t work as somewhere along the chain the XML content is being corrupted. I’ve attached the servicemix-longerchain.xml I’m using and the output-longerchain.log that’s generated. After playing around a bit with the following configuration sequence:

 

HTTPClient -> (localhost:8912)HTTPConnector -> HTTPInvoker -> (localhost:8913)HTTPConnector  -> TraceComponent

 

…I’m finding the TraceComponent is receiving what seems to be truncated XML which causes the identity XSLT transformation that does the tracing to fail. The first HTTPConnector seems to receive the XML sent so it looks like it’s either the first HTTPInvoker or the second HTTPConnecter that individually fail in some way or fail together. servicemix-shorterchain.xml and output-shorterchain.log are attached also.

 

Any ideas on this or where I’ve gone wrong?

 

Michael.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [servicemix-user] Problem with HTTPConnector/HTTPInvoker sequences

Rob Davies-2
Good find! 

Thanks Michael

On 2 Nov 2005, at 18:36, Michael Studman wrote:

I’ve discovered the problem here: XML truncation because HTTPInvoker does an XML transform that has a side-effect of eliminating insignificant whitespace on the input message but reuses the original HTTP header value for “Content-Length” when sending the transformed XML.

 

Although my example is contrived, I can see this being a problem in real situations. If there is a sequence of services with a HTTPComponent on one end and a HTTPInvoker somewhere in the chain, and all services in-between copy NormalizedMessage properties at each stage then this truncation will occur and be rather hard to diagnose, I imagine.

 

I’ll raise a JIRA issue.

 

Michael.

 


From: Michael Studman [[hidden email]]
Sent: 02 November 2005 11:23
To: [hidden email]
Subject: [servicemix-user] Problem with HTTPConnector/HTTPInvoker sequences

 

Hi,

 

For laughs I decided to extend the basic HTTP example and sequence a number of HTTPConnector/HTTPInvoker pairs terminated by a TraceComponent like this…

 

HTTPClient -> (localhost:8912)HTTPConnector -> HTTPInvoker –> (localhost:8913)HTTPConnector -> HTTPInvoker -> (localhost:8914)HTTPConnector -> TraceComponent

 

…I’m finding this doesn’t work as somewhere along the chain the XML content is being corrupted. I’ve attached the servicemix-longerchain.xml I’m using and the output-longerchain.log that’s generated. After playing around a bit with the following configuration sequence:

 

HTTPClient -> (localhost:8912)HTTPConnector -> HTTPInvoker -> (localhost:8913)HTTPConnector  -> TraceComponent

 

…I’m finding the TraceComponent is receiving what seems to be truncated XML which causes the identity XSLT transformation that does the tracing to fail. The first HTTPConnector seems to receive the XML sent so it looks like it’s either the first HTTPInvoker or the second HTTPConnecter that individually fail in some way or fail together. servicemix-shorterchain.xml and output-shorterchain.log are attached also.

 

Any ideas on this or where I’ve gone wrong?

 

Michael.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [servicemix-user] Problem with HTTPConnector/HTTPInvoker sequences

Michael Studman-2
In reply to this post by Michael Studman-2

Thanks! I’ve added SM-141 to Jira.

 


From: Rob Davies [mailto:[hidden email]]
Sent: 02 November 2005 18:45
To: [hidden email]
Subject: Re: [servicemix-user] Problem with HTTPConnector/HTTPInvoker sequences

 

Good find! 

 

Thanks Michael

 

On 2 Nov 2005, at 18:36, Michael Studman wrote:



I’ve discovered the problem here: XML truncation because HTTPInvoker does an XML transform that has a side-effect of eliminating insignificant whitespace on the input message but reuses the original HTTP header value for “Content-Length” when sending the transformed XML.

 

Although my example is contrived, I can see this being a problem in real situations. If there is a sequence of services with a HTTPComponent on one end and a HTTPInvoker somewhere in the chain, and all services in-between copy NormalizedMessage properties at each stage then this truncation will occur and be rather hard to diagnose, I imagine.

 

I’ll raise a JIRA issue.

 

Michael.

 


From: Michael Studman [[hidden email]]
Sent: 02 November 2005 11:23
To: [hidden email]
Subject: [servicemix-user] Problem with HTTPConnector/HTTPInvoker sequences

 

Hi,

 

For laughs I decided to extend the basic HTTP example and sequence a number of HTTPConnector/HTTPInvoker pairs terminated by a TraceComponent like this…

 

HTTPClient -> (localhost:8912)HTTPConnector -> HTTPInvoker –> (localhost:8913)HTTPConnector -> HTTPInvoker -> (localhost:8914)HTTPConnector -> TraceComponent

 

…I’m finding this doesn’t work as somewhere along the chain the XML content is being corrupted. I’ve attached the servicemix-longerchain.xml I’m using and the output-longerchain.log that’s generated. After playing around a bit with the following configuration sequence:

 

HTTPClient -> (localhost:8912)HTTPConnector -> HTTPInvoker -> (localhost:8913)HTTPConnector  -> TraceComponent

 

…I’m finding the TraceComponent is receiving what seems to be truncated XML which causes the identity XSLT transformation that does the tracing to fail. The first HTTPConnector seems to receive the XML sent so it looks like it’s either the first HTTPInvoker or the second HTTPConnecter that individually fail in some way or fail together. servicemix-shorterchain.xml and output-shorterchain.log are attached also.

 

Any ideas on this or where I’ve gone wrong?

 

Michael.



 

Loading...