You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Reinis Vicups (JIRA)" <ji...@apache.org> on 2010/03/04 10:10:29 UTC
[jira] Created: (CXF-2690) Oneway MEP with fastInfoset without
'force' results in no compression
Oneway MEP with fastInfoset without 'force' results in no compression
---------------------------------------------------------------------
Key: CXF-2690
URL: https://issues.apache.org/jira/browse/CXF-2690
Project: CXF
Issue Type: Bug
Components: OtherDatabindings, Transports
Affects Versions: 2.2.6
Environment: Windows Vista
jdk1.6.0_07
Reporter: Reinis Vicups
If a fastInfoset (accept=application/fastinfoset) @Oneway Message is sent to the Server and 'force' option of the fastInfoset is not set to 'true', the server would give 202 response and would use content-type: text/xml like this:
15:04:33,000 DEBUG [main] cxf.transport.http.HTTPConduit (2132) - Header fields:
null: [HTTP/1.1 202 Accepted]
Content-Length: [0]
Content-Type: [text/xml]
Server: [Jetty(6.1.21)]
I am not sure if this is the consequence of server answering with text/xml, but as a result the client issues all of the following requests with text/xml aswell instead of switching to application/fastinfoset.
Per definition fastinfoset works like this:
1. client requests server with content-type:text/xml but indicates that it (client) accept:application/fastinfoset;
2. server responds with content-type:application/fastinfoset
3. all the following requests from client to server will be with content-type:application/fastinfoset
Additional info that might be relevant:
- I have tested with multiple messages (not just two)
- All messages were sent from the same instance of client and received by the same instance of server (no new instances were created)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-2690) Oneway MEP with fastInfoset without
'force' results in no compression
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Kulp resolved CXF-2690.
------------------------------
Resolution: Not A Problem
Fix Version/s: Invalid
Assignee: Daniel Kulp
Resolved as it's working properly.
The clients work fine with the 202 without the Content-Type. I updated the server side code to not generate the Content-Type for the 202 response and all the clients are fine.
> Oneway MEP with fastInfoset without 'force' results in no compression
> ---------------------------------------------------------------------
>
> Key: CXF-2690
> URL: https://issues.apache.org/jira/browse/CXF-2690
> Project: CXF
> Issue Type: Bug
> Components: OtherDatabindings, Transports
> Affects Versions: 2.2.6
> Environment: Windows Vista
> jdk1.6.0_07
> Reporter: Reinis Vicups
> Assignee: Daniel Kulp
> Fix For: Invalid
>
>
> If a fastInfoset (accept=application/fastinfoset) @Oneway Message is sent to the Server and 'force' option of the fastInfoset is not set to 'true', the server would give 202 response and would use content-type: text/xml like this:
> 15:04:33,000 DEBUG [main] cxf.transport.http.HTTPConduit (2132) - Header fields:
> null: [HTTP/1.1 202 Accepted]
> Content-Length: [0]
> Content-Type: [text/xml]
> Server: [Jetty(6.1.21)]
> I am not sure if this is the consequence of server answering with text/xml, but as a result the client issues all of the following requests with text/xml aswell instead of switching to application/fastinfoset.
> Per definition fastinfoset works like this:
> 1. client requests server with content-type:text/xml but indicates that it (client) accept:application/fastinfoset;
> 2. server responds with content-type:application/fastinfoset
> 3. all the following requests from client to server will be with content-type:application/fastinfoset
> Additional info that might be relevant:
> - I have tested with multiple messages (not just two)
> - All messages were sent from the same instance of client and received by the same instance of server (no new instances were created)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2690) Oneway MEP with fastInfoset without
'force' results in no compression
Posted by "Reinis Vicups (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842966#action_12842966 ]
Reinis Vicups commented on CXF-2690:
------------------------------------
Humm,
I am wondering what does the 'port.doBug2692("foo")' does? If its a Twoway message then it's no wonder that you are unable to replicate since Twoway messages have always worked with fastinfoset.
I posted this ticket because testcase like this:
port.doOneWay();
port.doOneWay();
port.doOneWay(); <- still no fastinfoset
port.doOneWay(); <- still no fastinfoset
port.doOneWay(); <- still no fastinfoset
port.doOneWay(); <- still no fastinfoset
port.doOneWay(); <- still no fastinfoset
does not work for me. I have use case where the port.doOneWay() is beeing called bulk and my problem is that the batch of 10000 calls to port.doOneWay() going over the wire without FI produces too much trafic and takes too long for my taste :)
> Oneway MEP with fastInfoset without 'force' results in no compression
> ---------------------------------------------------------------------
>
> Key: CXF-2690
> URL: https://issues.apache.org/jira/browse/CXF-2690
> Project: CXF
> Issue Type: Bug
> Components: OtherDatabindings, Transports
> Affects Versions: 2.2.6
> Environment: Windows Vista
> jdk1.6.0_07
> Reporter: Reinis Vicups
>
> If a fastInfoset (accept=application/fastinfoset) @Oneway Message is sent to the Server and 'force' option of the fastInfoset is not set to 'true', the server would give 202 response and would use content-type: text/xml like this:
> 15:04:33,000 DEBUG [main] cxf.transport.http.HTTPConduit (2132) - Header fields:
> null: [HTTP/1.1 202 Accepted]
> Content-Length: [0]
> Content-Type: [text/xml]
> Server: [Jetty(6.1.21)]
> I am not sure if this is the consequence of server answering with text/xml, but as a result the client issues all of the following requests with text/xml aswell instead of switching to application/fastinfoset.
> Per definition fastinfoset works like this:
> 1. client requests server with content-type:text/xml but indicates that it (client) accept:application/fastinfoset;
> 2. server responds with content-type:application/fastinfoset
> 3. all the following requests from client to server will be with content-type:application/fastinfoset
> Additional info that might be relevant:
> - I have tested with multiple messages (not just two)
> - All messages were sent from the same instance of client and received by the same instance of server (no new instances were created)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-2690) Oneway MEP with fastInfoset without
'force' results in no compression
Posted by "Reinis Vicups (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Reinis Vicups closed CXF-2690.
------------------------------
> Oneway MEP with fastInfoset without 'force' results in no compression
> ---------------------------------------------------------------------
>
> Key: CXF-2690
> URL: https://issues.apache.org/jira/browse/CXF-2690
> Project: CXF
> Issue Type: Bug
> Components: OtherDatabindings, Transports
> Affects Versions: 2.2.6
> Environment: Windows Vista
> jdk1.6.0_07
> Reporter: Reinis Vicups
> Assignee: Daniel Kulp
> Fix For: Invalid
>
>
> If a fastInfoset (accept=application/fastinfoset) @Oneway Message is sent to the Server and 'force' option of the fastInfoset is not set to 'true', the server would give 202 response and would use content-type: text/xml like this:
> 15:04:33,000 DEBUG [main] cxf.transport.http.HTTPConduit (2132) - Header fields:
> null: [HTTP/1.1 202 Accepted]
> Content-Length: [0]
> Content-Type: [text/xml]
> Server: [Jetty(6.1.21)]
> I am not sure if this is the consequence of server answering with text/xml, but as a result the client issues all of the following requests with text/xml aswell instead of switching to application/fastinfoset.
> Per definition fastinfoset works like this:
> 1. client requests server with content-type:text/xml but indicates that it (client) accept:application/fastinfoset;
> 2. server responds with content-type:application/fastinfoset
> 3. all the following requests from client to server will be with content-type:application/fastinfoset
> Additional info that might be relevant:
> - I have tested with multiple messages (not just two)
> - All messages were sent from the same instance of client and received by the same instance of server (no new instances were created)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2690) Oneway MEP with fastInfoset without
'force' results in no compression
Posted by "Reinis Vicups (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842992#action_12842992 ]
Reinis Vicups commented on CXF-2690:
------------------------------------
Yes,
I agree that Content-Type in response was not appropriate. Daniel, did you had chance to test how does CXF-client client react if it gets 202 without neither content nor content-type supplied?
P.S. I guess this ticket can be closed now.
> Oneway MEP with fastInfoset without 'force' results in no compression
> ---------------------------------------------------------------------
>
> Key: CXF-2690
> URL: https://issues.apache.org/jira/browse/CXF-2690
> Project: CXF
> Issue Type: Bug
> Components: OtherDatabindings, Transports
> Affects Versions: 2.2.6
> Environment: Windows Vista
> jdk1.6.0_07
> Reporter: Reinis Vicups
>
> If a fastInfoset (accept=application/fastinfoset) @Oneway Message is sent to the Server and 'force' option of the fastInfoset is not set to 'true', the server would give 202 response and would use content-type: text/xml like this:
> 15:04:33,000 DEBUG [main] cxf.transport.http.HTTPConduit (2132) - Header fields:
> null: [HTTP/1.1 202 Accepted]
> Content-Length: [0]
> Content-Type: [text/xml]
> Server: [Jetty(6.1.21)]
> I am not sure if this is the consequence of server answering with text/xml, but as a result the client issues all of the following requests with text/xml aswell instead of switching to application/fastinfoset.
> Per definition fastinfoset works like this:
> 1. client requests server with content-type:text/xml but indicates that it (client) accept:application/fastinfoset;
> 2. server responds with content-type:application/fastinfoset
> 3. all the following requests from client to server will be with content-type:application/fastinfoset
> Additional info that might be relevant:
> - I have tested with multiple messages (not just two)
> - All messages were sent from the same instance of client and received by the same instance of server (no new instances were created)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2690) Oneway MEP with fastInfoset without
'force' results in no compression
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842971#action_12842971 ]
Daniel Kulp commented on CXF-2690:
----------------------------------
Ah. Ok.
Then this is more or less working as designed/per spec. On a one-way, the response is supposed to be a 202 Accepted without any content. There should not be Content-Type header at all (which I just fixed) as there is no content. Thus, there wouldn't be a way for the "negotiation" stuff to kick in with one-ways.
> Oneway MEP with fastInfoset without 'force' results in no compression
> ---------------------------------------------------------------------
>
> Key: CXF-2690
> URL: https://issues.apache.org/jira/browse/CXF-2690
> Project: CXF
> Issue Type: Bug
> Components: OtherDatabindings, Transports
> Affects Versions: 2.2.6
> Environment: Windows Vista
> jdk1.6.0_07
> Reporter: Reinis Vicups
>
> If a fastInfoset (accept=application/fastinfoset) @Oneway Message is sent to the Server and 'force' option of the fastInfoset is not set to 'true', the server would give 202 response and would use content-type: text/xml like this:
> 15:04:33,000 DEBUG [main] cxf.transport.http.HTTPConduit (2132) - Header fields:
> null: [HTTP/1.1 202 Accepted]
> Content-Length: [0]
> Content-Type: [text/xml]
> Server: [Jetty(6.1.21)]
> I am not sure if this is the consequence of server answering with text/xml, but as a result the client issues all of the following requests with text/xml aswell instead of switching to application/fastinfoset.
> Per definition fastinfoset works like this:
> 1. client requests server with content-type:text/xml but indicates that it (client) accept:application/fastinfoset;
> 2. server responds with content-type:application/fastinfoset
> 3. all the following requests from client to server will be with content-type:application/fastinfoset
> Additional info that might be relevant:
> - I have tested with multiple messages (not just two)
> - All messages were sent from the same instance of client and received by the same instance of server (no new instances were created)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2690) Oneway MEP with fastInfoset without
'force' results in no compression
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842872#action_12842872 ]
Daniel Kulp commented on CXF-2690:
----------------------------------
I'm not able to reproduce this with 2.3.0-SNAPSHOT code. A testcase of something like:
port.doOneWay();
port.doOneWay();
port.doBug2692("foo");
port.doBug2692("foo");
port.doOneWay();
port.doBug2692("foo");
Is resulting in the third request coming back in FI and thus enabling all furthur interacions to be FI.
> Oneway MEP with fastInfoset without 'force' results in no compression
> ---------------------------------------------------------------------
>
> Key: CXF-2690
> URL: https://issues.apache.org/jira/browse/CXF-2690
> Project: CXF
> Issue Type: Bug
> Components: OtherDatabindings, Transports
> Affects Versions: 2.2.6
> Environment: Windows Vista
> jdk1.6.0_07
> Reporter: Reinis Vicups
>
> If a fastInfoset (accept=application/fastinfoset) @Oneway Message is sent to the Server and 'force' option of the fastInfoset is not set to 'true', the server would give 202 response and would use content-type: text/xml like this:
> 15:04:33,000 DEBUG [main] cxf.transport.http.HTTPConduit (2132) - Header fields:
> null: [HTTP/1.1 202 Accepted]
> Content-Length: [0]
> Content-Type: [text/xml]
> Server: [Jetty(6.1.21)]
> I am not sure if this is the consequence of server answering with text/xml, but as a result the client issues all of the following requests with text/xml aswell instead of switching to application/fastinfoset.
> Per definition fastinfoset works like this:
> 1. client requests server with content-type:text/xml but indicates that it (client) accept:application/fastinfoset;
> 2. server responds with content-type:application/fastinfoset
> 3. all the following requests from client to server will be with content-type:application/fastinfoset
> Additional info that might be relevant:
> - I have tested with multiple messages (not just two)
> - All messages were sent from the same instance of client and received by the same instance of server (no new instances were created)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.