SelectorThread.setCompression("on");

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

SelectorThread.setCompression("on");

Alan Williamson
Can some explain how outgoing compression is suppose to work within Grizzly?

I *think* i may have misunderstood it.  I have it set to on, and
compress anything above 15KB.   However nothing is being compressed.

I take it then when i do something like this:

    OutputBuffer buffer = response.getOutputBuffer();
    buffer.doWrite(chunk, response);

Grizzly isn't automatically compressing this if the outgoing client
supports GZIP?

does that mean i have to manage this myself?

thanks

--
Alan Williamson

  Professional Self Publishing Packages
    http://www.Blog-City.com/

  myBlog = 'http://alan.blog-city.com/';

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SelectorThread.setCompression("on");

Jeanfrancois Arcand-2
Hi Alan,

Alan Williamson wrote:

> Can some explain how outgoing compression is suppose to work within
> Grizzly?
>
> I *think* i may have misunderstood it.  I have it set to on, and
> compress anything above 15KB.   However nothing is being compressed.
>
> I take it then when i do something like this:
>
>    OutputBuffer buffer = response.getOutputBuffer();
>    buffer.doWrite(chunk, response);
>
> Grizzly isn't automatically compressing this if the outgoing client
> supports GZIP?

Yes, via its output filter

https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/tcp/http11/filters/GzipOutputFilter.html
>
> does that mean i have to manage this myself?

No grizzly supports it (at least in GlassFish :-))

http://weblogs.java.net/blog/jfarcand/archive/2006/06/enabling_http_c_1.html

How did you configure it exactly? If it doesn't work, it probably
because of a bug. Last week I've ported some final fix from 1.0 which we
missed. Which version of Grizzly are you using?

Thanks

-- Jeanfrancois



>
> thanks
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SelectorThread.setCompression("on");

Alan Williamson
aaah, well i am writing my own response out with the following:

------------------------

        public void send(Response response) throws IOException {
                try{
               
                        response.setCharacterEncoding("UTF-8");
            response.setContentLength( length );
            response.setContentType( httpContentType );
            response.setStatus( httpResponseCode );
            response.setMessage( httpResponseText );
       
            if ( cookieOut != null ) response.addHeader("Set-Cookie", cookieOut );
            if ( locationOut != null ) response.addHeader("Location",
locationOut );
            if ( eTag != null ) response.addHeader( "ETag", eTag );
            if ( lastModified != null ) response.addHeader( "Last-Modified",
DateUtil.getHttpDate(lastModified) );
       
            if ( !bSendHeaderOnly ){
                    ByteChunk chunk = new ByteChunk( length );
                    chunk.append( bodyToSend, 0, length );
                    OutputBuffer buffer = response.getOutputBuffer();
                    buffer.doWrite(chunk, response);
            }

                }finally{
                        response.finish();
                }
        }
------------------------

so it does seem to suggest that i have to manage this myself,
determining if the client can accept GZIP or not

Jeanfrancois Arcand wrote:

> Hi Alan,
>
> Alan Williamson wrote:
>> Can some explain how outgoing compression is suppose to work within
>> Grizzly?
>>
>> I *think* i may have misunderstood it.  I have it set to on, and
>> compress anything above 15KB.   However nothing is being compressed.
>>
>> I take it then when i do something like this:
>>
>>    OutputBuffer buffer = response.getOutputBuffer();
>>    buffer.doWrite(chunk, response);
>>
>> Grizzly isn't automatically compressing this if the outgoing client
>> supports GZIP?
>
> Yes, via its output filter
>
> https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/tcp/http11/filters/GzipOutputFilter.html 
>
>>
>> does that mean i have to manage this myself?
>
> No grizzly supports it (at least in GlassFish :-))
>
> http://weblogs.java.net/blog/jfarcand/archive/2006/06/enabling_http_c_1.html 
>
>
> How did you configure it exactly? If it doesn't work, it probably
> because of a bug. Last week I've ported some final fix from 1.0 which we
> missed. Which version of Grizzly are you using?
>
> Thanks
>
> -- Jeanfrancois
>
>
>
>>
>> thanks
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

