cxf-issues mailing list archives

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

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


Mime
View raw message