I get a build failure when invoking dist target: ...... lang.dochtmlsingle: [mkdir] Created dir: C:\work\repos\JBossCache-HEAD\docs\build\en \html_single [copy] Copying 1 file to C:\work\repos\JBossCache-HEAD\docs \build\en\html_single\css javadocs: [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Creating destination directory: "C:\work\repos \JBossCache-HEAD\output\api\" [javadoc] javadoc: error - Illegal package name: "&#169;" [javadoc] javadoc: error - Illegal package name: "1998-2007" [javadoc] javadoc: error - Illegal package name: "Inc.</b>" [javadoc] javadoc: error - Illegal package name: "Reserved.</i></ p> -classpath C:\work\repos\JBossCache-HEAD\lib\bs he-HEAD\lib\commons-logging-1.1.jar;C:\work\repos\JBossCache-HEAD \lib\concurrent.jar;C:\work\repos\JBossCache-HEAD\li e-HEAD\lib\jboss-aop-jdk50.jar;C:\work\repos\JBossCache-HEAD\lib \jboss-common-core.jar;C:\work\repos\JBossCache-HEAD\ k\repos\JBossCache-HEAD\lib\jcip-annotations.jar;C:\work\repos \JBossCache-HEAD\lib\jdbm-1.0.jar;C:\work\repos\JBossCa repos\JBossCache-HEAD\lib\junit.jar;C:\work\repos\JBossCache-HEAD \lib\log4j-1.2.14.jar;C:\work\repos\JBossCache-HEAD\ @C:\DOCUME~1\Vladimir\LOCALS~1\Temp\javadoc1053255913" [javadoc] Loading source files for package Red... [javadoc] javadoc: warning - No source files for package Red [javadoc] Loading source files for package Hat... [javadoc] javadoc: warning - No source files for package Hat [javadoc] Loading source files for package All... [javadoc] javadoc: warning - No source files for package All [javadoc] Loading source files for package Rights... [javadoc] javadoc: warning - No source files for package Rights [javadoc] 4 errors [javadoc] 4 warnings dist: [mkdir] Created dir: C:\work\repos\JBossCache-HEAD\tmp [mkdir] Created dir: C:\work\repos\JBossCache-HEAD\tmp\lib [mkdir] Created dir: C:\work\repos\JBossCache-HEAD\tmp\docs [mkdir] Created dir: C:\work\repos\JBossCache-HEAD\tmp\examples [mkdir] Created dir: C:\work\repos\JBossCache-HEAD\tmp\tests [mkdir] Created dir: C:\work\repos\JBossCache-HEAD\tmp\etc [mkdir] Created dir: C:\work\repos\JBossCache-HEAD\tmp\resources [mkdir] Created dir: C:\work\repos\JBossCache-HEAD\tmp\docs\javadoc [mkdir] Created dir: C:\work\repos\JBossCache-HEAD\tmp\docs\faq [mkdir] Created dir: C:\work\repos\JBossCache-HEAD\tmp\docs\faq- pojo [mkdir] Created dir: C:\work\repos\JBossCache-HEAD\tmp\docs \tutorial [mkdir] Created dir: C:\work\repos\JBossCache-HEAD\tmp\docs \tutorial-pojo [mkdir] Created dir: C:\work\repos\JBossCache-HEAD\tmp\docs \JBossCache-UserGuide [mkdir] Created dir: C:\work\repos\JBossCache-HEAD\tmp\docs \PojoCache [mkdir] Created dir: C:\work\repos\JBossCache-HEAD\tmp\ant-dist [mkdir] Created dir: C:\work\repos\JBossCache-HEAD\tmp\src [copy] Copying 16 files to C:\work\repos\JBossCache-HEAD\tmp \ant-dist [copy] Copying 6 files to C:\work\repos\JBossCache-HEAD\tmp [copy] Copying 1 file to C:\work\repos\JBossCache-HEAD\tmp \resources [copy] Copying 3 files to C:\work\repos\JBossCache-HEAD\tmp [copy] Copying 43 files to C:\work\repos\JBossCache-HEAD\tmp\etc [move] Moving 1 files to C:\work\repos\JBossCache-HEAD\tmp\etc [copy] Copying 1030 files to C:\work\repos\JBossCache-HEAD\tmp \tests [copy] Copying 79 files to C:\work\repos\JBossCache-HEAD\tmp \examples [copy] Copying 25 files to C:\work\repos\JBossCache-HEAD\tmp\lib BUILD FAILED C:\work\repos\JBossCache-HEAD\build.xml:1318: C:\work\repos \JBossCache-HEAD\docs\faq\build not found. Total time: 1 minute 37 seconds C:\work\repos\JBossCache-HEAD> Manik Surtani wrote: > Guys, > > In preparing for rewriting the tutorial for 2.0.0, I've updated > the GUI as well. Could you please get this from HEAD and let me > know what you think. Feedback would be very useful. > > 1) Check out CVS HEAD > 2) ./build.sh dist > 3) Unzip the JBossCache-core-2.0.0 distro zip file in dist/ > 4) In the JBossCache-core-2.0.0 directory, run ./build.sh run.demo > 5) Do the above AGAIN in another shell window. > > You should now have 2 GUI instances, both with embedded beanshell > panes (thanks to Vladimir for his initial work on this). > > Now to write up the documentation for the tutorial, taking users > through the cache API. :-) One of the other things I have done > is update and comment the source code for the GUI and View - since > I expect users to look at this source code as a "live" example. > > Please let me know your thoughts. > > Cheers, > -- > 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

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,

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, >

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

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

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(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 > -- 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

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