--
Alan Williamson

  Professional Self Publishing Packages
    http://www.Blog-City.com/

  myBlog = 'http://alan.blog-city.com/';

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SelectorThread.setCompression("on");

Jeanfrancois Arcand-2


Alan Williamson wrote:

> aaah, well i am writing my own response out with the following:
>
> ------------------------
>
>     public void send(Response response) throws IOException {
>         try{
>        
>             response.setCharacterEncoding("UTF-8");
>         response.setContentLength( length );
>         response.setContentType( httpContentType );
>         response.setStatus( httpResponseCode );
>         response.setMessage( httpResponseText );
>    
>         if ( cookieOut != null ) response.addHeader("Set-Cookie",
> cookieOut );
>         if ( locationOut != null ) response.addHeader("Location",
> locationOut );
>         if ( eTag != null ) response.addHeader( "ETag", eTag );
>         if ( lastModified != null ) response.addHeader( "Last-Modified",
> DateUtil.getHttpDate(lastModified) );
>    
>         if ( !bSendHeaderOnly ){
>             ByteChunk chunk = new ByteChunk( length );
>             chunk.append( bodyToSend, 0, length );
>             OutputBuffer buffer = response.getOutputBuffer();
>             buffer.doWrite(chunk, response);
>         }
>
>         }finally{
>             response.finish();
>         }
>     }
> ------------------------
>
> so it does seem to suggest that i have to manage this myself,
> determining if the client can accept GZIP or not

Hum..I think the client will send the appropriate header if he supports
it. Based on that header, Grizzly will GZIP the response. Class
com.sun.grizzly.http.DefaultProcessorTask has:

>     /**
>      * Check for compression
>      *
>      */
>     private boolean isCompressable(){
>         // Compression only since HTTP 1.1
>         if (! http11)
>             return false;
>
>         // Check if browser support gzip encoding
>         MessageBytes acceptEncodingMB =
>             request.getMimeHeaders().getValue("accept-encoding");
>            
>         if ((acceptEncodingMB == null)
>             || (acceptEncodingMB.indexOf("gzip") == -1))
>             return false;
>
>         // Check if content is not allready gzipped
>         MessageBytes contentEncodingMB =
>             response.getMimeHeaders().getValue("Content-Encoding");
>
>         if ((contentEncodingMB != null)
>             && (contentEncodingMB.indexOf("gzip") != -1))
>             return false;
>
>         // If force mode, allways compress (test purposes only)
>         if (compressionLevel == 2)
>            return true;
>
>         // Check for incompatible Browser
>         if (noCompressionUserAgents != null) {
>             MessageBytes userAgentValueMB =  
>                 request.getMimeHeaders().getValue("user-agent");
>             if (userAgentValueMB != null) {
>                 String userAgentValue = userAgentValueMB.toString();
>
>         if (inStringArray(noCompressionUserAgents, userAgentValue))
>         return false;
>             }
>         }
>
>         // Check if suffisant len to trig the compression        
>         int contentLength = response.getContentLength();
>         if ((contentLength == -1)
>             || (contentLength > compressionMinSize)) {
>             // Check for compatible MIME-TYPE
>             if (compressableMimeTypes != null)
>                 return (startsWithStringArray(compressableMimeTypes,
>                         response.getContentType()));
>         }
>
> return false;
>     }
>    

Hence if your client add the accept-encoding: gzip, compression should
starts. If that's not the case, then we have a bug :-)

A+

-- Jeanfrancois



