[infinispan-dev] HotRod client - optimize serialization

[Mircea Markus]

On 5 Jul 2010, at 13:50, Manik Surtani wrote:

> 
> On 5 Jul 2010, at 11:33, Mircea Markus wrote:
> 
>> 
>> On 5 Jul 2010, at 13:21, Manik Surtani wrote:
>> 
>>> What sort of socket do you use?  Depending on this, socket.getOutputStream() may be the most efficient (if it is a zero-copy NIO buffer for example).
>>        SocketChannel socketChannel = SocketChannel.open(serverAddress);
>>        *socket* = socketChannel.socket();
> 
> Hmm.  You could use ByteBuffers - and reuse them as well, if you know that the byte array sizes are *roughly* similar.  
no guarantee on that as I don't have control over the values.
> You will still have the same problem of a spike in value size that you described below, in the case of pooling ExposedBAOS instances.  You could maintain a threshold and if such a stream were to exceed this size, instead of resetting and reusing this instance you drop it from the pool and create a new one... 
> 
> This threshold would have to be configurable though otherwise you may end up with a lot of unnecessary GC churn.
The more I think about it the more I like the idea of serializing the values directly to the socket, and not reuse buffers for keys: these are small objects, and not sure that the complexity (mainly thinking about concurrency control) would payoff.
> 
> 
>>> 
>>> Why do you need to hang on to the byte[] representation for keys?
>> I need it for hashing calculation, as java hotrod client is distribution aware.
>>> 
>>> 
>>> On 5 Jul 2010, at 11:10, Mircea Markus wrote:
>>> 
>>>> Hi,
>>>> 
>>>> On HR we serialize the (key, value) pairs before sending them to the client.
>>>> Current approach is we transfer them into an byte[] using an ByteArrayInputStream/ByteArrayOutputStream and then write them over the network with socket.getOutputStream().write(byte[])  
>>>> 
>>>> What I'm looking for a better way of serializing, by reusing byte arrays.
>>>> One approach would be to use an pool of ExposedByteArrayOutputStream, pool's size being == number of tcp connections between client and server. My concern with this approach is that if one is using a large value (e.g. 100MB ) once in a blue moon, than I'll always keep an 100MB array in memory, cached, even though I don't want it. 
>>>> 
>>>> Another approach would be to use use existing code for keys(i.e. serialize them into an byte[]), which are expected to be smaller, and for values to write directly in the  socket, through socket.getOutputStream(). This way I won't have the 100MB issue and also I won't create an byte[] for each value (I need to do that for keys though, as I need access to key's byet[] for computing its hash code).
>>>> 
>>>> Any suggestions much appreciated!
>>>> 
>>>> Cheers,
>>>> Mircea
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> 
>>> --
>>> Manik Surtani
>>> manik at jboss.org
>>> Lead, Infinispan
>>> Lead, JBoss Cache
>>> http://www.infinispan.org
>>> http://www.jbosscache.org
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
> 
> 
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev