[jbosscache-dev] Re: Integrating steaming transfer in JBC
Manik Surtani
manik at jboss.org
Tue Aug 15 15:55:09 EDT 2006
This all sounds very good. I particularly like defining the byte
stream format of persistent state. I agree with Bela that we'd have
to include a version bit/short.
So are we looking at overloading the load/storeState methods with an
Input/OutputStream parameters/return types in the interface, plus
defining the format of this state - including an 'end-of-in-memory-
state' marker? Is that about it?
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik at jboss.org
Telephone: +44 7786 702 706
MSN: manik at surtani.org
Yahoo/AIM/Skype: maniksurtani
On 15 Aug 2006, at 19:20, Brian Stansberry wrote:
> Vladimir Blagojevic wrote:
>> Is it not that whenever you close OIS#1 (as you do in step 3)
>> close call is passed to underlying inputstream which would
>> close actual tcp inputstream passed up by jgroups layer?
>
> Yep.
>
>> We need some "end of in-memory state" marker?
>>
>
> Yes, definitely. The in-memory state is a series of NodeData objects,
> written one after another, not encapsulated in an array or list or
> anything. Persistent state is the same thing. So you'd need some
> sort
> of marker to tell the integrator when the in-memory state is finished.
>
>>>
>>> I was thinking there might be an issue with this:
>>>
>>> 1) StateTransferIntegrator gets InputStream IS from the JGroups
>>> layer. 2) Uses it to create ObjectInputStream OIS#1. Uses that to
>>> read off the in-memory state and any marker we insert in the stream.
>>> 3) Closes OIS#1. 4) Passes IS to the cache loader.
>>> 5) Cacheloader creates ObjectInputStream OIS#2 from IS. Reads the
>>> persistent state.
>>>
>>> Maybe that will work fine; it would be good if it did as it allows
>>> for a more flexible API.
More information about the jbosscache-dev
mailing list