>
> Jeanfrancois Arcand wrote:
>> Hi Alan,
>>
>> Alan Williamson wrote:
>>> Can some explain how outgoing compression is suppose to work within
>>> Grizzly?
>>>
>>> I *think* i may have misunderstood it.  I have it set to on, and
>>> compress anything above 15KB.   However nothing is being compressed.
>>>
>>> I take it then when i do something like this:
>>>
>>>    OutputBuffer buffer = response.getOutputBuffer();
>>>    buffer.doWrite(chunk, response);
>>>
>>> Grizzly isn't automatically compressing this if the outgoing client
>>> supports GZIP?
>>
>> Yes, via its output filter
>>
>> https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/tcp/http11/filters/GzipOutputFilter.html 
>>
>>>
>>> does that mean i have to manage this myself?
>>
>> No grizzly supports it (at least in GlassFish :-))
>>
>> http://weblogs.java.net/blog/jfarcand/archive/2006/06/enabling_http_c_1.html 
>>
>>
>> How did you configure it exactly? If it doesn't work, it probably
>> because of a bug. Last week I've ported some final fix from 1.0 which
>> we missed. Which version of Grizzly are you using?
>>
>> Thanks
>>
>> -- Jeanfrancois
>>
>>
>>
>>>
>>> thanks
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SelectorThread.setCompression("on");

Alan Williamson
> Hence if your client add the accept-encoding: gzip, compression should
> starts. If that's not the case, then we have a bug :-)

then we may have a bug!

i can't get a GZIP respoonse out no matter what i throw at it.

so with my code, it should be triggering the
com.sun.grizzly.http.DefaultProcessorTask class, even though, i am doing:
____________________________

SelectorThread st = new SelectorThread();
ByteBufferInputStream.setDefaultReadTimeout( 30000 );

st.setPort(serverPort);
st.setAdapter(this);

st.setMaxKeepAliveRequests(keepAliveRequests);
st.setKeepAliveTimeoutInSeconds(keepAliveTimeOut);

st.setCompression("on");
st.setCompressionMinSize(gzipThreshold);
____________________________

and then sending out my own response by overriding:

public void service(Request req, Response res) throws Exception {

}

yes?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SelectorThread.setCompression("on");

Oleksiy Stashok
In reply to this post by Jeanfrancois Arcand-2
Hello,

> Hum..I think the client will send the appropriate header if he
> supports it. Based on that header, Grizzly will GZIP the response.
> Class com.sun.grizzly.http.DefaultProcessorTask has:
>
>>     /**
>>      * Check for compression
>>      *
>>      */
>>     private boolean isCompressable(){
>>         // Compression only since HTTP 1.1
>>         if (! http11)
>>             return false;
>>
>>         // Check if browser support gzip encoding
>>         MessageBytes acceptEncodingMB =            
>> request.getMimeHeaders().getValue("accept-encoding");
>>                     if ((acceptEncodingMB == null)             ||
>> (acceptEncodingMB.indexOf("gzip") == -1))
>>             return false;
>>
>>         // Check if content is not allready gzipped
>>         MessageBytes contentEncodingMB =
>>             response.getMimeHeaders().getValue("Content-Encoding");
>>
>>         if ((contentEncodingMB != null)             &&
>> (contentEncodingMB.indexOf("gzip") != -1))
>>             return false;
>>
>>         // If force mode, allways compress (test purposes only)
>>         if (compressionLevel == 2)
>>            return true;
>>
>>         // Check for incompatible Browser
>>         if (noCompressionUserAgents != null) {
>>             MessageBytes userAgentValueMB =                  
>> request.getMimeHeaders().getValue("user-agent");
>>             if (userAgentValueMB != null) {
>>                 String userAgentValue = userAgentValueMB.toString();
>>
>>             if (inStringArray(noCompressionUserAgents, userAgentValue))
>>                 return false;
>>             }
>>         }
>>
>>         // Check if suffisant len to trig the compression        
>>         int contentLength = response.getContentLength();
>>         if ((contentLength == -1)             || (contentLength >
>> compressionMinSize)) {
>>             // Check for compatible MIME-TYPE
>>             if (compressableMimeTypes != null)
>>                 return (startsWithStringArray(compressableMimeTypes,
>>                         response.getContentType()));
>>         }
>>
>>     return false;
>>     }
>>    
>
> Hence if your client add the accept-encoding: gzip, compression should
> starts. If that's not the case, then we have a bug :-)
It's also possible to tune Grizzly SelectorThread for better GZIP control.
Please take a look at following SelectorThread methods:
(1)    public void setCompression(String compression);
(2)    public void setCompressableMimeTypes(String compressableMimeTypes);
(3)    public void setCompressionMinSize(int compressionMinSize);

