[jbosscache-dev] Fixing PojoCache tutorial - exception from getState

[Jason T. Greene]

Yes, IMO, that could be made more clear.

On Wed, 2007-04-25 at 16:32 +0200, Galder Zamarreno wrote:
> Fair enough. I guess it also makes it easier to debug if all nodes have 
> the same configuration. However, if we want to enforce it, we might 
> wanna tweak the docu to say that FetchInMemoryState must be true both 
> for setting and getting state.
> 
> Thoughts?
> 
> Manik Surtani wrote:
> > Well, typical in a P2P system, all parties need to play nice.  Both the 
> > requestor and provider need to be configured to deal with state transfers.
> > 
> > 
> > On 25 Apr 2007, at 14:10, Vladimir Blagojevic wrote:
> > 
> >> Hey,
> >>
> >> What about the point the Galder is making related to state provider 
> >> deciding as well if state should be provided or not? I guess the 
> >> argument against Galder's suggestion is that we need symmetrical 
> >> configuration in a cluster and cannot let *only* state requester 
> >> decide if state should be fetched or not...
> >>
> >> Vladimir
> >>
> >> Manik Surtani wrote:
> >>> Do you want to be using a separate bsh script for the PojoCache 
> >>> tutorial as well?
> >>>
> >>> I would have thought you'd use the same JBossCacheView which has an 
> >>> embedded BeanShell pane (thanks, Vladimir) and just change the 
> >>> contents of the tutorial?
> >>>
> >>> Re: the state transfer hack, I thought I removed that ... oops!  :-)
> >>>
> >>> On 24 Apr 2007, at 22:45, Galder Zamarreno wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I'm trying to fix the tutorial for PojoCache. This works slightly 
> >>>> different because you have an instance of the GUI and then the code 
> >>>> entered via ./runShellDemo.sh
> >>>>
> >>>> I have noted that in JBossCacheView, there following happens before 
> >>>> starting the cache:
> >>>>
> >>>> // hack to prevent a state transfer for now
> >>>> cache.getConfiguration().setFetchInMemoryState(false);
> >>>>
> >>>> pojocache.bsh which is loaded via ./runShellDemo.sh still uses the 
> >>>> same replSynch-service.xml descriptor but it does not set fetch in 
> >>>> memory to false.
> >>>>
> >>>> So, if you start the GUI first, and then execute ./runShellDemo.sh 
> >>>> and then type sourceRelative("pojocache.bsh");, you get an exception 
> >>>> like this:
> >>>>
> >>>> "Caused by: org.jboss.cache.CacheException: Cache instance at 
> >>>> 127.0.0.1:33058 cannot integrate state since state provider could 
> >>>> not provide state due to org.jboss.cache.CacheException: Cache 
> >>>> instance at 127.0.0.1:33056 is not configured to provide state"
> >>>>
> >>>> Now, i'm debating the suitability of the following code in 
> >>>> StateTransferManager.getState:
> >>>>
> >>>> if (!fetchPersistentState && !fetchTransientState)
> >>>> {
> >>>> e = new CacheException("Cache instance at " + 
> >>>> cache.getLocalAddress() + " is not configured to provide state");
> >>>> }
> >>>>
> >>>> Documentation says: "FetchInMemoryState: Whether or not to acquire 
> >>>> the initial in-memory state from existing members. "
> >>>>
> >>>> It does not say anything about giving a state. There's nothing 
> >>>> saying that a cache not configured to fetch should not be able to 
> >>>> give it. I mean, a cache could potentially be configured not to 
> >>>> retrieve transient state on startup, but another cache could be 
> >>>> configured to do so and should be able to retrieve it from the first 
> >>>> cache started, shouldn't it?
> >>>>
> >>>> Cheers,
> >>>>
> >>>> --Galder Zamarreño
> >>>> Sr. Software Maintenance Engineer
> >>>> JBoss, a division of Red Hat
> >>>> _______________________________________________
> >>>> jbosscache-dev mailing list
> >>>> jbosscache-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
> >>>
> >>> -- 
> >>> 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
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> jbosscache-dev mailing list
> >>> jbosscache-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
> >>
> > 
> > -- 
> > 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
> > 
> > 
> 
> -- 
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Jason T. Greene
Lead, POJO Cache
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx