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