Please look at [1], to see expected parameters for those methods.

Hope this will help a little :)

WBR,
Alexey.

[1]
http://weblogs.java.net/blog/jfarcand/archive/2006/06/enabling_http_c_1.html


>
> A+
>
> -- Jeanfrancois
>
>
>
>>
>> Jeanfrancois Arcand wrote:
>>> Hi Alan,
>>>
>>> Alan Williamson wrote:
>>>> Can some explain how outgoing compression is suppose to work within
>>>> Grizzly?
>>>>
>>>> I *think* i may have misunderstood it.  I have it set to on, and
>>>> compress anything above 15KB.   However nothing is being compressed.
>>>>
>>>> I take it then when i do something like this:
>>>>
>>>>    OutputBuffer buffer = response.getOutputBuffer();
>>>>    buffer.doWrite(chunk, response);
>>>>
>>>> Grizzly isn't automatically compressing this if the outgoing client
>>>> supports GZIP?
>>>
>>> Yes, via its output filter
>>>
>>> https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/tcp/http11/filters/GzipOutputFilter.html 
>>>
>>>>
>>>> does that mean i have to manage this myself?
>>>
>>> No grizzly supports it (at least in GlassFish :-))
>>>
>>> http://weblogs.java.net/blog/jfarcand/archive/2006/06/enabling_http_c_1.html 
>>>
>>>
>>> How did you configure it exactly? If it doesn't work, it probably
>>> because of a bug. Last week I've ported some final fix from 1.0
>>> which we missed. Which version of Grizzly are you using?
>>>
>>> Thanks
>>>
>>> -- Jeanfrancois
>>>
>>>
>>>
>>>>
>>>> thanks
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SelectorThread.setCompression("on");

Oleksiy Stashok
In reply to this post by Alan Williamson
You're typing very fast :)

Please try to set also compressable mime type, if you have one not in
set: text/html,text/xml,text/plain.
Also, to make sure it's a bug - set

st.setCompression("force");

WBR,
Alexey.

Alan Williamson wrote:

>> Hence if your client add the accept-encoding: gzip, compression
>> should starts. If that's not the case, then we have a bug :-)
>
> then we may have a bug!
>
> i can't get a GZIP respoonse out no matter what i throw at it.
>
> so with my code, it should be triggering the
> com.sun.grizzly.http.DefaultProcessorTask class, even though, i am doing:
> ____________________________
>
> SelectorThread st = new SelectorThread();
> ByteBufferInputStream.setDefaultReadTimeout( 30000 );
>
> st.setPort(serverPort);
> st.setAdapter(this);
>
> st.setMaxKeepAliveRequests(keepAliveRequests);
> st.setKeepAliveTimeoutInSeconds(keepAliveTimeOut);
>
> st.setCompression("on");
> st.setCompressionMinSize(gzipThreshold);
> ____________________________
>
> and then sending out my own response by overriding:
>
> public void service(Request req, Response res) throws Exception {
>
> }
>
> yes?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SelectorThread.setCompression("on");

Alan Williamson
okay ... some information here :)

the  st.setCompression("force");  does indeed do EVERYTHING!!

so i set that back to "on" and then it died again, irrespective of the
size threshold.

however, as soon as i set the

        st.setCompressableMimeTypes("text/xml");

it all burst into life!!!  It would appear this call is required.

Is there any stats i can get back from the engine to tell me how much
data i am saving by GZIP'ing? or the number of GZIP responses sent?

Oleksiy Stashok wrote:
> You're typing very fast :)
>
> Please try to set also compressable mime type, if you have one not in
> set: text/html,text/xml,text/plain.
> Also, to make sure it's a bug - set
>
> st.setCompression("force");

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SelectorThread.setCompression("on");

