Hi,
Still looking at the threading implications of CometEngine, I cannot
figure out why notificationHandlerClassName is a static variable. I am
sure there must be a reason, I just cannot see it. It is just that,
the implications for making the getter and setter thread safe are
greater and in my opinion not as elegant as if they were not static.
Should this conversation be moved to the dev list?
Best wishes,
Dan
On 08/07/2008, Jeanfrancois Arcand <Jeanfrancois.Arcand_at_sun.com> wrote:
> Salut,
>
> Dan Dubois wrote:
>
> > Hello,
> >
> > The only other public thread safety problem (I have not studied the
> > less public methods) I can see is with
> >
> CometEngine.setNotificationHandlerClassName(String
> > aNotificationHandlerClassName) which can be called at the same time
> > CometEngine.register is accessing the variable.
> >
> > I was also thinking about the synchronized keyword solution and was
> > wondering what you thought about the following:
> >
> > 1) Get rid of the CometEngine.getEngine() lazy instantiation and just
> > having the CometEngine as a private final static instance. This will
> > allow you to get rid of the synchronized keyword in front of the
> > getEngine() method I believe. I am sure this method is called a lot.
> >
>
> +1
>
>
>
> >
> > 2) Use something like a ReentrantReadWriteLock for the problems with
> > synchronization of the register and
> setNotificationHandlerClassName
> > methods. In my use case most of the time I call register will only be
> > to read from activeContexts to return an already created context which
> > can be done concurrently without having to block the entire register
> > method.
> >
> > Anyway, what do you think?
> >
>
> +1
>
>
> I am happy to investigate further if this
>
> > is a route you want to go down and post a patch on the issue.
> >
>
> I'm ready for a patch :-). The Comet works really needs to be improved and
> any patch will be quite appreciated! The documentation is far from perfect
> (for the code itselfs) so feel free to ask questions if you found something
> that looks ugly/strange (quite possible!)
>
> Thanks!
>
> -- Jeanfrancois
>
>
>
>
> >
> > Best wishes,
> > Dan
> >
> > On 07/07/2008, Jeanfrancois Arcand <Jeanfrancois.Arcand_at_sun.com> wrote:
> >
> > > Salut,
> > >
> > > I've filled:
> > >
> > >
> https://grizzly.dev.java.net/issues/show_bug.cgi?id=188
> > >
> > > to track the issue. I will start adding synchronized but if you have a
> > > patch, just attach it to the bug.
> > >
> > > Many thanks!
> > >
> > > -- Jeanfrancois
> > >
> > >
> > >
> > > Jeanfrancois Arcand wrote:
> > >
> > >
> > > > Hi Dan,
> > > >
> > > > Dan Dubois wrote:
> > > >
> > > >
> > > > > Hello All,
> > > > >
> > > > > I want to use CometEngine.register in my servlet doGet request.
> > > > >
> > > > > However looking at the source code v1_8_0_1
> > > > >
> > > >
> > >
> (https://grizzly.dev.java.net/source/browse/grizzly/tags/1_8_0_1/modules/comet/src/main/java/com/sun/grizzly/comet/CometEngine.java?rev=1268&view=markup
> > >
> <https://grizzly.dev.java.net/source/browse/grizzly/tags/1_8_0_1/modules/comet/src/main/java/com/sun/grizzly/comet/CometEngine.java?rev=1268&view=markup>)
> > > I believe that CometEngine.register is not thread safe. Do you agree
> with
> > > this?
> > >
> > > > Yes.
> > > >
> > > >
> > > >
> > > > > The reason I bring this up is because I can see quite a few use
> cases
> > > > >
> > > >
> > > where one would want to register a CometContext in a multithreaded
> > > environment, for example in a servlet event. Do you agree that it might
> be
> > > good to either document the lack of thread safety of make is threadsafe?
> > >
> > > > I fully agree. Since you looked at it, can you point me to the other
> > > >
> > > place? Or better, send me a svn diff :-) :-) :-)
> > >
> > > >
> > > >
> > > >
> > > >
> > > > > The main reason I am taking time to comment is because I think
> Grizzly
> > > > >
> > > >
> > > is excellent and want to help it get even better.
> > >
> > > >
> > > > Thanks!
> > > >
> > > >
> > > >
> > > > > Best wishes,
> > > > >
> > > > > Dan
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > >
> > > > 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
>
>