Salut,
Igor Minar wrote:
>
> On Nov 26, 2008, at 2:35 PM, Jeanfrancois Arcand wrote:
>
>>
>>
>> Igor Minar wrote:
>>> On Nov 26, 2008, at 2:07 PM, Jeanfrancois Arcand wrote:
>>>>
>>>>
>>>> Igor Minar wrote:
>>>>
>>>> [cut]
>>>>
>>>>> I believe I have copy of the comet code from gfv2ur2 and in
>>>>> CometTask I see:
>>>>> } finally {
>>>>> // Bug 6403933
>>>>> if (connectionClosed){
>>>>> cometSelector.cancelKey(cometKey);
>>>>> }
>>>>> And in CometSelector there is:
>>>>> SelectorThread st = cometTask.getSelectorThread();
>>>>> SelectionKey mainKey = cometTask.getSelectionKey();
>>>>> if (cometTask.getCometContext() != null){
>>>>> cometTask.getCometContext().interrupt(mainKey);
>>>>> }
>>>>> cometEngine.interrupt(key);
>>>>> st.cancelKey(mainKey);
>>>>
>>>> ah you deep dive inside that code :-) I agree I think that will
>>>> works. But I still need to invoke cancelKey(..) as the keep-alive
>>>> subsystem needs to be advised a connection is getting closed. I
>>>> guess I can get the KeepAlivePipeline and invoke it directly. I need
>>>> to investigate...
>>>>
>>>> Let me look at your code now :-)
>>> hahaha.. go for it and let me know if you see places that could be
>>> improved. I'm sure that there are some. Especially the plugin
>>> interface is super simple and should be improved.
>>> One thing I'm not terribly happy about is the state of my test suite.
>>> I basically have only a faban benchmark which does system/acceptance
>>> testing and load testing/benchmarking. I have some unit and
>>> functional tests written in RSpec that I invoke via JTestR, but that
>>> stuff is not committed yet because it's not complete.
>>
>> I want to see how you automate faban here as I really want to automate
>> it for the http modules.
>
> You can see the code in the repo under test/faban, which tests an
> example application (under etc/test-webapp).
Great, thanks!
>
> I had to build some custom code in order to make faban suitable for my
> "large" file downloads (see my custom class Md5Downloader).
>
> The test suite is not perfect, but it's good enough at the moment for
> catching concurrency issues, which could result in data inconsistencies
> or aborted downloads. Overall I'm sleeping much better now that I can
> reliably test the code even though it's only at this high level.
I'm running a customized Faban implementation for every release to make
sure no regression.
>
>
>>> In general I found it pretty difficult to test the code that extends
>>> grizzly code. Maybe that has changed in later releases (I've been
>>> primarily working with 1.0.x), but I'd really love to see some
>>> helper/mock/stub classes in grizzly or more IoC/injection that would
>>> aid in building a good test suite.
>>
>> Fully agree.
>>
>>> Do you have any pointers to your test suite or testing practices that
>>> other grizzly developers could leverage?
>>
>> We have improved a lot since 1.0.x IMO. For the http module, embedding
>> it could be as simple as:
>>
>> http://weblogs.java.net/blog/jfarcand/archive/2008/07/extending_the_g.html
>>
>>
>> For the test case, take a look at:
>>
>> https://grizzly.dev.java.net/nonav/xref-test/index.html
>
> Nice.
>
>> Of course there are still places for improvement, but that was a
>> gigantic step to move out of GF, then split the 1.0.x into 5 modules
>> (framework, http, http-utils, comet, cometd) instead of a monolithic jar.
>
> Very good. I need to catch up with grizzly 1.9 and 2.0.
>
>> You feedback is welcome :-) :-)
>
> I really like grizzly and I learned a lot by reading its code (I had no
> NIO experience before). I think that more focus on testability and
> better naming of classes and methods were the two main areas that I had
> problems with.
>
> For example, I found a few oddities that caused me to waste a lot of
> time by debugging:
>
> - org.apache.coyote.Response#reset doesn't reset the response body. I
> spent quite some time debugging data corruption cased by my app
> inserting a single space character into the response buffer and
> response#reset not cleaning it out. Actually I'd prefer to have two
> methods on the response class - resetHeaders and resetBody. In my
> extension, I'm really interested only in resetting the body and
> preserving the headers set by an application.
OK this code is from Tomcat :-) I do agree with you. I would recommend
you file an RFE here:
https://grizzly.dev.java.net/issues/
so we don't lost track.
>
> - org.apache.coyote.Response#sendHeader is misleading because it doesn't
> send headers until #finish is called, again something that I wasted a
> lot of time on
Agree. The issue is with Grizzly which cache the bytes until the very
end to avoid network operations. File an issue and that one can be
easily fixed by adding:
res.action(Action.ACTION_CLIENT_FLUSH,res);
which will flush the bytes.
>
> - org.apache.coyote.Response#remoteAddr returns null when I run
> grizzly-sendfile on my mac as localhost, but it works fine on our
> production servers (solaris)
>
Strange...we lazily evaluate those value so I don't understand how it
works :-) Mainly, you need to notify Grizzly with
ActionCode.ACTION_REQ_HOST_ADDR_ATTRIBUTE
> oh.. and there was one more.. If a subclass of AsyncFilter throws an
> exception from the static initializer or constructor, this exception is
> swallowed without any error logs. (that resulted in:
> http://twitter.com/IgorMinar/status/1020362781 :-D)
Hahaha :-) OK I can fix that one easily and you can blame me :-)
>
>
> One thing that is on my wishlist, but that is probably more an RFE for
> NIO than grizzly is that I'd like to be able to do "semi-blocking"
> writes to a channel or writes with defined timeout. What I mean by that
> is that I'd like to say, try to write this bytebuffer into this channel
> but don't block for longer than x milliseconds. That would allow me to
> take my code to a whole new level. Right now I workaround this by doing
> non-blocking writes and repeating them with throttling involved to avoid
> high cpu usage (see SendfileAlgorithm#throttle).
Currently in 1.9.0 we have async write queue that can help. With 1.0.22,
I would think you should take a look at the OutputWriter code and
instead of throwing EOFException. We can add support for such behavior
in 1.9.x as well. Just need an RFE :-)
>
> At the moment I focus mainly on what I call blocking algorithms
> (algorithms that employ blocking writes) because they are easier to
> implement, but IMO the future of grizzly-sendfile will be in
> non-blocking algorithms, which as my preliminary benchmarks show,
> deliver incomparable scalability, while retaining transfer performance
> (think 500 concurrent downloads served by only 50 or less worker
> threads). There are many cool *and* useful things that can be done in
> the grizzly-sendfile world when you start writing plugins and algorithms.
I can't do anything for 1.0.22 because we are pass 2.1 FCS, but for sure
we fix your RFE in 1.9.x :-). I suspect a lot of peoples will be
interested by your send file impl. (as File.transfertTo(..) is still
quite bogus)...at least I will evaluate it for inclusion in v3.
A+
-- Jeanfrancois
>
> cheers,
> Igor
>
>
>>
>>
>> A+
>>
>> -- jeanfrancois
>>
>>
>>
>>
>>
>>> /i
>>>>
>>>>
>>>> A+
>>>>
>>>> --Jeanfrancois
>>>>
>>>>
>>>>
>>>>> /i
>>>>>>
>>>>>>
>>>>>>
>>>>>> This would allow me to
>>>>>>> avoid having to retain a reference to the main selector and its
>>>>>>> selectionkey resulting in less clutter.
>>>>>>
>>>>>> I agree.
>>>>>>
>>>>>> A+
>>>>>>
>>>>>> -- Jeanfrancois
>>>>>>
>>>>>>
>>>>>>> /i
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>