Jeanfrancois Arcand-2


Alan Williamson wrote:

> okay ... some information here :)
>
> the  st.setCompression("force");  does indeed do EVERYTHING!!
>
> so i set that back to "on" and then it died again, irrespective of the
> size threshold.
>
> however, as soon as i set the
>
>     st.setCompressableMimeTypes("text/xml");
>
> it all burst into life!!!  It would appear this call is required.
>
> Is there any stats i can get back from the engine to tell me how much
> data i am saving by GZIP'ing? or the number of GZIP responses sent?

No of them are supported right now, but that shouldn't be a problem to
add support. Can you file an rfe here (so we don't forget :-))

https://grizzly.dev.java.net/issues/

Thanks!

-- Jeanfrancois



>
> Oleksiy Stashok wrote:
>> You're typing very fast :)
>>
>> Please try to set also compressable mime type, if you have one not in
>> set: text/html,text/xml,text/plain.
>> Also, to make sure it's a bug - set
>>
>> st.setCompression("force");
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SelectorThread.setCompression("on");

Oleksiy Stashok
In reply to this post by Alan Williamson
Hello Alan,

I commited the fix, so, think, it should start to work without calling:
 > st.setCompressableMimeTypes("text/xml");

Fix will be available in maven repository with next Grizzly 1.7-snapshot

Thanks.

WBR,
Alexey.



Alan Williamson wrote:

> okay ... some information here :)
>
> the  st.setCompression("force");  does indeed do EVERYTHING!!
>
> so i set that back to "on" and then it died again, irrespective of the
> size threshold.
>
> however, as soon as i set the
>
>     st.setCompressableMimeTypes("text/xml");
>
> it all burst into life!!!  It would appear this call is required.
>
> Is there any stats i can get back from the engine to tell me how much
> data i am saving by GZIP'ing? or the number of GZIP responses sent?
>
> Oleksiy Stashok wrote:
>> You're typing very fast :)
>>
>> Please try to set also compressable mime type, if you have one not in
>> set: text/html,text/xml,text/plain.
>> Also, to make sure it's a bug - set
>>
>> st.setCompression("force");
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SelectorThread.setCompression("on");

testn
For dynamic content e.g. servlet, content-length is not set explicitly. Therefore, it won't try to compress it. Would it make sense to also use Response.getBytesWritten as well?



Oleksiy Stashok wrote
Hello Alan,

I commited the fix, so, think, it should start to work without calling:
 > st.setCompressableMimeTypes("text/xml");

Fix will be available in maven repository with next Grizzly 1.7-snapshot

Thanks.

WBR,
Alexey.



Alan Williamson wrote:
> okay ... some information here :)
>
> the  st.setCompression("force");  does indeed do EVERYTHING!!
>
> so i set that back to "on" and then it died again, irrespective of the
> size threshold.
>
> however, as soon as i set the
>
>     st.setCompressableMimeTypes("text/xml");
>
> it all burst into life!!!  It would appear this call is required.
>
> Is there any stats i can get back from the engine to tell me how much
> data i am saving by GZIP'ing? or the number of GZIP responses sent?
>
> Oleksiy Stashok wrote:
>> You're typing very fast :)
>>
>> Please try to set also compressable mime type, if you have one not in
>> set: text/html,text/xml,text/plain.
>> Also, to make sure it's a bug - set
>>
>> st.setCompression("force");
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@grizzly.dev.java.net
> For additional commands, e-mail: users-help@grizzly.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@grizzly.dev.java.net
For additional commands, e-mail: users-help@grizzly.dev.java.net
Reply | Threaded
Open this post in threaded view
|

Re: SelectorThread.setCompression("on");

Jeanfrancois Arcand-2
Salut,

testn wrote:
> For dynamic content e.g. servlet, content-length is not set explicitly.
> Therefore, it won't try to compress it. Would it make sense to also use
> Response.getBytesWritten as well?

Can you elaborate a little bit about what you mean?

Thanks!

-- Jeanfrancois


