Can you use wireshark or similar to get the raw transfer bytes? I believe the GZIPInInterceptor would run before the LoggingInInterceptor. Thus, but the time it gets to the logging interceptor, the payload has been completely un-gzipped and the Content-Encoding header stripped off.
Dan On Mar 11, 2013, at 8:56 PM, Ted <[email protected]> wrote: > 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. -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
