Thanks, I'm not trying to force the first one to be GZ, but the
problem is the second one doesn't appear to be GZ either.

Just to test it, I hard coded 2 identical calls in succession :

        
System.err.println(messageWs.getUnreadActiveMessageCount(loggedInInfo.getLoggedInPersonId()));
        
System.err.println(messageWs.getUnreadActiveMessageCount(loggedInInfo.getLoggedInPersonId()));

The out put from the logs appear to be non gz-ed :
        2013-03-12 11:31:14,818 INFO  [MessageWs:234] Inbound Message
        ----------------------------
        ID: 38
        Address: https://127.0.0.1:8091/myoscar_server/ws/MessageService
        Encoding: UTF-8
        Http-Method: POST
        Content-Type: text/xml; charset=UTF-8
        Headers: {Accept=[*/*], accept-encoding=[gzip;q=1.0, identity; q=0.5,
*;q=0], cache-control=[no-cache], connection=[keep-alive],
Content-Length=[785], content-type=[text/xml; charset=UTF-8],
host=[127.0.0.1:8091], pragma=[no-cache], SOAPAction=[""],
user-agent=[Apache CXF 2.7.3]}
        Payload: <soap:Envelope ... </soap:Envelope>
        --------------------------------------
        2013-03-12 11:31:14,834 INFO  [MessageWs:234] Outbound Message
        ---------------------------
        ID: 38
        Encoding: UTF-8
        Content-Type: text/xml
        Headers:
        Payload: <soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";><soap:Body><ns2:getUnreadActiveMessageCountResponse
xmlns:ns2="http://ws.myoscar_server.oscarehr.org/";><return>31</return></ns2:getUnreadActiveMessageCountResponse></soap:Body></soap:Envelope>
        --------------------------------------
        2013-03-12 11:31:14,841 INFO  [MessageWs:234] Inbound Message
        ----------------------------
        ID: 39
        Address: https://127.0.0.1:8091/myoscar_server/ws/MessageService
        Encoding: UTF-8
        Http-Method: POST
        Content-Type: text/xml; charset=UTF-8
        Headers: {Accept=[*/*], accept-encoding=[gzip;q=1.0, identity; q=0.5,
*;q=0], cache-control=[no-cache], connection=[keep-alive],
Content-Length=[785], content-type=[text/xml; charset=UTF-8],
host=[127.0.0.1:8091], pragma=[no-cache], SOAPAction=[""],
user-agent=[Apache CXF 2.7.3]}
        Payload: <soap:Envelope ... </soap:Envelope>
        --------------------------------------
        2013-03-12 11:31:14,855 INFO  [MessageWs:234] Outbound Message
        ---------------------------
        ID: 39
        Encoding: UTF-8
        Content-Type: text/xml
        Headers:
        Payload: <soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";><soap:Body><ns2:getUnreadActiveMessageCountResponse
xmlns:ns2="http://ws.myoscar_server.oscarehr.org/";><return>31</return></ns2:getUnreadActiveMessageCountResponse></soap:Body></soap:Envelope>
        --------------------------------------


I'm assuming I should have seen a "Content-Encoding=[gzip]" in the
header somewhere if it were gz-ed?

Just to see if it's related to the 1k theshold problem, I did a 4k
message test too, still same header results, no gz.

I also tried your suggestion just to test :

        GZIPOutInterceptor x = new GZIPOutInterceptor(100);
        x.setForce(true);
        System.err.println("----- JUST SET FORCE TRUE");
        cxfClient.getOutInterceptors().add(x);

still the same results. Is it suppose to show
"Content-Encoding=[gzip]" on the inbound requests? or is there another
way to check for gz?

Also the outbound requests are not taking the threshold into account,
it seems to be 1k no matter what I set it to. Notice the responses
from above are also missing the gzip entry in the header, I do get
those on larger outbound objects though so I know the setting is at
least taking effect sometimes.

On 3/12/13, Daniel Kulp <[email protected]> wrote:
>
> By default, the GZIP out stuff on the client uses a "negotiated" method
> where the first request is not-gzipped, but with the Accept-Encoding header
> since it does not know if the server knows how to handle a GZIP post.   If
> the server responds with a GZIP response, subsequent requests from that
> client will be gzipped.     Try making multiple calls with the same client
> object and see if the headers and such change.
>
> You can force the first request to be gzipped by doing:
>
> GZIPOutInterceptor gz = new GZIPOutInterceptor(128)
> gz.setForce(true);
> client.getOutInterceptors().add(gz);
>
> Hope that helps!
>
> Dan
>
>
>
> On Mar 11, 2013, at 12:22 AM, Ted <[email protected]> wrote:
>
>> Hi I just tried gzip compression and it appears to be working in some
>> cases but not in others.
>> I'm on openjdk 1.7.0.3 and cxf 2.7.3 and tomcat 7.0.27.
>>
>> On the server side I've set
>>      @GZIP(threshold=128)
>> on the web services
>>
>> On the client I've set
>>      cxfClient.getInInterceptors().add(new GZIPInInterceptor());
>>      cxfClient.getOutInterceptors().add(new GZIPOutInterceptor(128));
>>
>> I'm logging what's going on with the server with :
>>      <bean id="compressGZIPFeature"
>> class="org.apache.cxf.transport.common.gzip.GZIPFeature"/>
>>      <bean id="loggingFeature"
>> class="org.apache.cxf.feature.LoggingFeature"/>
>>
>>      <cxf:bus>
>>              <cxf:features>
>>                      <ref bean="compressGZIPFeature"/>
>>                      <ref bean="loggingFeature"/>
>>              </cxf:features>
>>      </cxf:bus>
>>
>> What I can see is the client is sending
>>      Headers: {Accept-Encoding=[gzip;q=1.0, identity; q=0.5, *;q=0]}
>>
>> I can see if I have a large response (over 1k) I'm getting
>>      Headers: {Content-Encoding=[gzip], Vary=[Accept-Encoding]}
>>
>> The 2 problems I'm having is
>>
>> 1) the 128 seems to have no effect, I even tried '0' as per the
>> documentation for always on, and it does seem to work. Small data is
>> just normal / no mention of gzip encoding like the large data
>>
>> 2) The requests being sent by the client do not appear to be gziped,
>> but honestly I'm not sure how to check or what header to look for.
>> Have I missed something in the configuration?
>>
>> thanks
>> --
>> Ted.
>
> --
> Daniel Kulp
> [email protected] - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>


-- 
Ted.

Reply via email to