On 20 Jan 2012, at 01:12, Bela Ban wrote:
On 1/19/12 6:36 PM, Galder Zamarreño wrote:
>
>
> On Jan 19, 2012, at 3:43 PM, Bela Ban wrote:
>
>> This may not give you any performance increase:
>>
>> #1 In my experience, serialization is way faster than de-serialization.
>> Unless you're doing something fancy in your serializer
>
> No. I think Mircea didn't explain this very well. What really happens here is
that when asyncMarshalling is turned on (the name is confusing...), async transport
sending is activated. What does this mean?
>
> When the request needs to be passed onto JGroups, this is done in a separate thread,
which indirectly, results in marshalling happening in a different thread.
How is this thread created ? I assume you use a thread pool with a
*bounded* queue. Or are you spawning a new thread on every serialization
? If that's the case, then you're run out of threads if the
serialization rate is high…
Yes, an executor with a configurable/tunable thread pool. And yes, if this queue fills we
pay a price, and effectively starts to look like sync marshalling. But this isn't the
default and users who use this feature need to understand that marshalling is a hotspot
for them, and their transaction rate isn't that high that it overwhelms their
marshalling queue otherwise this doesn't help them.
I'm not entirely sure Mircea's and Galder's request makes sense though: with a
GET_NONE, does JGroups use a separate thread to send a message when a message is cast
using the MessageDispatcher? Or is this on the thread that calls cast() up until it hits
the socket, but just doesn't wait for any response?
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org