Can we get the exception trace?. Also, is it possible to share your custom IoFilter?
thanks ashish On Sun, Jan 3, 2010 at 3:58 AM, Laurent Cohen <[email protected]> wrote: > Hello, > > I've just started with Mina and am facing a problem I've been stuck with for > days. > Environment: > - Mina 2.0.0 RC1 > - Sun JDK 1.5 / 1.6 / 1.6 x64 > - Windows Vista x64 > > I'm currently trying to switch an open source grid computing project > (http://www.jppf.org), of which I am a developer, to Mina's communication > framework, as I believe it would be easier to maintain and extend, and I'm > very excited by the built-in SSL and in-JVM communication capabilities. > The architecture of the project is of type master / worker where the master > acts as the Mina server, and the worker nodes as the clients. > Currently, I am at a point where the communication between server and client > is working, but only with a single client/node. As soon as I have more than > one client, exceptions are thrown on the clients' side on write operations. > Each message exchanged between server and client is made of a set of > serialized Java objects, with a header for each object which is a 4-bytes > integer that indicates the length of the serialized block of data. The first > serialized object (i.e. message header) tells how many objects are in the > message. > Basically each message is as follows: [ length1, data1, ... , lengthN, dataN > ] where lengthX is the length of block dataX, which is a serialized object > graph. > > From the tracing and debugging I've done, the first object is always read > and deserialized properly, and it is always on the second object that the > exceptions occur. The exceptions are of types StreamCorruptedException, > NegativeArraySizeException, OutOfMemoryError, apparently due to the fact > that the block length is not read or written properly. > > On the server side, serialization/deserialization occurs only for the first > (header) object of the message. The other objects are actually handled as > arrays of bytes, but not necessarily in memory: some or all of them may be > stored in temporary files, depending on the remaining available memory in > the server's JVM. The goal is to allow the server to work with data > structures that are much larger than the JVM heap. This is why I implemented > a custom IoFilter, rather than for instance a codec like > CumulativeProtocolDecoder, as I do not want the entire message to be in > memory (only the header object, which is relatively small, has to be). > > Sorry for the lengthy explanation, I hope it is clear enough. I am puzzled > as to why this is working with a single client, but not with 2 or more. > Would you have any idea as to where I can look, and as to what I could have > missed, overlooked, or done wrong? > Please let me know if you need more information or code snippets. > > Sincerely, > -Laurent > -- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal
