Hi,
Thanks for the comprehensive response, much appreciated.
Well for a number of reasons we built our own Bayeaux implementation on
top of Grizzly Comet. There where a number of reasons for this.
First of all the CometdNotificationHanlder behavior changed. In addition
so did com.sun.grizzly.cometd.bayeux.Verb but well that's our own problem.
We're still seeing some weird comet expiry problems now, but we think
this could be an internal issue. But we'll give this a closer look.
One thing as a positive note, for the first time in 18 months, we've
been able to have CometD run without the CPU 100% Selector spinning
issue. The load is small, only 50 hosts running for 24hours with an
average of 2.2% prcoessing circa 540,000 connects...we're intending to
ramp up testing this area. So 1.0.30-SNAPSHOT looks good.
Kind Regards,
James
Jeanfrancois Arcand wrote:
> Salut,
>
> James Cooper wrote:
>> Hi All,
>> I'm not sure as to which list I should post this to, so apologies in
>> advance if I've not gotten to the right audience.
>>
>> I've been using Grizzly for the past 18 months and I've not been an
>> active community member and as such so of the issues I may report are
>> in some ways my own fault.
>>
>> Firstly our move from GF2.0.1 to GF2.1 has been pretty much an
>> unmitigated disaster. Mainly due to Grizzly and specifically our use
>> of its Cometd implementation. We've always been plagued by the CPU
>> consumption problem and only moving from Linux to Windows alleviated
>> that. Recently due to a virtual server bug fix, our production team
>> wanted us to move to GF 2.1 and since then we've been fighting with a
>> comet expiration delay issue highlighted in the following thread.
>>
>> http://tinyurl.com/kp8n2w
>>
>> Firstly it seems that the Comet implementation changed its API without
>> any form of communication to its user base and without any deprecation
>> model being followed. Whilst this might be something that a major
>> release MIGHT allow, it should not be the case for simple maintenance
>> releases. This again caused us delay.
>
> I apologize for the API changes...but can you point me which one caused
> that change? This is not expected and should be considered as a hight
> priority bug. We never wanted to breal backward compatibility. Event
> with GF v3, we also created a grizzly-compat module to make sure that
> *all* Grizzly Comet implementation based on 1.0.x still works in Grizzly
> 1.9.x/v3.
>
>
>
>>
>> In addition whilst not particularly a Grizzly issue. One never
>> actually knows for sure what version of Grizzly is actually in use
>> with GF. The GF package process at least that of GF2.X is abysmal.
>> Once you do find the correct Grizzly module, where's the equivalent
>> source?
>
> It's impossible right now. I've added that information in Grizzly
> 1.0.30, which will be integrated and available in GF 2.2
>
> In fact I'd
>> to dig deep into JIRA to find that only in May was Grizzly's 1.0.X
>> source moved to its SVN, revision 3149. Most of the time the only way
>> to know is to download all the source for GF.
>>
>> Now it seems a fix for the expiration issue was post in 1.0.30-SNAPSHOT
>> http://download.java.net/maven/2/com/sun/grizzly/grizzly-framework-http
>>
>> But alas, where's the source?
>
> Inside the Grizzly workspace:
>
> trunk/extra/grizzly1.0
>
>
>>
>> Sure there's allot of work around the forth coming version of GFv3 and
>> the work Grizzly has done to support that. But this is still not a
>> released platform and whilst I'd love to migrate, we're not going to
>> be able to put it into production until all the features we need are
>> available. As a net result, we're stuck on GF2.1 and in all honesty
>> very frustrated with it and sadly most of that frustration is Grizzly
>> related.
>
> Fully agree. Please send me the exact list of things that needs to be
> fixed ASAP to jfarcand @ apache.org. I wan to make sure you can use
> 1.0.30 and I want to make sure it fix all the regressions you are
> observing.
>
> Thanks
>
> -- Jeanfrancois
>
>
>
>>
>> Kind Regards.
>> James
>>
>> ---------------------------------------------------------------------
>> 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
>