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).

Why do you need to hang on to the byte[] representation for keys?

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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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.

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.

>> >> 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> -- >> Manik Surtani >> manik(a)jboss.org >> Lead, Infinispan >> Lead, JBoss Cache >> http://www.infinispan.org >> http://www.jbosscache.org >> >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 5 Jul 2010, at 11:58, Mircea Markus wrote: > > 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. Yeah I'm all for keeping it simple.

-- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev