Salut,
Oleksiy Stashok wrote:
> Hi Sebastian,
>
>>
>>
>> Thanks for your response and sorry for my late response :-)
>>
>> I'm using my own thread-pool (thus not the DefaultThreadPool) and thus
>> the byteBuffer is not set. I've implemented a work-around in my app:
>>
>> WorkerThread wt = (WorkerThread) Thread.currentThread();
>> if (wt.getByteBuffer() == null) {
>> wt.setByteBuffer(ByteBuffer.allocate(MsrpThreadPool.BUFFER_SIZE));
>> }
>>
>> This I've put in the first filter in the chain, before the read()
>> operation is done by ReadFilter.
> Right.
> Other option is to do this inside thread pool implementation as we do in
> DefaultThreadPool class.
> Or if you have better idea, how we can improve current API to avoid such
> issue - please let us know.
Should we set the ByteBuffer at the Thread creation. Since we are now
enforcing the use of a Threadfactory , at least for the http module, but
I would propose we enforce the rule in the framework as well. So the
contract should be:
+ We allow configuration of the ExecutorServives
+ We enforce the fact that the ExecutorServices, if instance of
ThreadPooolExecutor, use our WorkerThreadFactory.
+ We create the BB when ThreadFactory.newThread() is invoked
What do you think?
A+
-- Jeanfrancois
>
> WBR,
> Alexey.
>
>>
>>
>> Thanks
>> Sebastian
>>
>> Oleksiy Stashok wrote:
>>> ByteBuffer is getting initialized inside DefaultThreadPool, which is
>>> located in grizzly-utils module.
>>> Can I ask you, Sebastien, to provide a test case to reproduce issue?
>>> Thank you.
>>> WBR,
>>> Alexey.
>>> On Jan 12, 2009, at 16:24 , Jeanfrancois Arcand wrote:
>>>> Salut,
>>>>
>>>> Sebastian Dehne wrote:
>>>>> Dear list,
>>>>> I've upgraded from 1.8.6 to 1.9.3 and used a ExecutorService with
>>>>> own ThreadFactoryas shown on
>>>>> http://blogs.sun.com/oleksiys/entry/grizzly_1_9_0_executorservice.
>>>>> However, now I run into a NPE @ ReadFilter:124 because the
>>>>> byteBuffer has never been set with this thread. I've done some
>>>>> source-coding browsing and it seems to me there is no way this
>>>>> buffer is ever set. The method
>>>>> WorkerThreadImpl.createByteBuffer(boolean) is only used if the
>>>>> DefaultThreadPool is used, which is not the case here.
>>>>
>>>> Looks like a bug to me. Can you file an issue here so we can fix it
>>>> for our 1.9.4 releae (this week).
>>>>
>>>> https://grizzly.dev.java.net/issues/
>>>>
>>>> Thanks!
>>>>
>>>> -- Jeanfrancois
>>>>
>>>>> Any suggestions?
>>>>> Thanks & kind regards,
>>>>> Sebastian Dehne
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>>> <mailto:users-unsubscribe_at_grizzly.dev.java.net>
>>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>> <mailto:users-help_at_grizzly.dev.java.net>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>> <mailto:users-unsubscribe_at_grizzly.dev.java.net>
>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>> <mailto:users-help_at_grizzly.dev.java.net>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>> <mailto:users-unsubscribe_at_grizzly.dev.java.net>
>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>> <mailto:users-help_at_grizzly.dev.java.net>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> <mailto:users-unsubscribe_at_grizzly.dev.java.net>
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>> <mailto:users-help_at_grizzly.dev.java.net>
>>
>