Discussion moved to dev. :-)
Dan Dubois wrote:
> 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
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>