>
>
>
>
> Oleksiy Stashok wrote:
>> Hello Alan,
>>
>> I commited the fix, so, think, it should start to work without calling:
>>  > st.setCompressableMimeTypes("text/xml");
>>
>> Fix will be available in maven repository with next Grizzly 1.7-snapshot
>>
>> Thanks.
>>
>> WBR,
>> Alexey.
>>
>>
>>
>> Alan Williamson wrote:
>>> okay ... some information here :)
>>>
>>> the  st.setCompression("force");  does indeed do EVERYTHING!!
>>>
>>> so i set that back to "on" and then it died again, irrespective of the
>>> size threshold.
>>>
>>> however, as soon as i set the
>>>
>>>     st.setCompressableMimeTypes("text/xml");
>>>
>>> it all burst into life!!!  It would appear this call is required.
>>>
>>> Is there any stats i can get back from the engine to tell me how much
>>> data i am saving by GZIP'ing? or the number of GZIP responses sent?
>>>
>>> Oleksiy Stashok wrote:
>>>> You're typing very fast :)
>>>>
>>>> Please try to set also compressable mime type, if you have one not in
>>>> set: text/html,text/xml,text/plain.
>>>> Also, to make sure it's a bug - set
>>>>
>>>> st.setCompression("force");
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SelectorThread.setCompression("on");

testn
ProcessorTask.isCompressable() checks only on getContentLength() but not getBytesWritten. Should it check both?

Jeanfrancois Arcand-2 wrote
Salut,

testn wrote:
> For dynamic content e.g. servlet, content-length is not set explicitly.
> Therefore, it won't try to compress it. Would it make sense to also use
> Response.getBytesWritten as well?

Can you elaborate a little bit about what you mean?

Thanks!

-- Jeanfrancois


>
>
>
>
> Oleksiy Stashok wrote:
>> Hello Alan,
>>
>> I commited the fix, so, think, it should start to work without calling:
>>  > st.setCompressableMimeTypes("text/xml");
>>
>> Fix will be available in maven repository with next Grizzly 1.7-snapshot
>>
>> Thanks.
>>
>> WBR,
>> Alexey.
>>
>>
>>
>> Alan Williamson wrote:
>>> okay ... some information here :)
>>>
>>> the  st.setCompression("force");  does indeed do EVERYTHING!!
>>>
>>> so i set that back to "on" and then it died again, irrespective of the
>>> size threshold.
>>>
>>> however, as soon as i set the
>>>
>>>     st.setCompressableMimeTypes("text/xml");
>>>
>>> it all burst into life!!!  It would appear this call is required.
>>>
>>> Is there any stats i can get back from the engine to tell me how much
>>> data i am saving by GZIP'ing? or the number of GZIP responses sent?
>>>
>>> Oleksiy Stashok wrote:
>>>> You're typing very fast :)
>>>>
>>>> Please try to set also compressable mime type, if you have one not in
>>>> set: text/html,text/xml,text/plain.
>>>> Also, to make sure it's a bug - set
>>>>
>>>> st.setCompression("force");
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@grizzly.dev.java.net
>>> For additional commands, e-mail: users-help@grizzly.dev.java.net
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@grizzly.dev.java.net
>> For additional commands, e-mail: users-help@grizzly.dev.java.net
>>
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@grizzly.dev.java.net
For additional commands, e-mail: users-help@grizzly.dev.java.net
Reply | Threaded
Open this post in threaded view
|

Re: SelectorThread.setCompression("on");

testn
Jeanfrancois,

So do you think it makes sense? Otherwise, currently, it will need to set compression to "force" to make servlet content to be compressed.

Thanks!

testn wrote
ProcessorTask.isCompressable() checks only on getContentLength() but not getBytesWritten. Should it check both?

Jeanfrancois Arcand-2 wrote
Salut,

testn wrote:
> For dynamic content e.g. servlet, content-length is not set explicitly.
> Therefore, it won't try to compress it. Would it make sense to also use
> Response.getBytesWritten as well?

Can you elaborate a little bit about what you mean?

