Re: [jbosscache-dev] Re: Integrating steaming transfer in JBC
by Manik Surtani
I'm still stabilising HEAD at the moment, almost there. Once this is
stable (as far as interfaces go) and we have a properly working test
suite, you can start moving your stuff in. I expect to have HEAD
stable by mid next week.
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
On 16 Aug 2006, at 19:23, Vladimir Blagojevic wrote:
> Ok np. My current task is to integrate streaming state transfer
> into JBC and I will be working mostly under Brian's guidance. What
> is the deadline for this integration and how do we proceed?
>
> Vladimir
>
> From: Manik Surtani [mailto:manik@jboss.org]
> Sent: Wednesday, August 16, 2006 2:14 PM
> To: Vladimir Blagojevic
> Subject: Re: [jbosscache-dev] Re: Integrating steaming transfer in JBC
>
> Correct. At the end of the day this is just an overload on the
> same functionality, allowing different approaches, so we're not
> really making the interface any more complex.
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
> Email: manik(a)jboss.org
> Telephone: +44 7786 702 706
> MSN: manik(a)surtani.org
> Yahoo/AIM/Skype: maniksurtani
>
>
> On 16 Aug 2006, at 15:08, Vladimir Blagojevic wrote:
>
>> Manik,
>>
>> You mean you have nothing against 8 method approach for state
>> transfer?
>>
>> Vladimir
>>
>> From: Manik Surtani [mailto:manik@jboss.org]
>> Sent: Wednesday, August 16, 2006 5:28 AM
>> To: Bela Ban
>> Cc: Vladimir Blagojevic; Ben Wang; Brian Stansberry
>> Subject: Re: [jbosscache-dev] Re: Integrating steaming transfer in
>> JBC
>>
>> I've got nothing against overloading the methods.
>>
>>
>> --
>> Manik Surtani
>>
>> Lead, JBoss Cache
>> JBoss, a division of Red Hat
>>
>> Email: manik(a)jboss.org
>> Telephone: +44 7786 702 706
>> MSN: manik(a)surtani.org
>> Yahoo/AIM/Skype: maniksurtani
>>
>>
>> On 16 Aug 2006, at 07:36, Bela Ban wrote:
>>
>>> So you;re saying, since the methods that take a byte[] will
>>> construct an input stream anyway, why not provide the stream in
>>> the first place ? I like the idea; and it should not be hard to
>>> write code that generates a byte[] array from an input stream.
>>> However, what's wrong with having 8 state transfer methods, and
>>> provide a ListenerAdapter class, which has null implementations,
>>> and you simply extend that adapter class ?
>>>
>>> Vladimir Blagojevic wrote:
>>>> Guys,
>>>>
>>>> Is there a need to have additional 4 methods (thus in total 8
>>>> methods
>>>> for state transfer) in CacheLoader API in order to support both
>>>> streaming and byte based state transfer or can we cover both
>>>> types of
>>>> state transfer by having only 4 InputStream/OutputStream based
>>>> methods?
>>>>
>>>> These 4 methods would be something like:
>>>>
>>>> void storeEntireState(InputStream s);
>>>> void storeState(Fqn subtree,InputStream s);
>>>> void loadEntireState(OutputStream s);
>>>> void loadState(Fqn subtree,OutputStream s);
>>>>
>>>> We ensure that byte state transfer is still supported but that
>>>> doesn't
>>>> mean the CacheLoader needs to take/return byte[]! If byte state
>>>> transfer
>>>> is used, the StateTransferIntegrator can be responsible for
>>>> creating
>>>> ByteArrayInput(Output)Stream from the persistent state byte[]
>>>> and pass
>>>> stream to the CacheLoader instead of byte[].
>>>>
>>>> There will still be complexity in the integrator code to support
>>>> both
>>>> flavors, but that complexity doesn't need to be pushed from jgroups
>>>> layer all the way through to the CacheLoader API.
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> jbosscache-dev mailing list
>>>> jbosscache-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>>>
>>>>
>>>
>>> --
>>> Bela Ban
>>> Lead JGroups / Manager JBoss Clustering Group
>>> JBoss - a division of Red Hat
>>
>
19 years, 1 month
RE: [jbosscache-dev] Habanero: implementing peek() and _*() methods
by Ben Wang
If you expose these in the SPI, then it is not meant for end users, isn't it?
-----Original Message-----
From: Manik Surtani [mailto:manik@jboss.org]
Sent: Wednesday, August 16, 2006 5:25 PM
To: Ben Wang
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] Habanero: implementing peek() and _*() methods
I agree that access to _* methods will be useful/necessary.
This is why I proposed an interceptor chain bypass option, rather than directly exposing methods. My problem with directly exposing methods is that end users may see these and use them.
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
On 16 Aug 2006, at 03:49, Ben Wang wrote:
> Since I haven't done the integration so it is difficult to say for
> sure. But I have a feeling that I will need to have the access to
> _* methods as well from PojoCache. So would it be OK then to create a
> delegate interface from CacheSPI (e.g., NakedNode, in that calls here
> are not going thru any interceptor chain) that exposes these APIs?
> User can still access these but at least it doesn't pollute the SPI
> interfaces.
>
> BTW, maybe this deserves a forum thread? :-)
>
> My 2 cents,
>
> -Ben
>
>
> -----Original Message-----
> From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-
> bounces(a)lists.jboss.org] On Behalf Of Manik Surtani
> Sent: Monday, August 14, 2006 8:17 PM
> To: jbosscache-dev(a)lists.jboss.org
> Subject: [jbosscache-dev] Habanero: implementing peek() and _*()
> methods
>
> In 2.0.0, all interceptors have a reference to a CacheSPI only.
>
> This causes a problem in some interceptors (cache loader, lock
> interceptors, etc) which currently make a few direct calls to _get (),
> _put(), etc. to perform operations on the cache while bypassing the
> interceptor stack entirely.
>
> What do people think the best way would be do provide this access for
> very specialised cases, but not exposing such calls in the CacheSPI
> interface for generic Interceptors people may implement?
>
> I'm currently doing this by creating a 'bypassInterceptorChain'
> option and then calling a standard put() or get(), but this is at best
> a hack, plus it exposes the 'bypassInterceptorChain' option in a
> public API for users to (ab)use. Any better ideas?
>
> Cheers,
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
> Email: manik(a)jboss.org
> Telephone: +44 7786 702 706
> MSN: manik(a)surtani.org
> Yahoo/AIM/Skype: maniksurtani
>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
19 years, 1 month
RE: [jbosscache-dev] Habanero: implementing peek() and _*() methods
by Ben Wang
Since I haven't done the integration so it is difficult to say for sure. But I have a feeling that I will need to have the access to _* methods as well from PojoCache. So would it be OK then to create a delegate interface from CacheSPI (e.g., NakedNode, in that calls here are not going thru any interceptor chain) that exposes these APIs? User can still access these but at least it doesn't pollute the SPI interfaces.
BTW, maybe this deserves a forum thread? :-)
My 2 cents,
-Ben
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Manik Surtani
Sent: Monday, August 14, 2006 8:17 PM
To: jbosscache-dev(a)lists.jboss.org
Subject: [jbosscache-dev] Habanero: implementing peek() and _*() methods
In 2.0.0, all interceptors have a reference to a CacheSPI only.
This causes a problem in some interceptors (cache loader, lock interceptors, etc) which currently make a few direct calls to _get(), _put(), etc. to perform operations on the cache while bypassing the interceptor stack entirely.
What do people think the best way would be do provide this access for very specialised cases, but not exposing such calls in the CacheSPI interface for generic Interceptors people may implement?
I'm currently doing this by creating a 'bypassInterceptorChain'
option and then calling a standard put() or get(), but this is at best a hack, plus it exposes the 'bypassInterceptorChain' option in a public API for users to (ab)use. Any better ideas?
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
19 years, 1 month
RE: [jbosscache-dev] Re: Mail lists
by Ben Wang
+1
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Manik Surtani
Sent: Monday, August 14, 2006 11:32 PM
To: Ruel Loehr
Cc: Ryan Campbell; jbosscache-dev(a)lists.jboss.org; IT Ops Team; Eric Brown
Subject: [jbosscache-dev] Re: Mail lists
I must say I'm not too keen on switching to SVN just yet - too much on my plate at the moment. How does the end of Oct sound, once I've released JBC 2.0.0?
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
On 14 Aug 2006, at 14:28, Ruel Loehr wrote:
> Converting the jboss-cache cvs proj over to svn would in my opinion be
> pretty trivial. It's one single module, no mutation craziness
> would be needed, just a straight cvs2svn conversion. I'm
> thinking it would take a couple of days at most, 1 day to setup and
> test, 1 day to do a production conversion.
>
> Ruel Loehr
> JBoss QA
>
> -----------------------------
> 512-342-7840 ext 2011
> Yahoo: ruelloehr
> Skype: ruelloehr
> AOL: dokoruel
>
> -----Original Message-----
> From: Eric Brown
> Sent: Sunday, August 13, 2006 8:44 PM
> To: Manik Surtani; Ruel Loehr; Ryan Campbell
> Cc: IT Ops Team
> Subject: Re: Mail lists
>
> Since your repo is still within the old JBoss cvs repo, we don't have
> much option here w/out making mods to the existing scripts.
>
> TomBen - Can our existing script do this easily?
>
> I'd rather just get you guys on the schedule to move out of the old
> CVS to your own svn repo. I'm including Ryan and Ruel to comment on
> cvs2svn conversion.
>
>
>> From: Manik Surtani <manik(a)jboss.org>
>> Date: Fri, 11 Aug 2006 10:21:47 -0500
>> To: Eric Brown <eric.brown(a)jboss.com>
>> Conversation: Mail lists
>> Subject: Mail lists
>>
>> Hi Eric
>>
>> Could we pls make sure CVS commits on JBoss Cache are now mailed to
>> jbosscache-commits and JIRA notifications to jbosscache-issues, pls.
>> I suspect they're currently going to either the jboss-* lists or the
>> old SF ones.
>>
>> Thanks!
>> --
>> Manik Surtani
>>
>> Lead, JBoss Cache
>> JBoss, a division of Red Hat
>>
>> Email: manik(a)jboss.org
>> Telephone: +44 7786 702 706
>> MSN: manik(a)surtani.org
>> Yahoo/AIM/Skype: maniksurtani
>>
>>
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.405 / Virus Database: 268.10.10/418 - Release Date:
> 8/14/2006
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.405 / Virus Database: 268.10.10/418 - Release Date:
> 8/14/2006
>
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
19 years, 1 month
RE: [jbosscache-dev] Re: Integrating steaming transfer in JBC
by Vladimir Blagojevic
Guys,
Is there a need to have additional 4 methods (thus in total 8 methods
for state transfer) in CacheLoader API in order to support both
streaming and byte based state transfer or can we cover both types of
state transfer by having only 4 InputStream/OutputStream based methods?
These 4 methods would be something like:
void storeEntireState(InputStream s);
void storeState(Fqn subtree,InputStream s);
void loadEntireState(OutputStream s);
void loadState(Fqn subtree,OutputStream s);
We ensure that byte state transfer is still supported but that doesn't
mean the CacheLoader needs to take/return byte[]! If byte state transfer
is used, the StateTransferIntegrator can be responsible for creating
ByteArrayInput(Output)Stream from the persistent state byte[] and pass
stream to the CacheLoader instead of byte[].
There will still be complexity in the integrator code to support both
flavors, but that complexity doesn't need to be pushed from jgroups
layer all the way through to the CacheLoader API.
Thoughts?
19 years, 1 month
RE: [jbosscache-dev] Re: Integrating steaming transfer in JBC
by Brian Stansberry
I added a JIRA to add the format to the CacheLoader javadoc:
http://jira.jboss.com/jira/browse/JBCACHE-738
Bela Ban wrote:
> That's well defined (via NodeData), and I also wrote some
> document explaining the format.
>
> Simple:
> - persistent state
> - marker
> - transient state
> - EOF
>
> 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.
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
19 years, 1 month
RE: [jbosscache-dev] Re: Integrating steaming transfer in JBC
by Brian Stansberry
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.
19 years, 1 month
RE: [jbosscache-dev] Re: Integrating steaming transfer in JBC
by Vladimir Blagojevic
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? We need some "end of in-memory
state" marker?
>
> 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.
19 years, 1 month
RE: [jbosscache-dev] Re: Integrating steaming transfer in JBC
by Brian Stansberry
Bela Ban wrote:
> Brian Stansberry wrote:
>> Really, the whole idea is to make the byte[] go away
>> -- it serves no purpose, and once its created most (probably all) of
>> the benefit of streaming state transfer is lost.
>
> I think streaming state transfer should be an *additional mechanism*,
> *not* replace the byte[] approach. The byte[] approach is
> certainly simpler, so for small to medium states, developers
> may not want to use the (somewhat more complex) streaming
> approach. Compare this to the XML pasring modeL DOM is the
> byte[] model, Stax/SAX are the streaminmg state model.
>
+1. What I meant there was *if you are using streaming*, you don't want
the byte[].
>> As you say the tricky part is how does the cache loader know the
>> boundaries of what to read? Probably the simplest solution is the
>> StateTransferGenerator ensures the persistent state is the last stuff
>> written; the receiving cache loader then just reads until there is no
>> more.
>
> The format has been defined and - if needed - should be
> defined again, so that different CacheLoaders can transfer
> state betwen each other, e.g. JDBCCacheLoader with
> JDBMCacheLoader. I suspect we also have to include the
> version numbers in this format...
Ah, so we'd actually have a specified format for persistent state, as
opposed to the current case where all the impls we write share a format,
but it's not specified. Cool :)
<snip>
>> Hmm. Perhaps the CacheLoader API needs to use
>> ObjectInput/OutputStream.
>
> I think Input/OutputStream is good enough, you can always
> wrap it with an OIS/OOS
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.
19 years, 1 month
RE: [jbosscache-dev] Re: Integrating steaming transfer in JBC
by Brian Stansberry
Right now the cache loaders are actually using a
ByteArrayInput/OutputStream to deal with the byte[]. So I wouldn't think
it would be a big deal to refactor a bit to deal with an externally
provided stream. Really, the whole idea is to make the byte[] go away
-- it serves no purpose, and once its created most (probably all) of the
benefit of streaming state transfer is lost.
As you say the tricky part is how does the cache loader know the
boundaries of what to read? Probably the simplest solution is the
StateTransferGenerator ensures the persistent state is the last stuff
written; the receiving cache loader then just reads until there is no
more. The StateTransferGenerator would write some kid of marker to the
stream to identify that the persistent state is about to start.
StateTransferIntegrator monitors for that, and passes the stream to the
cache loader once its read.
Hmm. Perhaps the CacheLoader API needs to use ObjectInput/OutputStream.
Have to think about that a bit.
Manik Surtani wrote:
> Well then this is the ideal time to do it, while the
> interfaces are still malleable.
>
> I suspect the quick and dirty impl for most cache loader
> impls will be to wait till the stream closes to capture the
> byte[] and process this rather than a more efficient on-the-fly
> approach.
>
>> Yep. The thread kind of morphed into a design discussion :)
>>
>> jbosscache-dev-bounces(a)lists.jboss.org wrote:
>>> (This should be on the jbc dev mail list, btw - or on the design
>>> forum if it warrants it)
>>>
>>> Vladimir/Brian:
>>>
>>> Does this relate to the need for something like:
>>>
>>> void storeEntireState(OutputStream s); InputStream
>>> loadEntireState(); void storeState(OutputStream s, Fqn subtree);
>>> InputStream loadState(Fqn subtree);
>>>
>>> In the CacheLoader interface?
>>>
>>> Firstly, is this feasible when it comes to cache loaders - e.g., a
>>> JDBC cache loader - what sort of stream markers will we have to let
>>> the cache loader know when it can start chunking up data from the
>>> stream, parsing it and pushing this state down to storage?
> Or will
>>> it just be an API-level kludge where the CL impl attempts to keep
>>> reading from the stream until the stream closes, yanks out a byte[]
>>> and passes that into storeEntireState(byte[] b)? (May be the case
>>> for an initial impl, just so we have the interface methods in place
>>> for
>>> 2.0.0)
>>>
>>> Cheers,
>>>
>>>> I should have sent a copy to Manik and Bela as well. See below.
>>>>
>>>> Main point is: we need additional methods in CacheLoader to
>>>> accommodate streaming state transfer.
>>>> How should we proceed?
>>>>
>>>> Vladimir
>>>>
>>>> -----Original Message-----
>>>> From: Vladimir Blagojevic
>>>> Sent: Tuesday, August 15, 2006 11:41 AM
>>>> To: Brian Stansberry
>>>> Subject: RE: Integrating steaming transfer in JBC
>>>>
>>>> Oyyyy. Not only that but it also affects CacheLoader API:
>>>>
>>>> byte[] loadEntireState() throws Exception; void
>>>> storeEntireState(byte[] state) throws Exception; byte[] loadState
>>>> (Fqn subtree) throws Exception; void storeState(byte[] state, Fqn
>>>> subtree) throws Exception;
>>>>
>>>> These should have streaming counterparts if we really want large
>>>> state OOME to go away....
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Brian Stansberry
>>>> Sent: Tuesday, August 15, 2006 11:27 AM
>>>> To: Vladimir Blagojevic
>>>> Subject: RE: Integrating steaming transfer in JBC
>>>>
>>>> Yep, plus there are different types of state that will be handled
>>>> by different subsystems; that will be interesting for streaming
>>>> state transfer.
>>>>
>>>> Also, for buddy replication, the state transfer is a push rather
>>>> than a pull. Not sure what to do about that :(
>>>>
>>>> Vladimir Blagojevic wrote:
>>>>> Ok I see. So it is not only integration of state transfer but
>>>>> removing
>>>>
>>>>> rpc mechanism for partial state integration. I am looking at the
>>>>> code and learning how is this done. Then I'll ping you tomorrow/
>>>>> Thursday to
>>>>
>>>>> have a discussion with you.
>>>>>
>>>>> -----Original Message-----
>>>>> From: Brian Stansberry
>>>>> Sent: Monday, August 14, 2006 3:02 PM
>>>>> To: Vladimir Blagojevic
>>>>> Subject: RE: Integrating steaming transfer in JBC
>>>>>
>>>>> Just look at the JBCACHE issues and filter for the ones assigned
>>>>> to you :)
>>>>>
>>>>> Vladimir Blagojevic wrote:
>>>>>> Hey,
>>>>>>
>>>>>> What do you mean by looking at the non streaming state transfer
>>>>>> tasks? Which ones are those?
>>>>>>
>>>>>> Vladimir
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: "Brian Stansberry" <brian.stansberry(a)jboss.com>
>>>>>> Date: Mon, 14 Aug 2006 12:24:35
>>>>>> To:<vladimirb(a)rogers.blackberry.net>
>>>>>> Subject: RE: Integrating steaming transfer in JBC
>>>>>>
>>>>>> Sure, just let me know. But, I'd start with looking at the
>>>>>> non-streaming state transfer tasks. That will get you familiar
>>>>>> with the use cases and existing code.
>>>>>>
>>>
>>> _______________________________________________
>>> jbosscache-dev mailing list
>>> jbosscache-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>
>>
>>
>> Brian Stansberry
>> Lead, AS Clustering
>> JBoss, a division of Red Hat
>> Ph: 510-396-3864
>> skype: bstansberry
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
19 years, 1 month