On Nov 26, 2008, at 11:33 AM, Jeanfrancois Arcand wrote:
> Thanks Igor for the feedback.
>
> BTW I've fixed:
>
> https://grizzly.dev.java.net/issues/show_bug.cgi?id=289
I saw that, thanks!
> You can update GF with the 1.9.0 SNAPSHOT:
>
> http://weblogs.java.net/blog/jfarcand/archive/2008/11/updating_grizzl.html
>
> and see if that works.
I'll give it a shot. I ran into some class loading issues in GFv3,
which I didn't have time to troubleshoot yet. I think that I'll need
to rewrite my extension as on OSGi module in order to get it to work
properly in GFv3.
I'm currently targeting GFv2 because that's the version of the app
server we use to run our application for which I developed this
extension. But I'm interested in supporting GFv3 in the (near?) future
as well. It really depends only on how much free time I have.
> BTW would you be interested to contribute your extension (if it is
> generic enough?)
All the extension does is that sending (usually large) files to a
client based on instructions from an app. It is very generic and
reusable by any kind of app (JavaEE, Rails, Grails, ..) running on
glassfish and in fact any app using grizzly (currently only the old
grizzly version bundled with GFv2). This is basically a functionality
that has been supported by apache and many other web servers for a
long time, but never made it to glassfish or any other JaveEE server
AFAIK.
To keep it as generic as possible, I actually went as far as
implementing my own extension points, so that I can write plugins for
my grizzly extension.
It is licensed as GPL and used in production at mediacast.sun.com.
I'll try to set aside some time during the upcoming long weekend to
write some user docs and explain all the benefits. Once that is done,
I'll be sure to send out an announcement to this mailing list.
In the meantime, you can check out the source code at
http://kenai.com/projects/grizzly-sendfile
While I have you attention, there is one issue that I was not able to
resolve, and thus had to resort to patching grizzly. My extension
deregisters a channel from the grizzly's selector and uses it's own
selector and worker thread pool (pipeline) to execute the request in
order to have a better control over how the file download is being
handled (I support several file sending algorithms).
The problem I found is that without patching grizzly, my extension
works properly only for HTTP keep-alive connections. If the connection
is not keep-alive, grizzly will close the connection when I deregister
the channel and my filter exists. This means that when I finally get
around to start pumping the data to the client, the connection is
already closed.
What I did to resolve this was to patch DefaultProcessorTask to expose
a new forceKeepAlive() method:
http://kenai.com/projects/grizzly-sendfile/sources/605-Mercurial-Source-Code-Repository/revision/44
Pretty ugly, but with the API of grizzly 1.0.x, I don't think that
there is a way around it. Is there any chance that you could give me a
way to handle this via an official grizzly api (ideally something that
would ship with glassfish v2.1). All I need is to prevent grizzly from
closing the socketchannel when I deregister it from the main selector
(and thus take over the responsibility for closing it).
cheers,
Igor
>
>
> A+
>
> -- Jeanfrancois
>
> Igor Minar wrote:
>> Alexey helped me out on this one offline and I just want to share
>> the resolution.
>> In the end we figured out that the problem was not caused by
>> grizzly, but by bugs in my code and in the benchmarking code,
>> combination of which made it pretty difficult to spot the real
>> problem.
>> When it comes to issue in my code, the delay was caused by calling
>> SocketChannel#register before Selector#wakeup, which always
>> resulted in a nasty blocking == delay. Alexey recommended to
>> rewrite the code so that the registration is executed by the
>> selector thread, which processes a registration queue (similarly to
>> how grizzly does this already). I did that and the delay is now gone.
>> Thanks Alexey!
>> /i
>> On Oct 23, 2008, at 2:10 AM, Oleksiy Stashok wrote:
>>>>>
>>>>> Hello Igor,
>>>>>
>>>>>> I'm building an ARP filter for grizzly that I use in glassfish-
>>>>>> v2ur2 and I'm seeing huge request latency under moderate load
>>>>>> (20 users). When I run tests with a single user, the delay is
>>>>>> usually insignificant.
>>>>>>
>>>>>> I wrote a faban benchmark for my filter and also added some
>>>>>> debugging code that tracks processing time in the filter and I
>>>>>> came to the conclusion that the delay occurs before the request
>>>>>> hits the doFilter method of my filter, which means that the
>>>>>> delay is occurring in grizzly or glassfish and not in my filter.
>>>>>>
>>>>>> I see the problem repeatedly. The 90th percentile of the delay
>>>>>> is around 10 seconds (the average is 4-5 seconds, max is 30+
>>>>>> seconds).
>>>>>>
>>>>>> Are there any known issues with grizzly used in glassfish that
>>>>>> could cause this behavior?
>>>>> No, it's not known, at least for me. It could be related to
>>>>> situation, when some thread (other than Selector thread) tries
>>>>> to operate with a selector directly.
>>>>> Please make sure your Filter doesn't do something like that.
>>>>>
>>>>> For sure it could be good if you can provide some testcase,
>>>>> which reproduces the problem, so it's possible to run it locally
>>>>> and debug.
>>>>>
>>>>> Thank you.
>>>>>
>>>>> WBR,
>>>>> Alexey.
>>>>
>>>> Since I work for Sun, I could set up a box on SWAN and give you
>>>> access to it. Another alternative is that I'll send you all the
>>>> code and instructions on how to set it up. The code is open
>>>> source so either way will work for me.
>>> I prefer 1st option :) Please let me know the coordinates of the
>>> machine.
>>>
>>> Thank you.
>>>
>>> WBR,
>>> Alexey.
>>>
>>>
>>>>
>>>>
>>>> thanks,
>>>> Igor
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> cheers,
>>>>>> Igor
>>>>>>
>>>>>>
>>>>>>
>>>>>> Here are relevant parts of the domain.xml:
>>>>>>
>>>>>> <jvm-options>-Dcom.sun.enterprise.web.connector.grizzly.asyncHandlerClass
>>>>>> =com.sun.enterprise.web.connector.grizzly.async.DefaultAsyncHandler
>>>>>> </jvm-options>
>>>>>> <jvm-options>-Dcom.sun.enterprise.web.connector.grizzly.asyncHandler.ports
>>>>>> =8080</jvm-options>
>>>>>> <jvm-options>-Dcom.sun.enterprise.web.connector.grizzly.asyncFilters
>>>>>> =com.igorminar.grizzlysendfile.SendfileFilter</jvm-options>
>>>>>>
>>>>>> <http-listener acceptor-threads="5" address="0.0.0.0" blocking-
>>>>>> enabled="false" default-virtual-server="server" enabled="true"
>>>>>> family="inet" id="http-listener-1" port="8080" security-
>>>>>> enabled="false" server-name="" xpowered-by="true">
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>
>> ---------------------------------------------------------------------
>> 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
>