Thanks!

-- Jeanfrancois


>
>
>
>
> Oleksiy Stashok wrote:
>> Hello Alan,
>>
>> I commited the fix, so, think, it should start to work without calling:
>>  > st.setCompressableMimeTypes("text/xml");
>>
>> Fix will be available in maven repository with next Grizzly 1.7-snapshot
>>
>> Thanks.
>>
>> WBR,
>> Alexey.
>>
>>
>>
>> Alan Williamson wrote:
>>> okay ... some information here :)
>>>
>>> the  st.setCompression("force");  does indeed do EVERYTHING!!
>>>
>>> so i set that back to "on" and then it died again, irrespective of the
>>> size threshold.
>>>
>>> however, as soon as i set the
>>>
>>>     st.setCompressableMimeTypes("text/xml");
>>>
>>> it all burst into life!!!  It would appear this call is required.
>>>
>>> Is there any stats i can get back from the engine to tell me how much
>>> data i am saving by GZIP'ing? or the number of GZIP responses sent?
>>>
>>> Oleksiy Stashok wrote:
>>>> You're typing very fast :)
>>>>
>>>> Please try to set also compressable mime type, if you have one not in
>>>> set: text/html,text/xml,text/plain.
>>>> Also, to make sure it's a bug - set
>>>>
>>>> st.setCompression("force");
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@grizzly.dev.java.net
>>> For additional commands, e-mail: users-help@grizzly.dev.java.net
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@grizzly.dev.java.net
>> For additional commands, e-mail: users-help@grizzly.dev.java.net
>>
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@grizzly.dev.java.net
For additional commands, e-mail: users-help@grizzly.dev.java.net
Reply | Threaded
Open this post in threaded view
|

Re: SelectorThread.setCompression("on");

Jeanfrancois Arcand-2
Salut,

thanks for reminding me...this Oracle acquisition eat my time :-)

testn wrote:
> Jeanfrancois,
>
> So do you think it makes sense? Otherwise, currently, it will need to set
> compression to "force" to make servlet content to be compressed.

True. Is using force an issue for you? I'm just curious to see why we
should change that behavior, which is inherited from Tomcat. I'm OK to
change the behavior, just tell me the use case. BTW did you tested with
your proposed fix?

Thanks

-- Jeanfrancois



>
> Thanks!
>
>
> testn wrote:
>> ProcessorTask.isCompressable() checks only on getContentLength() but not
>> getBytesWritten. Should it check both?
>>
>>
>> Jeanfrancois Arcand-2 wrote:
>>> Salut,
>>>
>>> testn wrote:
>>>> For dynamic content e.g. servlet, content-length is not set explicitly.
>>>> Therefore, it won't try to compress it. Would it make sense to also use
>>>> Response.getBytesWritten as well?
>>> Can you elaborate a little bit about what you mean?
>>>
>>> Thanks!
>>>
>>> -- Jeanfrancois
>>>
>>>
>>>>
>>>>
>>>>
>>>> Oleksiy Stashok wrote:
>>>>> Hello Alan,
>>>>>
>>>>> I commited the fix, so, think, it should start to work without calling:
>>>>>  > st.setCompressableMimeTypes("text/xml");
>>>>>
>>>>> Fix will be available in maven repository with next Grizzly
>>>>> 1.7-snapshot
>>>>>
>>>>> Thanks.
>>>>>
>>>>> WBR,
>>>>> Alexey.
>>>>>
>>>>>
>>>>>
>>>>> Alan Williamson wrote:
>>>>>> okay ... some information here :)
>>>>>>
>>>>>> the  st.setCompression("force");  does indeed do EVERYTHING!!
>>>>>>
>>>>>> so i set that back to "on" and then it died again, irrespective of the
>>>>>> size threshold.
>>>>>>
>>>>>> however, as soon as i set the
>>>>>>
>>>>>>     st.setCompressableMimeTypes("text/xml");
>>>>>>
>>>>>> it all burst into life!!!  It would appear this call is required.
>>>>>>
>>>>>> Is there any stats i can get back from the engine to tell me how much
>>>>>> data i am saving by GZIP'ing? or the number of GZIP responses sent?
>>>>>>
>>>>>> Oleksiy Stashok wrote:
>>>>>>> You're typing very fast :)
>>>>>>>
>>>>>>> Please try to set also compressable mime type, if you have one not in
>>>>>>> set: text/html,text/xml,text/plain.
>>>>>>> Also, to make sure it's a bug - set
>>>>>>>
>>>>>>> st.setCompression("force");
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SelectorThread.setCompression("on");

