Re: Region registry is scoped by VM rather than cache instance
by Manik Surtani
Yes, this is a good point. This is a new API anyway and I just put
it there as a placeholder for the time being. +1 to making it a
member of TreeCache rather than a static instance. Could you please
go ahead and move the REGIONS_REGISTRY from being a static member of
RegionImpl to a member of TreeCache - or maybe RegionImpl (since each
TreeCache instance will have 1 RegionImpl instance if region based
marshalling is used).
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 23 Aug 2006, at 15:35, Vladimir Blagojevic wrote:
> Hey Manik,
>
> Take a look at TreeCacheProxyImpl.getRegion(). If there are >1 cache
> instances in JVM created using cache factory (just as in state
> transfer
> unit tests) then regions will be mixed up between different cache
> instance. Static region map declared in RegionImpl should perhaps be
> moved to a non-static map in cache instance?
>
> Or am I completely misunderstanding this.
>
> Vladimir
>
>
> P.S this is the reason why some state transfer tasks continue to fail.
19 years, 1 month
State transfer unit tests status
by Vladimir Blagojevic
The cause of OptionalDataException that was messing up state transfers
is now fixed. However, "Initial state transfer failed" error was still
popping up in some tests. The cause of this error is incorrect logic in
TreeCache.startService related to fetching of in memory state. JBC can
not fetch in memory state based only on FetchInMemoryState element but
should rather use JBC 1.4 logic?
protected boolean shouldFetchStateOnStartup() {
return !configuration.isInactiveOnStartup() && buddyManager == null
&&
(configuration.isFetchInMemoryState() || (cacheLoaderManager
!= null &&
cacheLoaderManager.isFetchPersistentState()));
}
When I use this approach "Initial state transfer failed" errors go away.
State transfer tests now fail on:
1) Region exceptions
org.jboss.cache.RegionNotEmptyException: Node / already exists and is
not empty at
org.jboss.cache.TreeCache.activateRegion(TreeCache.java:954) at
2) Activators
Activator A caught an exception
junit.framework.AssertionFailedError: Activator A caught an exception at
org.jboss.cache.statetransfer.VersionedTestBase.concurrentActivationTest
(VersionedTestBase.java:427) at
org.jboss.cache.statetransfer.VersionedTestBase.testConcurrentActivation
Sync(VersionedTestBase.java:353)
3) Buddy integration
node /a/d not found (gtx=null, caller=Thread[main,5,main])
org.jboss.cache.NodeNotExistsException: node /a/d not found (gtx=null,
caller=Thread[main,5,main]) at
org.jboss.cache.TreeCache._put(TreeCache.java:2783) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
19 years, 1 month
RE: [jbosscache-dev] Habanero: implementing peek() and _*() methods
by Galder Zamarreno
+1 on not having direct access to any methods the client should not be calling.
Alternatives to access to those methods are not easy. An interface extending CacheSPI with these methods? I haven't been following the progress of 2.0.0 that much so maybe I'm saying something that's already been said...
Galder Zamarreño
Support Engineer
JBoss, a division of RedHat
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Manik Surtani
Sent: 16 August 2006 19:15
To: Ben Wang
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] Habanero: implementing peek() and _*() methods
The SPI is still for end users - people who write custom cache
loaders, custom interceptors, etc. I'd rather not have direct access
methods here, somehow. What does everyone think?
--
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 16:11, Ben Wang wrote:
> 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
>
_______________________________________________
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 Galder Zamarreno
This is precisely what we're discussing when I was pondering how to transfer in-memory state to the persistent one as part of the SingletonCacheLoader development.
+1
Galder Zamarreño
Support Engineer
JBoss, a division of RedHat
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Brian Stansberry
Sent: 15 August 2006 22:16
To: Bela Ban
Cc: Manik Surtani; jbosscache-dev(a)lists.jboss.org
Subject: RE: [jbosscache-dev] Re: Integrating steaming transfer in JBC
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
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
19 years, 1 month
RE: Integrating streaming state transfer - design brainstorming
by Brian Stansberry
You need to think through whether the changes you make can be introduced
in AS 5.0.1 without making interoperability with 5.0.0 impossible. If
they can, they can be deferred to a JBC release that goes in 5.0.1. If
not, they need to be in a release for 5.0.0, or they remain a
non-default option for the life of the 5.0.0 series.
Vladimir Blagojevic wrote:
> We have FLUSH already in place. I agree with your proposal to
> include SST for 2.0.0 and to leave partial state transfer and
> locks for 2.1.0. It might be too late to squeeze everything in 2.0.0.
>
> However, I am not sure how it affects Jboss 5.0 timeline?
>
> Bela?
>
>
>
>> -----Original Message-----
>> From: Manik Surtani [mailto:manik@jboss.org]
>> Sent: Thursday, August 17, 2006 12:01 PM
>> To: Vladimir Blagojevic
>> Cc: Brian Stansberry; jbosscache-dev(a)lists.jboss.org
>> Subject: Re: Integrating streaming state transfer - design
>> brainstorming
>>
>> The two issues below require FLUSH, am I right?
>>
>> Can things not be phased in - just SST for now (2.0.0), and partial
>> state transfer and breaking of locks for 2.1.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 17 Aug 2006, at 16:18, Vladimir Blagojevic wrote:
>>
>>> Brian,
>>>
>>> I already did ask him about integration of streaming state transfer
>>> but I did not for this other stuff. I think I better talk to him
>>> first about everything. Lets postpone our conference call to after
>>> I talk to Manik.
>>>
>>> Manik,
>>>
>>> I am unsure how to procede with integration of streaming state
>>> transfer since it also affects partial state transfer, activation
>>> etc etc. See Jira issue below.
>>>
>>> Let me know.
>>>
>>>
>>> Vladimir
>>>
>>>> -----Original Message-----
>>>> From: Brian Stansberry
>>>> Sent: Thursday, August 17, 2006 11:09 AM
>>>> To: Vladimir Blagojevic
>>>> Subject: RE: Integrating streaming state transfer - design
>>>> brainstorming
>>>>
>>>> OK, but please try to ping Manik first re: what release it goes
>>>> in. That's up to you two.
>>>>
>>>> Vladimir Blagojevic wrote:
>>>>> Brian,
>>>>>
>>>>> I think I have sufficient understanding of how streaming needs to
>>>>> be integrated. I see how activation is using rpc calls to do
>>>>> partial state transfer and how this needs to be upgraded to
>>>>> partial streaming transfers.
>>>>>
>>>>> Some of these tasks that are assigned to me are marked for
>>>>> 2.1 version. I admit I am a bit confused how to proceed.
>>>>>
>>>>> So how's today afternoon for a talk? Maybe 3 pm EST? Or any other
>>>>> time that suits you.
>>>>>
>>>>> Vladimir
>>>>>
>>>>>
>>>>>
>>>>> http://jira.jboss.com/jira/browse/JBCACHE-591
>>>>> http://jira.jboss.com/jira/browse/JBCACHE-315
>>>>
>>>>
>>>>
>>>> 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
RE: Integrating streaming state transfer - design brainstorming
by Vladimir Blagojevic
We have FLUSH already in place. I agree with your proposal to include
SST for 2.0.0 and to leave partial state transfer and locks for 2.1.0.
It might be too late to squeeze everything in 2.0.0.
However, I am not sure how it affects Jboss 5.0 timeline?
Bela?
> -----Original Message-----
> From: Manik Surtani [mailto:manik@jboss.org]
> Sent: Thursday, August 17, 2006 12:01 PM
> To: Vladimir Blagojevic
> Cc: Brian Stansberry; jbosscache-dev(a)lists.jboss.org
> Subject: Re: Integrating streaming state transfer - design
> brainstorming
>
> The two issues below require FLUSH, am I right?
>
> Can things not be phased in - just SST for now (2.0.0), and
> partial state transfer and breaking of locks for 2.1.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 17 Aug 2006, at 16:18, Vladimir Blagojevic wrote:
>
> > Brian,
> >
> > I already did ask him about integration of streaming state transfer
> > but I did not for this other stuff. I think I better talk
> to him first
> > about everything. Lets postpone our conference call to
> after I talk to
> > Manik.
> >
> > Manik,
> >
> > I am unsure how to procede with integration of streaming state
> > transfer since it also affects partial state transfer,
> activation etc
> > etc. See Jira issue below.
> >
> > Let me know.
> >
> >
> > Vladimir
> >
> >> -----Original Message-----
> >> From: Brian Stansberry
> >> Sent: Thursday, August 17, 2006 11:09 AM
> >> To: Vladimir Blagojevic
> >> Subject: RE: Integrating streaming state transfer - design
> >> brainstorming
> >>
> >> OK, but please try to ping Manik first re: what release it
> goes in.
> >> That's up to you two.
> >>
> >> Vladimir Blagojevic wrote:
> >>> Brian,
> >>>
> >>> I think I have sufficient understanding of how streaming
> >> needs to be
> >>> integrated. I see how activation is using rpc calls to do partial
> >>> state transfer and how this needs to be upgraded to partial
> >> streaming
> >>> transfers.
> >>>
> >>> Some of these tasks that are assigned to me are marked for
> >>> 2.1 version. I admit I am a bit confused how to proceed.
> >>>
> >>> So how's today afternoon for a talk? Maybe 3 pm EST? Or any
> >> other time
> >>> that suits you.
> >>>
> >>> Vladimir
> >>>
> >>>
> >>>
> >>> http://jira.jboss.com/jira/browse/JBCACHE-591
> >>> http://jira.jboss.com/jira/browse/JBCACHE-315
> >>
> >>
> >>
> >> Brian Stansberry
> >> Lead, AS Clustering
> >> JBoss, a division of Red Hat
> >> Ph: 510-396-3864
> >> skype: bstansberry
>
>
>
19 years, 1 month
Re: Integrating streaming state transfer - design brainstorming
by Manik Surtani
The two issues below require FLUSH, am I right?
Can things not be phased in - just SST for now (2.0.0), and partial
state transfer and breaking of locks for 2.1.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 17 Aug 2006, at 16:18, Vladimir Blagojevic wrote:
> Brian,
>
> I already did ask him about integration of streaming state transfer
> but
> I did not for this other stuff. I think I better talk to him first
> about
> everything. Lets postpone our conference call to after I talk to
> Manik.
>
> Manik,
>
> I am unsure how to procede with integration of streaming state
> transfer
> since it also affects partial state transfer, activation etc etc. See
> Jira issue below.
>
> Let me know.
>
>
> Vladimir
>
>> -----Original Message-----
>> From: Brian Stansberry
>> Sent: Thursday, August 17, 2006 11:09 AM
>> To: Vladimir Blagojevic
>> Subject: RE: Integrating streaming state transfer - design
>> brainstorming
>>
>> OK, but please try to ping Manik first re: what release it
>> goes in. That's up to you two.
>>
>> Vladimir Blagojevic wrote:
>>> Brian,
>>>
>>> I think I have sufficient understanding of how streaming
>> needs to be
>>> integrated. I see how activation is using rpc calls to do partial
>>> state transfer and how this needs to be upgraded to partial
>> streaming
>>> transfers.
>>>
>>> Some of these tasks that are assigned to me are marked for
>>> 2.1 version. I admit I am a bit confused how to proceed.
>>>
>>> So how's today afternoon for a talk? Maybe 3 pm EST? Or any
>> other time
>>> that suits you.
>>>
>>> Vladimir
>>>
>>>
>>>
>>> http://jira.jboss.com/jira/browse/JBCACHE-591
>>> http://jira.jboss.com/jira/browse/JBCACHE-315
>>
>>
>>
>> Brian Stansberry
>> Lead, AS Clustering
>> JBoss, a division of Red Hat
>> Ph: 510-396-3864
>> skype: bstansberry
19 years, 1 month
RE: [jbosscache-dev] Fwd: Transparent Clustering, Organic Distributed Systems, ...
by Ben Wang
Please go ahead. To be frank, when I read Cameron's description of "social organism" for clustering, it is catchy on the surface. But I have had a hard time to understand what's so revolutionary about it? Must be getting old then. :-(
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Manik Surtani
Sent: Thursday, August 17, 2006 7:39 AM
To: jbosscache-dev(a)lists.jboss.org
Subject: [jbosscache-dev] Fwd: Transparent Clustering,Organic Distributed Systems, ...
This is actually a very interesting article and discussion (the one on Purdy's blog, not the one on Artima). Enjoying reading this.
I'll respond in the morning though - 1am blog postings are bound to bring about doom. :)
--
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
Begin forwarded message:
> From: Bill Venners <bv-svp(a)artima.com>
> Date: 17 August 2006 00:23:48 BDT
> To: Manik Surtani <manik(a)jboss.org>
> Cc: Ben Wang <ben.wang(a)jboss.com>
> Subject: Transparent Clustering, Organic Distributed Systems, ...
>
> Hi Manik and Ben,
>
> Just wanted to let you know that even though I haven't yet finished
> the articles I interviewed you for, some of the issues showed up in
> Cameron Purdy's weblog. So now there's some discussion here:
>
> http://www.artima.com/forums/flat.jsp?forum=106&thread=172063
>
> Feel free to chime in. I'm still going to write the articles, but
> perhaps we can hash out some of the issues in the forum.
>
> Thanks.
>
> Bill
> ----
> Bill Venners
> Editor-in-Chief
> Artima Developer
> http://www.artima.com
>
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
19 years, 1 month
Fwd: Transparent Clustering, Organic Distributed Systems, ...
by Manik Surtani
This is actually a very interesting article and discussion (the one
on Purdy's blog, not the one on Artima). Enjoying reading this.
I'll respond in the morning though - 1am blog postings are bound to
bring about doom. :)
--
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
Begin forwarded message:
> From: Bill Venners <bv-svp(a)artima.com>
> Date: 17 August 2006 00:23:48 BDT
> To: Manik Surtani <manik(a)jboss.org>
> Cc: Ben Wang <ben.wang(a)jboss.com>
> Subject: Transparent Clustering, Organic Distributed Systems, ...
>
> Hi Manik and Ben,
>
> Just wanted to let you know that even though I haven't yet finished
> the articles I interviewed you for, some of the issues showed up in
> Cameron Purdy's weblog. So now there's some discussion here:
>
> http://www.artima.com/forums/flat.jsp?forum=106&thread=172063
>
> Feel free to chime in. I'm still going to write the articles, but
> perhaps we can hash out some of the issues in the forum.
>
> Thanks.
>
> Bill
> ----
> Bill Venners
> Editor-in-Chief
> Artima Developer
> http://www.artima.com
>
19 years, 1 month