>>> 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?
The problem is that some Fitler may decide to detach a ByteBuffer and
not return in to WorkerThread.
Actually we need to check (recreate if required) BB each time before a
new task to be executed on a WorkerThread.
So create BB just once, when Thread is going to be created will not
work :(
WBR,
Alexey.
>
>
> 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
>>> >
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>