thanks, I'd looked at the blog before, I don't believe it has anything I haven't already implemented.
In terms of wireshark, I had also tried that before but none of the contents were comprehensible to me so I was not really able to tell what was or wasn't gzipped. I even moved it from https to http to try to get the contents in a relatively "plain text" format so I can see when it was not compressed and when it was, but I could never get the plain text version so I was not able to determine a change... it's the first time I'd used wireshark though, that's why I tried to look at the header instead. The header shows up on larger packets so I suspect at least for the threshold problem on out bound messages, it should be an indication of when it is and is not gzipped. I'll spend some more time with wireshark and see if I can't figure out how to use it a little better though. thanks. On 3/13/13, Daniel Kulp <[email protected]> wrote: > > 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 > > -- Ted.
