Hi,
sorry for the dealy...was on vacation and away from computers for two
weeks :-)
wouter.hendrickx_at_thomson.com wrote:
> Hi,
>
>
>
> Yesterday I came up with a wild though concerning async object
> serialization, and I’m interested in feedback on the usefulness /
> feasibility of the idea…
>
>
>
> While sending objects back and forth over an ObjectOutputStream wrapping
> a (classical non NIO) socket’s outputstream, I was wondering whether it
> would be possible to make a nonblocking implementation of what I was
> doing… JAVA’s implementation of Object streams is inherently
> synchronous, forcing both the reading and writing end to block upon any
> read/write operation. It would be possible to create a (pseudo-)
> nonblocking alternative if it was possible to determine the size of a
> completely serialized object beforehand, and then sending the size
> before you actually transmit the object. That way, the receiving end
> will know how many bytes are needed before the Object can be
> deserialized again in one go… (so no more socket operations are needed
> to deserialize the object)…
>
>
>
> As I said, yesterday I came up with the idea that it is (at least
> theoretically) possible to make an asynchronous implementation of the
> serialization process! Indeed, as the serialized data conforms to a
> `grammar’ of some sort (I’m not sure whether this is the right term to
> use here), it is perfectly possible to process a few bytes, yielding a
> state containing a partially constructed object, and then continuing
> object reconstruction when more data comes available.
>
>
>
> Such implementation would make it possible to accept socket connections,
> and to start reading whole objects from these connections, in an
> asynchronous matter, as there is now no need to read whole objects in
> one blow. This eliminates the need of a dedicated thread looping over
> calls to objectOutputStream.readObject() …
>
>
>
> As my explanation is probably unclear, let’s write some pseudo-code
>
>
>
> interface ObjectHandler {
>
> /**
>
> * Process a newly deserialized object
>
> * E.g. put object in some sort of queue, ...
>
> * @param object
>
> */
>
> void handle( Object object );
>
> }
>
>
>
> public interface ObjectDeserializer {
>
> /**
>
> * Called from the asynchronous socket API to offer new bytes
>
> * to the deserializer
>
> * If one or more complete object are read during the processing
>
> * of the buffer, they are passed on to the registered object
>
> * handler...
>
> * @param buffer
>
> */
>
> void offer( byte[] buffer );
>
>
>
> /**
>
> * Register a handler with this deserializer
>
> * @param handler
>
> */
>
> void setHandler( ObjectHandler handler );
>
> }
>
>
>
>
>
> So the class ObjectDeserializer will form the link between the low-level
> socket API and a (sort-of) asynchronous object producing API…
>
> In my view, an implementation of ObjectDeserializer for the Hessian
> binary web protocol is certainly possible, on top of that, I suppose
> plain old java Object streams can have an asynchronous implementation,
> although it will be quite tedious to implement ;-)
>
>
>
> I see applications for such a solution in software where lots of Object
> communication between many endpoints, in a send-and-forget manner. I
> came up with the idea while experimenting and thinking about
> point-to-point object communications within a (larger) computer cluster.
>
>
>
> The reason I post this, is to poll whether there would be interest in
> such an implementation, and to communicate my idea to the wider world ;)
GlassFish deployment is based on object serialization via a Servlet. The
way I solved the problem for them (object deserialization) was to use a
temporary Selector pool to make sure the InputStream the Servlet is
using "blocks' until the entire object is read/deserialized. I would be
interested to explore your solution to see if that improve the current
design.
Thanks!
-- Jeanfrancois
>
>
>
> Kind Regards,
>
>
>
> Wouter
>
>
>
>
>
>
>