[jboss-user] [JBoss Cache: Core Edition] - Success story
I wrote a small article regarding a project I did some time ago where we clustered our load-servers together using JBoss Cache to create a load server farm. It is not a complex solution by any means, but it's somewhat of a success story and outlines a simple distribution of work solution using JBC so I thought maybe someone here would enjoy it =) You can find the article here: http://www.cubeia.com/index.php?option=com_contenttask=viewid=28Itemid=9 View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=4208662#4208662 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4208662 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Cache: Core Edition] - Re: Exception when a cluster node joins under load
I'm pretty sure that upgrading to JBC 2.1.0 GA and JGroups 2.6.2 did resolve the not in started state errors for us. Unfortunately we ran into other issues when using sync replication on versions 2.0.0 so we're still running 2.0.0. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4157670#4157670 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4157670 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Cache: Core Edition] - Re: Exception when a cluster node joins under load
Posted here: http://www.jboss.com/index.html?module=bbop=viewtopict=135172 View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4157799#4157799 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4157799 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Cache: Core Edition] - Re: Exception when a cluster node joins under load
Our workaround consisted of 'stopping the world', i.e. halt everything in the system while the new node is connecting and transferring state data. Then start execution again when we can guarantee that the JBC has stabilized. Unfortunately we have still not been able to have a jboss cache node join a cluster under load without encountering errors and/or unexpected behaviour. See: http://www.jboss.com/index.html?module=bbop=viewtopict=135172 View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4156499#4156499 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4156499 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Cache: Core Edition] - Re: State transfer errors
Did you ever find something out regarding this? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4151744#4151744 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4151744 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Cache: Core Edition] - Re: Data Gravitation
I have done some small scale tests with FetchInMemoryState set to false and it seems to be working and does not interfere with the expected behavior (as long as we are using buddy replication). We will make larger scale tests for this when 2.1.1.GA is released. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4148319#4148319 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4148319 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Cache: Core Edition] - Re: Getting data from a node
Cheers. The JIRA issue is currently due for 2.2.0, is this correct or do you think it might be included in 2.1.1? If the fix is likely to be included in 2.1.1 then we wont bother with implementing a workaround but rather wait for 2.1.1 =) View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4148097#4148097 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4148097 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Cache: Core Edition] - Re: Getting data from a node
The returned map from the node seems to be an instance of java.util.Collections$UnmodifiableMap. The javadoc for the UnmodifiableMap specifies: anonymous wrote : unmodifiableMap | | public static K,V MapK,V unmodifiableMap(Map? extends K,? extends V m) | | Returns an unmodifiable view of the specified map. This method allows modules to provide users with read-only access to internal maps. Query operations on the returned map read through to the specified map, and attempts to modify the returned map, whether direct or via its collection views, result in an UnsupportedOperationException. | | The returned map will be serializable if the specified map is serializable. | | Parameters: | m - the map for which an unmodifiable view is to be returned. | Returns: | an unmodifiable view of the specified map. I would say it is plausible that the unmodifiedMap provides an immutable view but is still backed by a map which will reflect changes to the underlying data thus creating a map which is not safe to iterate in concurrent situations. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4147756#4147756 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4147756 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Cache: Core Edition] - Getting data from a node
We have seen ConcurrentModificationExceptions in our system when handling data maps returned from a node. In the JBC javadoc it is specified that the method Node.getData() should return an immutable map. anonymous wrote : Returns: | a Map containing the data in this Node. If there is no data, an empty Map is returned. The Map returned is always immutable. | Is this still true for 2.1.0.GA? Since there was no other way I could possibly see the exception occur in our system I whipped together a quick test to see if I could rely on the returned map not to change. What I found was that you cannot safely iterate the returned data map if other threads are changing the cache, which seems to imply that the returned map is not immutable. You can find the simple test here: http://www.cubeia.com/misc/nodedata/ It is not possible to take a defensive copy of the map either since we then might end up with a ConcurrentModificationExceptions in the initialization of the new map (this was actually the case of the original error). View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4147749#4147749 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4147749 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Cache: Core Edition] - Data Gravitation
Hi. We have been experiencing an issue in our system when enabling buddy replication. The issue manifests itself in way that replication seems to be completely missing. We can turn the issue on and off by enabling/disabling buddy replication so I have focused on isolating the problem in a stand-alone test. In my test scenario I am now able to create something I think is a bug. I am using two caches with buddy replication enabled and force data gravitation between them. I then fail the secondary cache and examine if the data was recoverable on the primary cache. This works like a charm. However, when I do this a second time around, i.e. start up a new cache again, the same scenario fails. The second time, the objects gravitated from the primary cache are not removed as they are the first time around and when we inspect the cache for recovered data after failing the second secondary cache, we get the wrong data. The primary cache has the correct data under its _buddy_backup node but since it prefers its own data, it will read the 'wrong' version. This is pretty complex to explain, so I have posted the complete test code here: http://www.cubeia.com/misc/buddyrep/ I've tried to add comments to the code to be as explanatory as possible. The test was written for 2.1.0.GA. I do have an understanding of data affinity and what the concept implies, however, I believe that the test do not break or abuse data affinity but rather tests fail-over scenarios when using buddy replication. Finally, why should the behavior change because the cache had a member in the past? I hope you can run the test and try it out. Just ask away if the code not making any sense to you =) View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4144478#4144478 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4144478 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Concurrency issue in OrderedSynchronizationHandler (2.0.
I just experienced what might be the same problem. I started up 6 nodes and one node was using up all CPU without any real load on it. Dumping all stacks shows that all threads are parked except one which is stuck on map.get in OrderedSynchronizationHandler. ReceivingGameEventDaemon-1 prio=1 tid=0x092d5eb0 nid=0x5660 runnable [0x85421000..0x85421f30] | at java.util.HashMap.get(HashMap.java:346) | at org.jboss.cache.interceptors.OrderedSynchronizationHandler.getInstance(OrderedSynchronizationHandler.java:50) | at org.jboss.cache.interceptors.TxInterceptor.registerHandler(TxInterceptor.java:901) | at org.jboss.cache.interceptors.TxInterceptor.registerTransaction(TxInterceptor.java:877) | at org.jboss.cache.interceptors.TxInterceptor.attachGlobalTransaction(TxInterceptor.java:342) | at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:292) | at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:131) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) | at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:81) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) | at org.jboss.cache.interceptors.InvocationContextInterceptor.invoke(InvocationContextInterceptor.java:62) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) | View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4134856#4134856 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4134856 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: What isolation mode do you use and why?
We use repeatable read and read uncommitted (different caches). We use read_uncommitted only to ensure a reader is never blocked. If read_committed would always allow read then we would be happy using that instead. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4129643#4129643 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4129643 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Exception when a cluster node joins under load
Are you using 2.0.0 GA? We have encountered this problem for 2.0.0 GA and never solved it properly. Currently we have a smelly workaround for it. I have a simple test project for replicating this (for v2.0.0), but its real easy to replicate: Setup one node that is making changes to a couple of nodes to the cache and bring up a new node that joins the cluster. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4119819#4119819 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4119819 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Buddyrep issue
Wow, that was fast =) The issue is indeed fixed for the standalone test case. We will probably wait for the CR3 release before we test with our real application. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4117525#4117525 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4117525 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: How to use fully-eplicated and buddy-replicated caches w
Why don't you just use separate regions in the cache?
I.e.:
root {}
| /data_a
| /... // first data set here
| /data_b
| /... // second data set here
That way you use one cache for your data.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4117527#4117527
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4117527
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Buddyrep issue
We do apply session affinity. Look at this way: 1. Cache A starts 2. Cache A adds 10 nodes to the cache 3. Cache B starts 4. Cache B 'gets' the 10 nodes thus causing a gravitation After #4 in the sequence we end up with the weird buddy rep settings as discussed above. This is exactly what we are doing in the test provided. We only go through the sequence once, we do not keep modifying/adding etc to the cache. (There is also a 5 second sleep between 3 and 4). Just to clarify: We do not add data to the cache while trying to read it. We do not modify data to the cache while trying to read it. In fact there is no concurrent access at all in the test provided. The issue is clearly related to data gravitation, in the logs we see that the buddy backup is correctly setup before gravitation occurs (i.e. after #3 in the sequence above), but has changed to include itself after data gravitation has occurred (after #4 in the sequence). I'll try and make a comparison run with 2.0.0 GA and post the logs, if behavior is unchanged then we should get the same buddy backup result. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4117065#4117065 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4117065 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Buddyrep issue
I tried a snapshot build from SVN (revision 4982) but the result is still the
same .
Actually I was not entirely accurate in the sequence description. It should be
like this:
1. Cache A starts
2. Cache A adds 10 nodes to the cache
3. Cache B starts
4. Cache B 'gets' 9 nodes thus causing a gravitation
I'm not sure why I decided to gravitate 9/10 nodes, but there it is. I have
modified a producer log to include the sequence numbers so you can follow the
sequences in the log better. You can find a log containing the sequences here:
http://www.robotsociety.com/cache/br/producer_seq.log
You can see a comparison between running the provided test for 2.0.0 GA and
2.1.0 CR2 here:
2.0.0 GA producer log :
http://www.robotsociety.com/cache/br/2.0.0/producer_2.0.0.log
2.1.0 CR2 producer log :
http://www.robotsociety.com/cache/br/2.1.0%20CR2/producer_2.1.0_cr2.log
To sum the comparison up, the 2.0.0 GA and 2.1.0 CR2 are equal until data has
gravitated. Then we can see that for 2.0.0 GA the cache in the producer looks
like:
2.0.0 GA:
| null {}
| /9 {4=85969gehp9xt}
| /_BUDDY_BACKUP_ {}
| /192.168.1.135_51890 {}
| /3 {4=xapfkubptgx0}
| /5 {2=17z0dcpunsivo}
| /7 {2=1kr0r0fpucxmy}
| /2 {1=1cdp3dootdbu9}
| /0 {0=cvwo5pn5r7ou}
| /4 {4=1wzvk2sq01r1p}
| /8 {0=1vfthyv0lbkvw}
| /6 {2=i5az9hje5gxo}
| /1 {0=10eaf93uzvsru}
And for 2.1.0 CR2:
2.1.0 CR2:
| null {}
| /9 {0=13gmz9ol9twc}
| /_BUDDY_BACKUP_ {}
| /192.168.1.135_51892 {}
| /3 {1=kf0p8vtuad5y}
| /5 {4=uvykukzoi2h0}
| /7 {1=zaouao7ntsy7}
| /2 {0=ib5tifo2tqco}
| /0 {4=1d1boyx12sha7}
| /4 {2=gyxlbtnjgpc}
| /8 {3=1ivb35jlxspf2}
| /6 {0=pte5ws2mpe11}
| /1 {1=1erqp88pgexrv}
| /192.168.1.135_51891 {} // --- wtf?
As I stated before in my first slightly confusing post, it is not the fact that
we get an additional (recursive) buddy node in the cache that is the
dealbreaker for us. But I strongly believe that this is one of, if not the,
cause for the lock timeouts we see. Remember that for 2.0.0 GA buddy rep works
like a charm for us, but with 2.1.0 CR2 it is broken. Given that and the fact
that the caches are in different states after a gravitation has occurred using
the simple test code provided, indicates to me that something has changed
and/or a regression has occurred.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4117127#4117127
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4117127
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Buddyrep issue
I have now tried to reproduce the issue in a standalone unit test and have
succeeded to at least some extent =)
I am now running two caches locally where one is producing data and the other
one is inspecting the cache - causing data to gravitate to the second cache.
The issue is replicated in the sense that the produces does get a buddy backup
node for itself, but I can't seem to get that node to contain any data.
The standalone test is much simpler and single threaded compared to the real
life application so thats a plausible reason why we do not see the exact same
behaviour (i.e. data inside the redundant buddy backup node).
In short:
The producer (master) is started:
Master created: 192.168.1.135:51469
The slave joins the cluster and is added as a buddy to the master:
MASTER:
| null {}
| /1 {1=c6m0p888dfvz}
| /_BUDDY_BACKUP_ {}
| /192.168.1.135_51470 {}
The slave fetches cache contents and data is gravitated to the slave, thus
moving to the slave buddy backup. But we also see the master having a buddy
backup for itself (with no data):
MASTER:
| null {}
| /_BUDDY_BACKUP_ {}
| /192.168.1.135_51469 {}
| /192.168.1.135_51470 {}
| /1 {1=c6m0p888dfvz}
The backup node for itself does not contain any data like in our real
application but I think it might be symptomatic for the issue.
You can find the full logfiles here:
http://www.cubeia.com/misc/cache/log
You can find the source code for the test here:http://www.cubeia.com/misc/cache
Warning, the code is a bit of a hack =)
To run it, start one instance with the argument 'master' and then another
instance with the argument 'slave' directly after. I've put some system
properties used in the javadoc of the main class.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4116710#4116710
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4116710
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Buddyrep issue
2.1.0 CR2 is correct. We are not using anything extra apart from turning on buddy replication and using data gravitation. I tried to recreate it today as well in a separate unit-test but with no success so far. I will give it another shot tomorrow since I think the underlying use case scenario is what might be triggering this. Ideally you would run the nodes on different machines to introduce some latency between the gravitations, I'll try to do that tomorrow. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4116554#4116554 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4116554 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Buddyrep issue
(Cont.) Further, we see that all locks that fail because a timeout is from .6, which do have .5 as its buddy backup. So, my question is if buddy replication has changed between 2.0.0 and 2.1.0? In any case the behavior is changed since this worked with 2.0.0 and not anymore. Why does the .5 member show up twice and as a buddy backup of itself? It does not make sense to me anyway Anyway, I hope I have been able to state the setup we are using, it tends to be a bit complex to define when using multiple nodes and buddy rep =) View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4115925#4115925 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4115925 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Buddyrep issue
Hi.
I am currently using cache 2.1.0 GA and jgroups 2.6.1 with buddy replication.
Buddy rep is configured to use one buddy only.
The setup is four nodes with ip addresses like:
172.16.0.5
| 172.16.0.6
| 172.16.0.7
| 172.16.0.8
|
| They are all started in the stated order so that .5 is the coordinator. The
first node up (.5) will insert data to the cache and then data will gravitate
to the other nodes when needed. This will occur mostly initially when applying
load to the system. Data affinity is handled by a layer above the cache.
|
| Using this scenario with 2.0.0 GA presented no problems except adding new
nodes during load, so we are now investigating 2.1.0.
|
| The issue I'm facing is that the coordinator seems to get two buddy
backups, one being itself.
|
| This is the contents on 172.16.0.5 (coordinator):
|
|
| | null {}
| | /91 [EMAIL PROTECTED] [EMAIL PROTECTED]
| | /63 [EMAIL PROTECTED] [EMAIL PROTECTED]
| | /92 [EMAIL PROTECTED] [EMAIL PROTECTED]
| |...
| |
| | /_BUDDY_BACKUP_ {}
| | /172.16.0.8_8786 {}
| | /15 [EMAIL PROTECTED] null}
| | /16 [EMAIL PROTECTED] null}
| | /172.16.0.5_8786 {}
| | /31 {}
|
| Notice that there are two members listed under_BUDDY_BACKUP, one is .8 and
the other one is .5, which is itself.
|
| Now, on 172.16.8 we get a lot of lock timeouts like the one below:
|
| Caused by: org.jboss.cache.lock.TimeoutException: read lock for
/_BUDDY_BACKUP_/172.16.0.5_8786 could not be acquired by
GlobalTransaction:172.16.0.6:8786:41 after 5000 ms. Locks: Read lock owners:
[]
| | Write lock owner: GlobalTransaction:172.16.0.6:8786:1
| | , lock info: write owner=GlobalTransaction:172.16.0.6:8786:1
(activeReaders=0,
activeWriter=Thread[Incoming,TableSpace,172.16.0.8:8786,5,Thread Pools],
waitingReaders=25, waitingWriters=0, waitingUpgrader=0)
| |
|
| 172.16.0.8 also shows two members under the buddy backup:
|
| null {}
| | /28 {}
| | /29 {}
| | /92 {}
| |...
| | /_BUDDY_BACKUP_ {}
| | /172.16.0.7_8786 {}
| | /91 [EMAIL PROTECTED] null}
| | /41 [EMAIL PROTECTED] null}
| | /115 [EMAIL PROTECTED] null}
| |...
| | /172.16.0.5_8786 {}
| | /31 {}
| |
|
| It seems like .8's buddy to backup is in fact .7. But we still hold some
buddy ref to the .5 member as well. In fact, all the lock timeouts on .8 is
related to to .5 buddy back fqn:
|
| failure acquiring lock: fqn=/_BUDDY_BACKUP_/172.16.0.5_8786
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4115924#4115924
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4115924
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Timeout when starting 2nd cache
Hi. We are currently testing a scenario of starting up an additional cache to a cluster where replication is running. We have been using 2.0.0 GA with Jgroups 2.5.0, but have encountered problems with this (mainly 'cache not in started state'). So we decided to try 2.1.0 CR2. It seems that by using 2.1.0 CR2 and jgroups 2.6.1 (not the bundled version), we get the most stable node up and down. However, sometimes when starting up a second cache we get the lock timeout described in the stacktraces below. | - Server 1 (Producer) - | | org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/_BUDDY_BACKUP_/192.168.1.135_50641//31, caller=Thread[Incoming,192.168.1.112:32903,10,Thread Pools], lock=read owners=[Thread[Incoming,192.168.1.112:32903,10,Thread Pools]] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0) | at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:528) | at org.jboss.cache.interceptors.PessimisticLockInterceptor$LockManager.acquire(PessimisticLockInterceptor.java:680) | at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:481) | at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:377) | at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:193) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:77) | at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:77) | at org.jboss.cache.interceptors.NotificationInterceptor.invoke(NotificationInterceptor.java:32) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:77) | at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:298) | at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:130) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:77) | at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:97) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:77) | at org.jboss.cache.interceptors.InvocationContextInterceptor.invoke(InvocationContextInterceptor.java:62) | at org.jboss.cache.CacheImpl.invokeMethod(CacheImpl.java:4004) | at org.jboss.cache.CacheImpl._replicate(CacheImpl.java:2861) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:597) | at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330) | at org.jboss.cache.marshall.InactiveRegionAwareRpcDispatcher.handle(InactiveRegionAwareRpcDispatcher.java:77) | at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:624) | at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:533) | at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:365) | at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:746) | at org.jgroups.JChannel.up(JChannel.java:1151) | at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:362) | at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:427) | at org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER.up(STREAMING_STATE_TRANSFER.java:242) | at org.jgroups.protocols.FRAG2.up(FRAG2.java:205) | at org.jgroups.protocols.pbcast.GMS.up(GMS.java:767) | at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) | at org.jgroups.protocols.UNICAST.handleDataReceived(UNICAST.java:579) | at org.jgroups.protocols.UNICAST.up(UNICAST.java:250) | at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:714) | at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:167) | at org.jgroups.protocols.FD.up(FD.java:322) | at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:300) | at org.jgroups.protocols.MERGE2.up(MERGE2.java:145) | at org.jgroups.protocols.Discovery.up(Discovery.java:246) | at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1535) | at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1484) | at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) | at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) | at java.lang.Thread.run(Thread.java:619) | Caused by: org.jboss.cache.lock.TimeoutException: write lock for /_BUDDY_BACKUP_/192.168.1.135_50641//31 could not be
[jboss-user] [JBossCache] - Replication exception when node lost
Hi. We are currently running a setup with jboss cache 2.1.0 CR2 and JGroups 2.6.1. When disconnecting one node from a cluster of two nodes, the first node will often catch exception below. Replication exception : org.jboss.cache.ReplicationException: rsp=sender=192.168.1.112:32904, retval=null, received=false, suspected=true | org.jboss.cache.ReplicationException: rsp=sender=192.168.1.112:32904, retval=null, received=false, suspected=true | View changed: [192.168.1.135:50649|4] [192.168.1.135:50649] | at org.jboss.cache.CacheImpl.callRemoteMethods(CacheImpl.java:2060) | at org.jboss.cache.CacheImpl.callRemoteMethods(CacheImpl.java:1952) | at org.jboss.cache.CacheImpl.callRemoteMethods(CacheImpl.java:1945) | at org.jboss.cache.CacheImpl.callRemoteMethods(CacheImpl.java:2091) | at org.jboss.cache.RPCManagerImpl.callRemoteMethods(RPCManagerImpl.java:70) | at org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:106) | at org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:69) | at org.jboss.cache.interceptors.ReplicationInterceptor.handleReplicatedMethod(ReplicationInterceptor.java:118) | at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:90) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:77) | at org.jboss.cache.interceptors.NotificationInterceptor.invoke(NotificationInterceptor.java:32) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:77) | at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:298) | at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:130) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:77) | at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:107) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:77) | at org.jboss.cache.interceptors.InvocationContextInterceptor.invoke(InvocationContextInterceptor.java:62) | at org.jboss.cache.CacheImpl.invokeMethod(CacheImpl.java:4004) | at org.jboss.cache.CacheImpl.put(CacheImpl.java:1483) | at org.jboss.cache.CacheImpl.put(CacheImpl.java:1468) | at org.jboss.cache.UnversionedNode.addChild(UnversionedNode.java:353) | at CacheTest$Producer.run(CacheTest.java:129) | at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417) | at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269) | at java.util.concurrent.FutureTask.run(FutureTask.java:123) | at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) | at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) | at java.lang.Thread.run(Thread.java:595) | Caused by: org.jboss.cache.SuspectException: Suspected member: 192.168.1.112:32904 | at org.jboss.cache.CacheImpl.callRemoteMethods(CacheImpl.java:2054) | ... 28 more | It looks like the cache is throwing an exception since the recipient is no longer with us (well, suspected at least). 1. Is this new behavior in 2.1? I can't remember having to catch these exceptions before when a member left the cluster. 2. What happens if the groups is 10 nodes and one member leaves? Will the replication be discarded, replicated to all but the suspected member or is it inconclusive? I tried to find some documentation regarding this but could not find any. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4114715#4114715 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4114715 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Serialization
Hi. We have been hunting hot spots in our application which relies heavily on the jboss cache. One hot spot that occurred was in the actual serialization of the objects. We got rid of the hot spot by using jboss serialization instead of the regular java serialization. In short we changed the ObjectOutputStreams in the JavaObjectStreamFactory class to use JBossObjectOutputStreams instead (and input of course). Now, we cannot be 100% sure that we gained cpu by doing this. It is possible that the hot spot just got spread out over multiple methods so the hot spot disappeared but we lost cycles over all. But the hot spot was removed from the list nevertheless. So my question is, is there a reason why jboss cache is not using jboss serializing for serializing objects? Since jboss serializing takes pride in being x times faster then vanilla java serializing, wouldn't this be a desirable element to include in the cache? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4103744#4103744 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4103744 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Improved performance
We have been load testing our system lately and we have been noticing many threads waiting to lock the readOwnerList in the LockMap class. The readOwnerList_ is a CopyOnWriteArraySet and (as the sourcecode comment above clearly states) is not the most effecient implementation to use here. So I decided to try and replace the CopyOnWriteArraySet with a ConcurrentHashMap implementation instead and I got a very significant performance boost. Not only was CPU significantly lower on the machines running the cache, but concurrency was also much, much better. I was actually surprised to see how much performance was gained. Therefore, I would certainly recommend that you swap out the CopyOnWriteArraySet to something more efficient. The actual coding took me about 1 minute to do, so it should certainly be a simple way to improve the cache throughput. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4099664#4099664 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4099664 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Scalability
We are currently running 4 nodes with synchronous replication of rather large data objects. (The replication is done within a transaction.) The objects replicated are from 1k up to about 8k bytes large. These 4 nodes currently handle up to 5000 events/second which would translate into 1250 replications per second and node. (Note: I would really like to try PojoCache here for a more fine grained replication. ) We are constantly trying new jgroups stacks and so forth, but currently it seems like we get better performance with TCP. Buddy replication also helped alot (1 buddy per node). We also run a cache shared by 8 nodes which is updated more then 5k/s, but that cache carries only small data and is updated asynchronously and is batched. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4098811#4098811 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4098811 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Data gravitation synchronization issue
I have been investigating the issue further and it seems like we actually access the node right after creating it. This causes concurrent access from both the server that currently owns the data and the server that is assigned to the node and this is what is triggering the lock-situation described above. I understand that accessing a node this way is not desired (permitted?) when running buddy replication and I will change the usage pattern to avoid this. However, I don't see why the locks should hang and cause a timeout (if configured). Arguably the scenario should work functionally, but will of course be suboptimal. I would argue this mostly since the lock-issue could be symptomatic of a more generic lock problem at hand. Anyway, it seems like we got buddy rep up and running now, which is great! View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4098452#4098452 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4098452 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Data gravitation synchronization issue
I have also seen this behaviour in our application. Buddy replication does not seem to work under concurrent load and/or usage. Just from starting up (no load applied) I get this in the logs: | 2007-10-23 14:25:52,664 Incoming Thread,TableSpace,172.16.0.5:7500 ERROR jboss.cache.interceptors.TxInterceptor - method invocation failed | org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/5, caller=GlobalTransaction:172.16.0.7:7500:1, lock=write owner=GlobalTransaction:172.16.0.6:7500:2 (activeReaders=0, activeWriter=Thread[Incoming Thread,TableSpace, | 172.16.0.5:7500,5,Incoming], waitingReaders=0, waitingWriters=0, waitingUpgrader=0) | at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:528) | at org.jboss.cache.interceptors.PessimisticLockInterceptor$LockManager.acquire(PessimisticLockInterceptor.java:579) | at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:393) | at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:329) | at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:187) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) | at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) | at org.jboss.cache.interceptors.NotificationInterceptor.invoke(NotificationInterceptor.java:32) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) | at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:298) | at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:131) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) | at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:123) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) | at org.jboss.cache.interceptors.InvocationContextInterceptor.invoke(InvocationContextInterceptor.java:62) | at org.jboss.cache.CacheImpl.invokeMethod(CacheImpl.java:3939) | at org.jboss.cache.CacheImpl._dataGravitationCleanup(CacheImpl.java:3055) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330) | at org.jboss.cache.interceptors.CallInterceptor.invoke(CallInterceptor.java:49) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) | at org.jboss.cache.interceptors.DataGravitatorInterceptor.invoke(DataGravitatorInterceptor.java:167) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) | at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:37) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) | at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:203) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) | at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) | at org.jboss.cache.interceptors.NotificationInterceptor.invoke(NotificationInterceptor.java:32) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) | at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:511) | at org.jboss.cache.interceptors.TxInterceptor.handlePessimisticPrepare(TxInterceptor.java:394) | at org.jboss.cache.interceptors.TxInterceptor.handleRemotePrepare(TxInterceptor.java:254) | at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:100) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) | at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:123) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) | at org.jboss.cache.interceptors.InvocationContextInterceptor.invoke(InvocationContextInterceptor.java:62) | at org.jboss.cache.CacheImpl.invokeMethod(CacheImpl.java:3939) | at org.jboss.cache.CacheImpl._replicate(CacheImpl.java:2853) | at
[jboss-user] [JBossCache] - Re: Data gravitation synchronization issue
Using 2.1 beta does not solve the problem. I still get timeout exceptions from unsuccesful lock acquisition when enabling buddy replication. JBoss Cache version: JBossCache 'Alegrias' 2.1.0.BETA1[ $Id: Version.java 4592 2007-10-10 16:44:36Z [EMAIL PROTECTED] $] | | JGroups version: 2.6.0 beta-1 | | Incoming Thread,TableSpace,172.16.0.5:7500 ERROR jboss.cache.interceptors.TxInterceptor - method invocation failed | org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/5, caller=GlobalTransaction:172.16.0.7:7500:1, lock=write owner=GlobalTransaction:172.16.0.6:7500:2 (activeReaders=0, activeWriter=Thread[Incoming Thread,TableSpace, | 172.16.0.5:7500,5,Incoming], waitingReaders=0, waitingWriters=0, waitingUpgrader=0) | at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:528) | at org.jboss.cache.interceptors.PessimisticLockInterceptor$LockManager.acquire(PessimisticLockInterceptor.java:598) | at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:412) | at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:348) | at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:185) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) | at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) | at org.jboss.cache.interceptors.NotificationInterceptor.invoke(NotificationInterceptor.java:32) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) | at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:299) | at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:131) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) | at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:123) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) | at org.jboss.cache.interceptors.InvocationContextInterceptor.invoke(InvocationContextInterceptor.java:62) | at org.jboss.cache.CacheImpl.invokeMethod(CacheImpl.java:3954) | at org.jboss.cache.CacheImpl._dataGravitationCleanup(CacheImpl.java:3026) | | Caused by: org.jboss.cache.lock.TimeoutException: write lock for /5 could not be acquired after 5000 ms. Locks: Read lock owners: [] | Write lock owner: GlobalTransaction:172.16.0.6:7500:2 | (caller=GlobalTransaction:172.16.0.7:7500:1, lock info: write owner=GlobalTransaction:172.16.0.6:7500:2 (activeReaders=0, activeWriter=Thread[Incoming Thread,TableSpace,172.16.0.5:7500,5,Incoming], waitingReaders=0, waitingWriters=0 | , waitingUpgrader=0)) | at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:244) | at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:167) | at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:497) | View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4097891#4097891 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4097891 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: 2.0GA and Maven2
Works ok now. Cheers View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4078269#4078269 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4078269 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: 2.0GA and Maven2
The jboss cache jar at: http://repository.jboss.com/maven2/jboss/jboss-cache/2.0.0.GA/ Looks like it has not been built correctly (4k?). The JBC dependency from maven does not work anyway. I'm getting the feeling that you guys are not using maven... ;) View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4077193#4077193 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4077193 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Buddy Replication
JBoss Cache: 2.0.0 GA JGroups: 2.5.0 GA Your description sounds exactly like what is happening here. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4076626#4076626 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4076626 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Buddy Replication
We get the following stack trace when starting up the cache with buddy replication enabled and can't really understand why. | 2007-08-21 21:27:49,849 Incoming Thread,TableSpace,172.16.0.5:8786 INFO space.jboss.ExtendedCache.TableSpace - viewAccepted(): [172.16.0.5:8786|1] [172.16.0.5:8786, 172.16.0.6:8786] | | 2007-08-21 21:27:49,849 AsyncViewChangeHandlerThread,172.16.0.5:8786 DEBUG jboss.cache.buddyreplication.BuddyManager - Instance 172.16.0.5:8786 broadcasting membership in buddy pool BuddyPool to recipients null | | 2007-08-21 21:27:49,851 AsyncViewChangeHandlerThread,172.16.0.5:8786 ERROR jboss.cache.buddyreplication.BuddyManager - Problems broadcasting buddy pool membership info to cluster | java.lang.RuntimeException: failed executing request [req_id=1187724469850 | caller=172.16.0.5:8786 | 172.16.0.6:8786: sender=172.16.0.6:8786, retval=null, received=false, suspected=false | | request_msg: [dst: null, src: null (1 headers), size=41 bytes] | rsp_mode: GET_ALL | done: true | timeout: 2000 | expected_mbrs: 0 ([172.16.0.6:8786])] | at org.jgroups.blocks.MessageDispatcher.castMessage(MessageDispatcher.java:433) | at org.jgroups.blocks.RpcDispatcher.callRemoteMethods(RpcDispatcher.java:199) | at org.jgroups.blocks.RpcDispatcher.callRemoteMethods(RpcDispatcher.java:167) | at org.jboss.cache.CacheImpl.callRemoteMethods(CacheImpl.java:2093) | at org.jboss.cache.CacheImpl.callRemoteMethods(CacheImpl.java:2023) | at org.jboss.cache.RPCManagerImpl.callRemoteMethods(RPCManagerImpl.java:55) | at org.jboss.cache.buddyreplication.BuddyManager.makeRemoteCall(BuddyManager.java:929) | at org.jboss.cache.buddyreplication.BuddyManager.broadcastBuddyPoolMembership(BuddyManager.java:904) | at org.jboss.cache.buddyreplication.BuddyManager.broadcastBuddyPoolMembership(BuddyManager.java:888) | at org.jboss.cache.buddyreplication.BuddyManager.access$800(BuddyManager.java:56) | at org.jboss.cache.buddyreplication.BuddyManager$AsyncViewChangeHandlerThread.broadcastPoolMembership(BuddyManager.java:1080) | at org.jboss.cache.buddyreplication.BuddyManager$AsyncViewChangeHandlerThread.handleEnqueuedViewChange(BuddyManager.java:1054) | at org.jboss.cache.buddyreplication.BuddyManager$AsyncViewChangeHandlerThread.run(BuddyManager.java:1020) | at java.lang.Thread.run(Thread.java:595) | Caused by: java.lang.IllegalArgumentException: 172.16.0.6:8786 is not a member of the group [172.16.0.5:8786] (enabled_members=[]) | at org.jgroups.protocols.UNICAST.down(UNICAST.java:301) | at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:317) | at org.jgroups.protocols.pbcast.GMS.down(GMS.java:782) | at org.jgroups.protocols.FRAG.down(FRAG.java:138) | at org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:221) | at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:339) | at org.jgroups.JChannel.downcall(JChannel.java:1240) | at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:752) | at org.jgroups.blocks.RequestCorrelator.sendRequest(RequestCorrelator.java:297) | at org.jgroups.blocks.GroupRequest.doExecute(GroupRequest.java:440) | at org.jgroups.blocks.GroupRequest.execute(GroupRequest.java:190) | at org.jgroups.blocks.MessageDispatcher.castMessage(MessageDispatcher.java:430) | ... 13 more | It seems that the view is changed and accepted, viewAccepted(): [172.16.0.5:8786|1] [172.16.0.5:8786, 172.16.0.6:8786] But then the buddy manager fails to send a message since unicast does not acknowledge the member. Any help would be appreciated! View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4076468#4076468 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4076468 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - 2.0GA and Maven2
Hi, I was about to update to 2.0 GA and I noticed that in the maven pom file the dependency to jgroups still uses the 2.5.0-BETA2 version of jgroups. Is there any reason for this or has it just been forgotten? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4073868#4073868 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4073868 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: JBoss Cache 2.0.0 in GA
Great stuff! Keep up the good work =) View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4073295#4073295 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4073295 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Reading threads are blocked
True. I dismissed optimistic locking earlier for reasons I can't remember right now. I might take another plunge into using optimistic locking for at one of our cache applications. I solved the blocked readers in one instance by putting a local cache in front of jboss cache. Not the prettiest solution but at least my reading threads are happy... =) View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4066398#4066398 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4066398 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - CR3 Listener
I just upgraded to CR3 and found out that the CacheListener interface has been removed in favor for the annotationbased listener. Some gripes: 1. Wouldn't this be considered a major api change(?) and as such should not go in between two cr releases? 2. I understand that the benefit is that you can choose to declare only those listener methods you are interested of, thus reducing the amount of empty boilerplate listener methods. However, the downpart is that we are losing type safety here and I personally do not consider this a good bargain. From the documentation we can read: anonymous wrote : Methods annotated as such need to be public, have a void return type, and accept a single parameter of type org.jboss.cache.notifications.event.Event or one of it's subtypes. Now, isn't this exactly why we have interfaces? An interface enforces signature and types. If we fail to honor the interface we get a nice compilation error, with the annotation based model we will get runtime checking and runtime errors. If we look at the list of available annotations here http://labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/2.0.0.CR3/JBossCache-UserGuide/en/html_single/index.html#api.listener we can see that the input ot the methods differ. Now I have to switch between my IDE and the documentation to lookup the annotation and what the proper signature is. Should I fail to comply, my IDE will not tell me since there is no compile-time checking. Furthermore, since there is no longer a CacheListener interface, I cannot use that interface for listener-registration in layers created on top of the cache, forcing me either into allowing Object or creating my own Listener interface which will allow me at least some typesafety. But in the end I will never really know until the cache is started and every possible listener has been registered to the cache, right? Generally I'm not opposed annotations. I think they do fill a purpose, but I can't seem understand the reasons for this particular design decision. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4064522#4064522 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4064522 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Reading threads are blocked
Will do. I'll post the results here when done. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4063366#4063366 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4063366 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Reading threads are blocked
Using the testbeds from above on CR3 shows a significant improvement over CR2. The source for the tests can be found here: http://www.robotsociety.com/cache/cr3/src.rar NB: These tests are micro-benchmarks, i.e. not a real-life scenario. Parallel tests Reading threads access all available nodes concurrently. Reading throughput was improved by 27%. All threads are still mostly blocked. I'm not sure how much concurrency we can claim here. Threads: http://www.robotsociety.com/cache/cr3/parallell_threads.GIF Dedicated tests Four threads all read from a dedicated node. There is one node per thread so they should never try to read from the same node. Reading throughput was improved by 40%. Thread concurrency is clearly improved which can be seen in the profiler as well. Threads comparison: http://www.robotsociety.com/cache/cr3/comparison.GIF It seems that in the parallel scenario, most threads are blocked by the initLock in UnversionedNode. The lock is lazily initiated in case we don't need locking, but on the other hand you then force a synchronized upon every threads that wants to get the lock reference. The synchronization is only to check if the lock has been initialized and when it has it really serves no purpose, so arguably this could be solved without having to synchronize on every getLock() call. However, using non-lazy initialization and removing the sync block did not result in any significantly higher concurrency since the next mutex is in the tryLock on the lock that we pass back. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4063426#4063426 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4063426 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Reading threads are blocked
That would probably qualify as a double locked check which is unfortunately not thread safe (see http://www.ibm.com/developerworks/library/j-dcl.html). View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4063575#4063575 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4063575 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: 2.0 and JMX
I omitted the getMbeanServer() since it is environment dependent. A oneliner
approach to getting the default server is like this:
private MBeanServer getMBeanServer() {
| return ManagementFactory.getPlatformMBeanServer();
| }
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4060913#4060913
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4060913
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: jbosscache MBeans not appearing in jconsole
If you are using the regular cache you can follow this thread: http://www.jboss.com/index.html?module=bbop=viewtopict=106118 If you are using pojocache you can use a similar pattern: MBeanServer mbs = getMBeanServer(); | mbs.registerMBean(new PojoCacheJmxWrapper(cache), pojoCacheName); View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4060316#4060316 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4060316 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: jbosscache MBeans not appearing in jconsole
What version are you using? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4060114#4060114 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4060114 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - PojoCache regional classloader
I can't seem to find any mention of context classloaders in the pojocache documentation. Will regional context classloaders work in the same way for pojo as for the regular cache? I.e., can I get a region of the pojocache's underlying cache and register a context classloader? There will be different regions with different classloaders. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4059667#4059667 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4059667 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Reading threads are blocked
Of course. You can get the source code here: http://www.robotsociety.com/cache/src.zip There are two tests, one is concurrent readers on all nodes the other one is concurrent readers on fixed nodes. Both tests are for profiling so they don't assert any functionality. In fact there is no reason for using junit here, guess it was just old habits kicking in... View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4055308#4055308 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4055308 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Reading threads are blocked
We are currently testing the 2.0 CR2 in a load intensive environment. I started
to notice a lot of blocked threads that were blocked by the cache.
In order to investigate further I constructed a simple load test on a cache.
The cache uses the standard replAsync-service.xml
This is what I do:
1. Create a cache
| 2. Initialize the cache with some nodes and data
| 3. Start a large number of concurrent readers
| 4. Observe the threads and monitors in the system using jprofiler
|
|
| Contents of the created and initialized cache:
|
| | DEBUG CacheLockGetTest - null {}
| | /d {}
| | /g {1=Data}
| | /h {1=Data}
| | /f {1=Data}
| | /e {1=Data}
| | /b {}
| | /g {1=Data}
| | /h {1=Data}
| | /f {1=Data}
| | /e {1=Data}
| | /a {}
| | /g {1=Data}
| | /h {1=Data}
| | /f {1=Data}
| | /e {1=Data}
| | /c {}
| | /g {1=Data}
| | /h {1=Data}
| | /f {1=Data}
| | /e {1=Data}
| |
|
| The task used to read from the cache:
|
|
| | private class CacheExecutor implements Runnable {
| | private final Fqn fqn;
| | public CacheExecutor(Fqn fqn) { this.fqn = fqn; }
| |
| | public void run() {
| | cache.get(fqn, 1);
| | }
| | }
| |
|
|
| The cache has been initialized before I start the readers, so that when the
readers are running no write occurs on the cache. Now, I thought that read
operations on the cache would be concurrent but when inspecting the threads in
jprofiler I got this:
|
| http://www.robotsociety.com/cache/threads.GIF
|
| If we look at the contending threads' stack traces we see that they all
block against UnversionedNode (See:
http://www.robotsociety.com/cache/monitors.GIF)
|
| I have looked at unversioned node and there is much synchronization going
on in there. I am not sure why the blocking is so frequent and I also saw
threads working in different regions blocking each other.
|
| One question is, if I access a/b/c, will a read lock be acquired for all
those nodes, if so then we will ultimately have synchronization on the common
root node for all read operations in the cache, correct?
|
| I understand that the test above is a bit artificial since we do not run
any other type of logic that would permit pauses for access, but I also run
into this blocking issues in our server where we do execute other functionality.
|
| Now, our cache is pretty large so I will try and divide the regions into
separate caches to minimize the synchronization issues or try to find some
other workaround, but shouldn't a cache solution permit more concurrent access
rather then having what looks like a global sync lock?
|
| On a side note, after running a while the UnversionedNode sync lock is
replaced by the readOwnerList_ in LockMap (see:
http://www.robotsociety.com/cache/monitors_copyarray.GIF).
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4053977#4053977
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4053977
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Exclusive lock on bottom (leaf) node only?
Great stuff! View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4053461#4053461 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4053461 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Exclusive lock on bottom (leaf) node only?
What is the status of this? Should Option.setForceWriteLock() write-lock all nodes all the way up from the designated node or not? If this is in fact correct behaviour, is there any recommended way of solving the leaf-only locking scenario described in this thread? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4053086#4053086 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4053086 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Maven and CR2
My first feedback on CR2: I can't get CR2 from maven. =) This works: dependency groupId=jboss artifactId=jboss-cache version=2.0.0.BETA1/ | This does not work: dependency groupId=jboss artifactId=jboss-cache version=2.0.0.CR2/ Error: Unable to resolve artifact: Missing: | -- | 1) jgroups:jgroups-all:jar:2.5.0-BETA2 I can always patch the libs manually, but... View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4050859#4050859 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4050859 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Maven and CR2
Downloading and installing the jgroups 2.5.0 beta 2 manually in jgroups-all locally led to this problem: | Unable to resolve artifact: Unable to get dependency information: Unable to read the metadata file for artifact 'jgroups:jgroups-all:jar': Cannot find parent: jgroups:jboss-parent for project: null:jgroups:jar:2.5.0-BETA2 This looks wrong to me: jgroups:jboss-parent Shouldn't it be jboss:jboss-parent ? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4050873#4050873 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4050873 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Maven and CR2
The parent works now, i.e. jgroups:jboss-parent - jboss:jboss-parent Still, it seems that the jgroups dependency is pointing to 'jgroups-all' where in the maven repo only 'jgroups' exists. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4050908#4050908 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4050908 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Maven and CR2
I am no maven expert or anything, but I think you want to change this dependency: dependency | groupIdjgroups/groupId | artifactIdjgroups-all/artifactId | version2.5.0-BETA2/version | exclusions | exclusion | artifactIdbsh/artifactId | groupIdbsh/groupId | /exclusion | /exclusions | /dependency To: dependency | groupIdjgroups/groupId | artifactIdjgroups/artifactId | version2.5.0-BETA2/version | exclusions | exclusion | artifactIdbsh/artifactId | groupIdbsh/groupId | /exclusion | /exclusions | /dependency I.e., change artifactId from 'jgroups-all' to just 'jgroups'. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4050913#4050913 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4050913 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Maven and CR2
You're right, the old '-all' was cached on my side. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4050962#4050962 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4050962 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Exclusive lock on bottom (leaf) node only?
Using repeatable read as transaction isolation will not stop concurrent read access to the node if i'm not mistaken. My interpretation is that atijms want to get an exclusive lock on '/a/b/n1' regardless of read or write operation. If this is correct then repeatable_read would not solve the issue. I have actually the same requirement, I need to access a node and lock that node (and that node only) excusively. I do not want to write-lock the parent nodes. If I use Option.setForceWriteLock() , then all nodes are write locked. So far, I have found two working solutions, none which are pretty imho. 1. Perform a write operation such as remove(...) first when accessing the node. That acquires a write lock during the transaction right away. Not very performance wise I would gather though =) 2. Make your own locking scheme. I implemented this, it doesn't feel right (feels like a true hack), but it works for me. First I get the lock from the node, add the lock to my transaction. Then I acquireAll on the node for read locks and finally acquire write lock on the leaf node only. I'd be real happy if there was an option we could provide (similar to Options.setForceWriteLock()) that let us readlock the branch and write lock the leaf node only... View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4050321#4050321 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4050321 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Object is not replicated after field update
As a note I finally got it working by adding the arguments: -javaagent:lib/jboss-aop-jdk50.jar -Djboss.aop.path=src/conf/META-INF/pojocache-aop.xml and copying the pojocache-aop.xml from the distribution /resources. I must say, I do find the documentation for this rather... confusing. It is not as concise at it could be anyway. I have one question though, in the documentation it states that you can either precompile classes or runtime by using a special system classloader. But in section 7 it says: anonymous wrote : | 7.3.1. Ant target for running load-time instrumentation using specialized class loader | | In JDK5.0, you can use the javaagent option that does not require a separate Classloader. Here are the ant snippet from one-test-pojo, for example. So... if I use this, do I still subsitute the system classloader or not? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4048832#4048832 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4048832 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Object is not replicated after field update
Did you find out what the problem was? I'm fiddling around with pojocache myself and got the same error when running the examples from the distribution. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4048797#4048797 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4048797 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Regional classloaders and state transfer
We are currently using the 2.0 beta 2 release, and have some problem with the state transfer. We are using regional based classloaders with an example cache like: /a/ - ClassLoader A /b/ - ClassLoader B The startup sequence of the cache looks like: 1. Create cache 2. Register classloaders 3. Start the cache Now, we startup Cache #1 and everything is working well. We add some ClassLoader A specific objects under /a/... and can read and write them correctly. Placing ClassLoader B specific objects under /b/... also works fine. Then we start Cache #2 using the same start sequence as above, but then we run into problems. Cache #1 has objects in it's cache so a state transfer is initialized. The regions have been initialized in Cache #2 with proper classloaders so that should be fine. However, the state transfer from Cache #1 is triggered on the root '/'. When Cache #2 gets the initial state transfer it goes a little like this: 1. Do I have regional based classloaders? yes. 2. Do I have a classloader defined for region '/'? no. 3. Use default classloader. 4. ClassNotFoundException The class not found is of course due to the fact that objects under /a/... will require ClassLoader A. The steps are of course my interpretation from stepping the code in a debugger, I might be wrong. Any feedback regarding this would be much appreciated, I am not really sure yet on how to solve the problem if the state transfer is for the whole cache with the root node as reference. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4041653#4041653 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4041653 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: config loading issue with 2.0.0.BETA2
If it helps, I extended DefaultCacheFactory and added my own little factory
method that accepts an input stream.
The method looks like:
public Cache createCache(InputStream is, boolean start) throws
ConfigurationException {
| XmlConfigurationParser parser = new XmlConfigurationParser();
| Configuration c = parser.parseStream(is);
| return createCache(c, start);
| }
|
Of course, it should be possible to _not_ extend the factory and create a cache
in a similar manner.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4035949#4035949
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4035949
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - 2.0 and JMX
I'm using 2.0 in a standalone application. When using 1.4 I got the JBoss Cache registered to JMX by default (I think). Now when we are testing out 2.0, it doesn't seem to get registered to JMX anymore. However, registering the cache manually works perfectly fine: | CacheImpl cache = createCache(); | MBeanServer mbs = getMBeanServer(); | mbs.registerMBean(cache.getCacheMBeanInterface(), monitorName); | Is this the new preferred way of registering a cache to JMX or are you planning a more automated way? Using the method above also means we have to reference CacheImpl (and not just Cache). Also, while I'm at it, I realize that the MBean interface is work-in-progress since it is still missing out on a lot of information if you compare it to 1.4. However, I would vote for adding the getMembers() so we can easily inspect the members of a distributed cache via JConsole (or any other JMX tool). View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4035964#4035964 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4035964 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - CacheAPI
I'm using the 2.0 Habanero cache and I want to access my cache as a CacheSPI. The reason being that I want to access nodes as NodeSPI so I can inspect (and possible upgrade) the node lock. Now, I started to check the Javadoc on how to get the CacheSPI instead of the regular Cache interface, but couldn't relly find anything. So I checked the test implementations for the 2.0, and found that you do this: cache = (CacheSPI) DefaultCacheFactory.getInstance().createCache(...); However, in the Javadoc we find: You should NEVER attempt to directly cast a Cache instance to this interface. ok, so I'm guessing that you want guys like me not to look at the unit tests and cast the Cache to a CacheSPI (because it may not work in the future) =) But, do you have any recommend way of getting a CacheSPI? Is there any other way then to make a cast at the moment? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4032738#4032738 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4032738 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: CacheAPI
Cheers! I'll look into the PessimisticLockInterceptor View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4032778#4032778 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4032778 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - WAN distributed caches
I was wondering if there is any support built in or a preferred way of setting up a replication gateway for having a treecache running in two geographically separated locations. The setup is that I want to run a treecache at site A and a treecache at site B. I want them to share the same data, but there is no need for all nodes at site A to be aware of the nodes at site B and the other way around. Site A and B are geographically separated. Synchronizing is fairly relaxed, so using a lazy periodical async setup would be perfectly ok. A picture says more then words (from gigaspaces): http://www.gigaspaces.com/docs/manual/Data_Grid_Proofed_files/image047.jpg View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3979900#3979900 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3979900 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Buddy Replication
Well, at least I don't have find it out the hard way now... I'll guess I will start looking into other ways of propagating the state information needed through other channels, be it a second cache or something else. Cheers View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3979274#3979274 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3979274 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Buddy Replication
I am currently developing a system using the regular treecache. In the cache we store stateful objects. The nodes in the system all have a designated set of objects that the manipulate. In essence, the cache is mostly for fail-over reasons. Therefore I find that using buddy replication together with data gravitation proves to be a very good match (we are using 1.4). However, I would like to add a new type of node to the system, this node has a monitor-like role and needs to get periodical snapshots of all objects (and their state) in the cache. The monitor node will only perform read operations towards the cache. Now, my question is if anyone has any suggestion of the best way to set this up... Is it possible to 'mix' cache configurations so that the monitor node will not use buddy replication but rather get the complete cache or would this be a completely backward solution? Any input is welcome! / Fredrik Johansson View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3979019#3979019 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3979019 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
