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

[Galder Zamarreno]

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