cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Kulp (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CXF-2690) Oneway MEP with fastInfoset without 'force' results in no compression
Date Tue, 09 Mar 2010 01:51:27 GMT

    [ 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.


Mime
View raw message