users@grizzly.java.net

Re: SelectorThread.setCompression("on");

From: testn <test1_at_doramail.com>
Date: Wed, 8 Jul 2009 17:06:18 -0700 (PDT)

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_at_grizzly.dev.java.net
>>>>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>>>
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>
>>>>
>>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>
>

-- 
View this message in context: http://www.nabble.com/SelectorThread.setCompression%28%22on%22%29--tp15411852p24401629.html
Sent from the Grizzly - Users mailing list archive at Nabble.com.