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

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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosscache-dev > > -- > 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