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

Manik Surtani manik at jboss.org
Thu Apr 26 06:34:33 EDT 2007


Thanks for creating this, Galder.

Guys, since we're on the topic of the tutorial, is there any feedback  
on the core cache tutorial?  Do you think it sufficiently covers  
basic usage of the cache to get a user started, or should there be  
more stuff?


On 25 Apr 2007, at 18:00, Galder Zamarreno wrote:

> That is a very good point actually.
>
> Let's make it more obvious in the docu for users and problem solved :)
>
> http://jira.jboss.com/jira/browse/JBCACHE-1036
>
> Brian Stansberry wrote:
>> Re: the handling of getState, if the state transfer is not done  
>> via RPC but rather via the JGroups state transfer protocols, the  
>> sender cache has no way to know what the receiver wants (in  
>> memory, persistent).  It can only rely on its own configuration to  
>> decide what to send.
>> Galder Zamarreno wrote:
>>> Alternatively, if that code is behaving as it should, why is  
>>> there that "hack" to prevent in memory state transfer for the  
>>> GUI? So that it always starts empty?
>>>
>>> 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






More information about the jbosscache-dev mailing list