[jbosscache-dev] Fixing PojoCache tutorial - exception from getState
Manik Surtani
manik at jboss.org
Wed Apr 25 09:46:01 EDT 2007
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
More information about the jbosscache-dev
mailing list