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.
>
> 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
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.
You feedback is welcome :-) :-)
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
>