testn
Have fun with the Oracle. If that's the default behavior, it's fine by me. I'm just thinking whether there is an easier way to turn compress on selectively without having to insert the filter manually.

Jeanfrancois Arcand-2 wrote
Salut,

thanks for reminding me...this Oracle acquisition eat my time :-)

testn wrote:
> Jeanfrancois,
>
> So do you think it makes sense? Otherwise, currently, it will need to set
> compression to "force" to make servlet content to be compressed.

True. Is using force an issue for you? I'm just curious to see why we
should change that behavior, which is inherited from Tomcat. I'm OK to
change the behavior, just tell me the use case. BTW did you tested with
your proposed fix?

Thanks

-- Jeanfrancois



>
> Thanks!
>
>
> testn wrote:
>> ProcessorTask.isCompressable() checks only on getContentLength() but not
>> getBytesWritten. Should it check both?
>>
>>
>> Jeanfrancois Arcand-2 wrote:
>>> Salut,
>>>
>>> testn wrote:
>>>> For dynamic content e.g. servlet, content-length is not set explicitly.
>>>> Therefore, it won't try to compress it. Would it make sense to also use
>>>> Response.getBytesWritten as well?
>>> Can you elaborate a little bit about what you mean?
>>>
>>> Thanks!
>>>
>>> -- Jeanfrancois
>>>
>>>
>>>>
>>>>
>>>>
>>>> Oleksiy Stashok wrote:
>>>>> Hello Alan,
>>>>>
>>>>> I commited the fix, so, think, it should start to work without calling:
>>>>>  > st.setCompressableMimeTypes("text/xml");
>>>>>
>>>>> Fix will be available in maven repository with next Grizzly
>>>>> 1.7-snapshot
>>>>>
>>>>> Thanks.
>>>>>
>>>>> WBR,
>>>>> Alexey.
>>>>>
>>>>>
>>>>>
>>>>> Alan Williamson wrote:
>>>>>> okay ... some information here :)
>>>>>>
>>>>>> the  st.setCompression("force");  does indeed do EVERYTHING!!
>>>>>>
>>>>>> so i set that back to "on" and then it died again, irrespective of the
>>>>>> size threshold.
>>>>>>
>>>>>> however, as soon as i set the
>>>>>>
>>>>>>     st.setCompressableMimeTypes("text/xml");
>>>>>>
>>>>>> it all burst into life!!!  It would appear this call is required.
>>>>>>
>>>>>> Is there any stats i can get back from the engine to tell me how much
>>>>>> data i am saving by GZIP'ing? or the number of GZIP responses sent?
>>>>>>
>>>>>> Oleksiy Stashok wrote:
>>>>>>> You're typing very fast :)
>>>>>>>
>>>>>>> Please try to set also compressable mime type, if you have one not in
>>>>>>> set: text/html,text/xml,text/plain.
>>>>>>> Also, to make sure it's a bug - set
>>>>>>>
>>>>>>> st.setCompression("force");
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@grizzly.dev.java.net
>>>>>> For additional commands, e-mail: users-help@grizzly.dev.java.net
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@grizzly.dev.java.net
>>>>> For additional commands, e-mail: users-help@grizzly.dev.java.net
>>>>>
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@grizzly.dev.java.net
>>> For additional commands, e-mail: users-help@grizzly.dev.java.net
>>>
>>>
>>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@grizzly.dev.java.net
For additional commands, e-mail: users-help@grizzly.dev.java.net