[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