>>>
>>> Sebastian Dehne wrote:
>>>>> 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 :(
>>>> Good point. It also shouldn't be a threadPool's resposibility to
>>>> manage the byteBuffer.
>>>
>>> Well, at least the ThreadPool must use our Threadfactory, as it
>>> will not work if it doesn't.
>>>
>>> Alexey: It is still unclear to me that I'm wrong. The WorkerThread
>>> can always make sure, when it execute, that it's BB is not null.
>>> Actually this is what WorkerThread were doing until recently ;-)
>>> So I do think my proposal will perfectly works ;-)
>> WorkerThread can not make sure of that :)
>
> Before executing the task, they can certainly do it ;-) This is how
> is was done before we switch to ExecutorServices:
>
>> public WorkerThreadImpl(Pipeline<Callable> pipeline, String name,
>> Runnable runnable, int initialByteBufferSize){
>> super(threadGroup, runnable, name);
>> target = runnable;
>> this.pipeline = pipeline;
>> setDaemon(true);
>> this.initialByteBufferSize = initialByteBufferSize;
>> }
>> /**
>> * Execute a {_at_link Task}.
>> */
>> @Override
>> public void run(){
>> if (byteBuffer == null){
>> byteBuffer = ByteBufferFactory.allocate(byteBufferType,
>
> :-)
It was so. But with ThreadPoolExecutor (default Grizzly thread pool
impl) it's not possible to do anymore.
>> Currently WorkerThread just runs ThreadPool's internal task and
>> runs it forever, or until ThreadPool will decide to stop the
>> thread. WorkerThread doesn't even have own run method implemented,
>> it derives it from Thread.
>> So possible solution could be in notifying WorkerThread from
>> ThreadPool each time a new task is going to be executed. This way
>> we will move Buffer allocation logic from ThreadPool to WorkerThread.
>
> I agree :-) Any solution to the current issue is good :-)
Ok, will implement that.
WBR,
Alexey.
>
>
> A+
>
> -- jeanfrancois
>
>>> Image I have a single threadPool which I use for
>>>> multiple applications (also grizzly). With the current design,
>>>> each thread of this pool will get a byteBuffer at some point in
>>>> time.
>> Right. Having ByteBuffer for each thread let's us decrease a number
>> of ByteBuffer allocations, which is quite expensive.
>>>> A better way is to detach the byteBuffer from a thread when is it
>>>> not needed and re-attach it again once a certain thread is going
>>>> to do some work for grizzly.
>>>
>>> Hum, performance wise, the idea is to avoid the synchronization of
>>> putting the bb inside a pool and then getting back once needed.
>>> That's the hole idea of attaching a thread to the WorkerThread.
>> And pooling ByteBuffer will not help neither with memory
>> consumption (ByteBuffers just will be gathered in pool instead not
>> in workerthread) nor with performance (cost of synchronization).
>> Thanks.
>> WBR,
>> Alexey.
>>>
>>>
>>> A+
>>>
>>> -- Jeanfrancois
>>>
>>>
>>>
>>>
>>>> Seb
>>>> ---------------------------------------------------------------------
>>>> 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
>