[JBoss-dev] [Design of JBoss IIOP on JBoss] - CORBA servant MBean?
There have been several posts recently asking how one might plug a CORBA servant into JBoss as a method to wrap EJB calls behind customized IDL or to just utilize extant servants as is. Given this interest, it seems like writing an MBean that could load/manage any CORBA servant class would be a good idea, and I would like to contribute such a bean. Here are some quick thoughts about functionality: * This MBean would depend on at least the CorbaORB MBean. * The servant after being activated, could be registered with the CORBA naming service provided by JBoss via the CORBANaming MBean (and a third party one as well). * Since MBeans have a definate lifecycle, it might be a good idea for this MBean to really represent a named POA, since the MBean lifecycle could be mapped to a POA lifecycle. This would also allow for the configuration of the POA's policies and the inclusion of a POAManager if need be. Is this a worthwhile effort? Is this something that could be a part of JBoss, or would this be better served as a thirdparty MBean (the contributed MBeans wiki)? Is there any other functionality that might be useful to have? View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3874048#3874048 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3874048 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Isolation Level of NONE Works In JBC 1.2.1?
As mentioned in a previous post, I am using the cache in an asychronously replicated manner, and with the default isolation level of REPEATABLE_READ I get lock errors when there is moderate to heavy use of the cache. As suggested, I set the isolation level to NONE, and I received the following error from lots of the threads accessing the cache (even with mild to moderate use of the cache). | java.lang.IllegalStateException: addWriter(): owner already existed | at org.jboss.cache.lock.LockMap.addWriter(LockMap.java:112) | at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:175) | at org.jboss.cache.Node.acquireWriteLock(Node.java:483) | at org.jboss.cache.Node.acquire(Node.java:440) | at org.jboss.cache.interceptors.LockInterceptor.lock(LockInterceptor.java:240) | at org.jboss.cache.interceptors.LockInterceptor.invoke(LockInterceptor.java:156) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40) | at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:35) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40) | at org.jboss.cache.interceptors.ReplicationInterceptor.replicate(ReplicationInterceptor.java:217) | at org.jboss.cache.TreeCache._replicate(TreeCache.java:2682) | 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:324) | at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:236) | at org.jgroups.blocks.RpcDispatcher.handle(RpcDispatcher.java:220) | at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:615) | at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:512) | at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:326) | at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722) | at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:554) | at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691) | at java.lang.Thread.run(Thread.java:534) | Is this an issue or expected? Would a test case that presents this behavior help (it seems easy to produce in our application anyway)? I set the isolation level to READ_UNCOMMITTED while running the same tests that produced the above issue, and it seems promising, but I am not done testing with it yet. Is this a valid workaround for this issue? View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3871843#3871843 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3871843 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: Lock Acquisition Timeouts In JBC 1.2.1
I thought it might be something like that, but should I get the IllegalStateException that I got (shown above) when I did that? View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3871684#3871684 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3871684 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Lock Acquisition Timeouts In JBC 1.2.1
I have been using JBC 1.2 for some time, and our application has a case where multiple threads (many of them) might access the same node in the cache at the same time and/or update a node's children. We are not using transactions. This has worked fine even under high volume. With the introduction of JBC 1.2.1, I now get lock acquisition timeout errors in medium to high volume situations, and I would like to understand how to turn them off. The Javadocs for TreeCache indicate that setting the lock acquisition timeout to zero turns them off, but this only makes the errors I have occur with *much* greater frequency. It appears that a zero setting really means wait zero milliseconds to timeout. I can set this value to an arbitrarily high number, but disabling this would be much better. As I understand it, the reason we want a lock acquisition timeout is to avoid deadlock situations (such as a distributed deadlock), but since I am not using transactions nor a synchronously replicating cache, this should not occur I would not think. Is it not possible to turn these off? I am going try setting the isolation level to NONE from REPEATABLE_READ (the default) to see if it makes any difference. In JBC 1.2, isolation levels did not come into play unless transactions were utilized (that is what I understood to be the case anyway). Has this changed? Posts on this forum and the documentation with the 1.2.1 release seem to suggest that maybe it has. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3871627#3871627 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3871627 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: Lock Acquisition Timeouts In JBC 1.2.1
By setting the isolation level to NONE, I got a different error. Its stacktrace is below. | java.lang.IllegalStateException: addWriter(): owner already existed | at org.jboss.cache.lock.LockMap.addWriter(LockMap.java:112) | at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:175) | at org.jboss.cache.Node.acquireWriteLock(Node.java:483) | at org.jboss.cache.Node.acquire(Node.java:440) | at org.jboss.cache.interceptors.LockInterceptor.lock(LockInterceptor.java:240) | at org.jboss.cache.interceptors.LockInterceptor.invoke(LockInterceptor.java:156) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40) | at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:35) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40) | at org.jboss.cache.interceptors.ReplicationInterceptor.replicate(ReplicationInterceptor.java:217) | at org.jboss.cache.TreeCache._replicate(TreeCache.java:2682) | 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:324) | at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:236) | at org.jgroups.blocks.RpcDispatcher.handle(RpcDispatcher.java:220) | at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:615) | at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:512) | at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:326) | at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722) | at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:554) | at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691) | at java.lang.Thread.run(Thread.java:534) | I am not sure what this means beyond the fact the isolation level change did apparently influence how the cache was behaving regardless of the fact that I am not using transactions. Is the answer to handle the lock acquisition timeout exceptions mentioned in the previous post, somehow turn them off (how?), or is there another alternative? View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3871648#3871648 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3871648 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: Lock Acquisition Timeouts In JBC 1.2.1
One more piece of new information, there is obviously some deadlock going on here. I increased the lock acquisition timeout time to 5 minutes and noticed the following: * the process stopped (did nothing) waiting for 5 minutes after about 500 simultaneous client requests * after this timeout period, more timeout exceptions occurred than when the timeout was set to 15 or 30 seconds I am not sure what to do now as this same code (both client and server) works *fine* when used with JBC 1.2. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3871649#3871649 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3871649 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: Lock Acquisition Timeouts In JBC 1.2.1
Additionally, I have noticed/tried the following: * the lock acquisition timeouts seem only to occur while listing a given node's children and the retrieving information from each of the children * if the isolation level is set to READ_COMMITTED, the lock acquisition timeouts completely go away (I have no idea why) Should a change in isolation level create/alleviate a dead lock situation like this? View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3871663#3871663 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3871663 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: TreeCache's ClusterConfig attribute
I did not realize this was possible, so I tried configuring JBossCache to use the same JGroups configuration so I could share the channel as the previous post mentioned, but once deployed, the two components do not appear to interact nicely with each other (it would have been really cool if they did). I took the JBossCache 1.2 configuration specified in the file replAsync-service.xml and set its cluster name, mcast address, and mcast port to be the same as the JBoss 3.2.7 cluster configuration. Then I deployed it (the file). First, each channel appears to see the other as a peer in the cluster. I guess it makes since that this is happening (two JChannel instances are being created), but it means that on a single node, I will have two cluster members. That seems odd. It would be neat, I think, if the cache could piggyback the application server cluster rather than exist as a cluster member (or is this a bad idea?). Second, upon recognizing the existence of the peer, JBossCache attempts to query the peer for its cache state. This is where everything appears to go wrong. The complete message/stack trace is as follows: 03:06:46,890 INFO [TreeCache] viewAccepted(): new members: [a:1357 (additional data: 18 bytes), b:1369] | 03:06:46,900 INFO [DefaultPartition] New cluster view for partition DefaultPartition (id: 1, delta: 1) : [192.168.1.100:1099, 192.168.1.100:1369] | 03:06:46,900 INFO [DefaultPartition] I am (192.168.1.100:1099) received membershipChanged event: | 03:06:46,900 INFO [DefaultPartition] Dead members: 0 ([]) | 03:06:46,900 INFO [DefaultPartition] New Members : 1 ([192.168.1.100:1369]) | 03:06:46,911 INFO [DefaultPartition] All Members : 2 ([192.168.1.100:1099, 192.168.1.100:1369]) | 03:06:49,895 ERROR [FD_SOCK] received null cache; retrying | 03:06:51,888 INFO [TreeCache] state could not be retrieved (must be first member in group) | 03:06:53,400 ERROR [FD_SOCK] received null cache; retrying | 03:06:56,895 ERROR [FD_SOCK] received null cache; retrying | 03:06:57,636 INFO [TreeCache] received the state (size=1463 bytes) | 03:06:57,736 ERROR [TreeCache] failed unserializing state | java.lang.ClassCastException | at org.jboss.cache.TreeCache$MessageListenerAdaptor._setState(TreeCache.java:2828) | at org.jboss.cache.TreeCache$MessageListenerAdaptor.setState(TreeCache.java:2797) | at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.passUp(MessageDispatcher.java:614) | at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:331) | at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722) | at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:554) | at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691) | at java.lang.Thread.run(Thread.java:534) After this, the following message kept repeating (which is the application server querying the now dead cache I think): 03:07:03,705 ERROR [FD_SOCK] socket address for a:1357 (additional data: 18 bytes) could not be fetched, retrying If JBossCache messaging can share the JBossCluster channel, is this the right way to go about it? View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3868089#3868089 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3868089 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: Use of getChildrenNames
norbert wrote : This must happen within the same transaction as getChildrennames(). If not using transactional locking there's still a chance that the Constructor of TreeSet will throw ConncurrentModificationException too. (It makes use of the Iterator of the 'result'). Yeah, I noticed the same thing (after trying it). I am not using a transaction b/c this happens so infrequently, I am just retrying if I get the exception. It would be nice if you could do this without transactions (and not get the exception). View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3856892#3856892 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3856892 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: Guidance on JBoss Distributed Cache Application
Read the JBossCache tutorial. It has a lot of useful information. http://docs.jboss.org/jbcache/Tutorial.html View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3856932#3856932 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3856932 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: JBossCache Bug in get(someNode, key)?
[EMAIL PROTECTED] wrote : Jimmy, if you could provide the unit test, that would be great, because I want to release JBossCache 1.2 by mid-December. | I have created a unit test that causes the described behavior. Because it involves a little more than a single JUnit TestCase class, I do not think it would be wise to post it on the forum. I will send it along to you and Ben via an e-mail. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3856992#3856992 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3856992 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: JBossCache Bug in get(someNode, key)?
[EMAIL PROTECTED] wrote : You *cannot* use async repl and expect that the backup cache(s) have already been updated when you update the primary cache. Use sync_repl. BTW: there is a unit test case (forgot which one) that tests this. Check it out. I agree with the above; I do not expect an update from one cache VM to be immediately propogated to the VMs in the cache cluster (and I have been testing with SYNC replication anyway though I prefer ASYNCH replication). The problem I am seeing is after the replication occurs. A key/value pair exists in a node's map, then it does not, then it does. All of this happens inside the *same* VM. Isn't the initial presence of the key/value pair, in the node's map proof that replication has already occurred? The VM in which this behavior occurs does not place this value into the map, but after it is replicated, it disappers only to reappear again later (as the log showed). The disappearance/reappearance of the key/value pair is my concern, not when it is replicated. Note, the key/value pair that goes missing (there are actually two that exhibit this behavior), is not being modified or removed by any VM in the cache cluster once it has been added. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3856724#3856724 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3856724 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: JBossCache Bug in get(someNode, key)?
I should mentioned that in my last test run, I saw this same behavior for a single VM. The VM initially put the key/value pair into the node's map, it existed, it disappeared, and then it reappeared. The VM was in a cache cluster, but replication was not the cause of the initial key/value insertion. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3856735#3856735 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3856735 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: JBossCache Bug in get(someNode, key)?
[EMAIL PROTECTED] wrote : do you see this when you use cache mode of LOCAL? That is, no replication at all? That is a good question. I have not tried this with a replication mode of LOCAL. That is something that I need to investigate. I am working on coming up with a test case to demonstrate the problem. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3856802#3856802 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3856802 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: Use of getChildrenNames
norbert wrote : Although the methods of 'Node' are declared as public, this class is (currently) not intendet to be used directly by TreeCache-clients. I am confused. The getChildrenNames method I referred to is on the TreeCache class, not the Node class. Does it still fall into the described not intended category? View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3856639#3856639 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3856639 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: JBossCache Bug in get(someNode, key)?
bwang00 wrote : Like Norbert mentioned, use tx now. There is a known problem in locking when tx is not used. We are fixing that in release 1.2. Do I need locking when I am getting a value that is already in a node's map? I do not care if other items are added to the map while I am getting this value do I? Is the issue you refer to the reason I am getting null? bwang00 wrote : If you are using TreeCacheAop, I'd suggest you try the latest pre-1.2 release in jboss-head. I have done some refactoring and bug fixing on the aop part. So far, when I am using the TreeCacheAop methods, I have not had any issues. This problem only occurs when using TreeCache's put/get methods. That said, would this refactoring be of any help? bwang00 wrote : If you still are seeing the problem, the best way to help me out to troubleshoot is to write a JUnit test case. That can cut down the time that I need to generate one by myself. Besides, I can check in your test case in the src tree as well. I can try to create one, but this only seems to happen under high load (and with multiple nodes), and then, it does not happen everytime. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3856640#3856640 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3856640 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Use of getChildrenNames
I have some code that uses getChildrenNames, and this works well except when other threads via the same VM (or a remote one upon replication) change the children a node has by removing or adding children. The issue is that to use a set, you need to use an iterator. When the underlying set is modified, the iterator properly throws a ConcurrentModificationException. To avoid this, I attempted to use the toArray method on the returned set, but this suffers from the same problem. In other code where I have used iterators, I have used the clone method to avoid this problem, but since the Set interface is returned by this method, I can not use that. I tried to see the type actually returned through getClass().getName(), but it is an UnmodifiableSet returned from the Collections class, and it does not implement Cloneable either. Can anyone suggest a course of action to take? I do not care if what I get back remains up to date as changes are made to the cache node, I only care that it is up-to-date when I invoke getChildrenNames. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3856590#3856590 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3856590 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: JBossCache Bug in get(someNode, key)?
My application was running a a Linux box, but all of the application's JAR files were available via NFS. By moving the application's JAR files to local disk, the described problem seems to have disappeared. Unfortunately, I was unable to try the aforemented tests (turning on synchronous replication) before this change was made, so I do not know what that might have produced. If the problem reappears, I will try this to see what it produces. My theory is that the classloader was failing to load class information across the NFS-mounted file system and causing the issue. Has anyone else experienced this type of strange behavior in their Java applications when utilizing NFS? View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3856589#3856589 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3856589 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: JBossCache Bug in get(someNode, key)?
jiwils wrote : My application was running a a Linux box, but all of the application's JAR files were available via NFS. By moving the application's JAR files to local disk, the described problem seems to have disappeared. Correction...the problem is back (with everything on the local disk). I will be attempting to see what happens if I turn on synchronous replication. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3856593#3856593 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3856593 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: JBossCache Bug in get(someNode, key)?
jiwils wrote : Correction...the problem is back (with everything on the local disk). I will be attempting to see what happens if I turn on synchronous replication. I am still getting a null result when calling get(blah, key) just like before even when using synchronous replication. There were no CacheExceptions or a derivative reported during the get that returned null nor during the put in the remote VM where the key/value pair was placed into the cache. In the same VM as the get that returned null, other threads received a value for the same key before and after the invocation that returned null. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3856597#3856597 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3856597 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: JBossCache Bug in get(someNode, key)? [More Info]
jiwils wrote : I am still getting a null result when...
For further clarification, here is the snippet of code that this is occurring
in and the log that it produces (proof that this is really happening).
The code snippet:
| String nodeID = null;
| String fqn = null;
|
| try
| {
| nodeID = new String(id);
| fqn = (String) _cache.get(/blah, nodeID);
|
| if (log.isDebugEnabled())
| {
| StringBuffer message = new StringBuffer(Retrieved);
| message.append(SPACE);
| message.append(fqn);
| message.append(SPACE);
| message.append(for);
| message.append(SPACE);
| message.append(nodeID);
| message.append(SPACE);
| message.append(from blah.);
|
| log.debug(message.toString());
| }
| }
| catch (CacheException ce)
| {
| log.error(Unable to use blah:, ce);
| }
|
The log snippet:
| 00:13:40,887 DEBUG [Test] Retrieved /blah/some_test for
bwLbCSdPI80ONJeMWEmEgA== from blah.
| 00:13:40,889 DEBUG [Test] Retrieved /blah/some_test/test for
MyTOeDTaGhly7bp4/Smy6g== from blah.
| ...snip...
| 00:13:40,889 DEBUG [Test] Retrieved null for MyTOeDTaGhly7bp4/Smy6g== from
blah.
| ...snip...
| 00:13:40,900 DEBUG [Test] Retrieved /blah/some_test for
bwLbCSdPI80ONJeMWEmEgA== from blah.
| 00:13:40,901 DEBUG [Test] Retrieved /blah/some_test/test for
MyTOeDTaGhly7bp4/Smy6g== from blah.
|
Again nothing is being removed from the blah node's map during this test, and
no CacheException is logged (even though synchronous replication has been
enabled).
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3856599#3856599
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3856599
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: JBossCache Bug in get(someNode, key)?
norbert wrote : Try this with synchronous replication to see whether there are any 'CacheException' when 'put' ist called right before retriving 'null'. | | (Asynchronous Replication will catch these Exceptions internally since they do not occur synchronous to the corresponding method-call). | An interesting idea (and I will try it to see what happens), but in my case, the put in question is happening in another VM. Furthermore, I know that the replication is working because before (and after) the null occurrance, get invocations for the same key are working. Could there be a hidden exception in the get invocation that your suggestion might expose? Since I am not using transactions, I am not sure what that would be. I am only using SERIALIZABLE as an isolation level because it seemed to fix an unrelated issue where a cache node existed, but its corresponding object did not (yet). View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3856460#3856460 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3856460 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - JBossCache Bug in get(someNode, key)?
I have two JVMs that are invoking put(blah, key, value) and get(blah, key) where blah is the same node in a TreeCacheAop instance. The keys and the values are String instances. A key, in this case, is a hashed version of its corresponding value which is just an FQN to another location in the cache. When many threads (200 or more) are creating nodes and adding key/value pairs for those nodes into the cache, I occassionaly get null back from the cache on a get invocation. This occurs in between get invocations for the same key in which a value was returned. At no time are key/value pairs being removed from the blah node, and at no time are other nodes being removed from the cache. Can anyone help me postulate why this might be occurring? I am using JBossCache 1.1.1 with an isolation level of SERIALIZEABLE (it happened with REPEATABLE_READ too) and with asynch replication. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3856217#3856217 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3856217 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: Transactions/Locking Across VMs Issues
bela wrote : #1 exists() doesn't acquire a lock, use get(). We tried the top-level if with both and exist and get to see if it made any difference before I posted, because we thought this might be the case. Thanks for (correctly) pointing back to the Javadoc. bela wrote : #2: you try to update the same data on 3 nodes concurrently. Because you use REPL_SYNC...This is a typical distributed deadlock. Thanks for the distributed deadlock explanation. I knew that there was something I was missing. For us, the locking is not so important (so we will probably not use transactions). What are the solutions for this type of problem? Random sleep times before retrying if a timeout occurs? What about a master node that hands out locks/blocks when called? It seems like there would be a pretty standard set of possibilities when this type of situation is encountered. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3855017#3855017 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3855017 --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: Transactions/Locking Across VMs Issues
By refactoring the above code to retry a configurable number of times and by
randomizing the time to wait between retries, I was able to get the behavior I
expected. Essentially, this code takes a concurrent event, and makes it not
concurrent (avoiding the distributed deadlock situation altogether).
The refactored code:
| public void test()
| throws Exception
| {
| _cache.startService();
|
| try
| {
|
| // Try to insert into the cache a maximum of 2 times.
| int retryCount = 2;
|
| for (int i = 0; i retryCount; i++)
| {
| try
| {
| putInCache(key, _value);
| }
| catch (AlreadyBound ab)
| {
| throw ab;
| }
| catch (Exception e)
| {
| System.out.println();
| System.out.println(= Try # + i +
=);
| e.printStackTrace(System.out);
|
System.out.println(==);
| System.out.println();
|
| // Wait at least 100 milliseconds.
| Thread.sleep(_random.nextInt(4900) + 100);
|
| continue;
| }
|
| break;
| }
| }
| catch (Throwable t)
| {
| t.printStackTrace(System.out);
| System.out.println();
| }
| finally
| {
| System.out.println();
| System.out.println(Done.);
| System.out.println();
| }
| }
|
| private void putInCache(String key, String value)
| throws Exception
| {
| UserTransaction tx =
| new DummyUserTransaction(DummyTransactionManager.getInstance());
|
| tx.begin();
|
| Object previous = _cache.put(aom, key, _value);
|
| if (previous != null)
| {
| tx.rollback();
|
| throw new AlreadyBound();
| }
| else
| {
| tx.commit();
| }
| }
|
Anyone else have other ideas on how to handle distributed deadlock situations?
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3855027#3855027
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3855027
---
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Transactions/Locking Across VMs Issues
I have been attempting to get transactional access to a node when inserting
key/value pairs into a node's map. However, no matter what I do this does not
work for me.
I have three VMs running on a multiprocessor box that each contain an instance
of a cache. All three VMs are reading the same cache configuration file. VMs
1 and 2 are running client code that is putting a key/value pair in a HashMap.
The key is the same, so by using transactions I would like for one of the
clients to successfully put the key/value pair, and I would like the other VM
to recognize that the value has already been put. VMs 1 and 2 are started as
close as possible to the same time in order to ensure that transaction locking
is occurring.
The code for VMs 1 and 2 is as follows:
| _cache.startService();
|
| // Sleep to ensure that cache start is finished (does no good).
| System.out.println(Sleeping...);
| Thread.sleep(1);
| System.out.println(Done sleeping.);
|
| UserTransaction tx =
| new DummyUserTransaction(DummyTransactionManager.getInstance());
|
| try
| {
| tx.begin();
|
| if (! _cache.exists(aom, key))
| {
| System.out.println(Inside if...);
|
| Object last = _cache.put(aom, key, _value);
| tx.commit();
|
| if (last != null)
| {
| System.out.println(Last was not null...);
| System.out.println(last);
|
| // tx.rollback();
| }
| else
| {
| System.out.println(Last was null...);
| }
| }
| else
| {
| System.out.println(already exists);
| }
| }
| catch (Throwable t)
| {
| t.printStackTrace(System.out);
| }
|
The 3rd VM is just a listener, but it does not implement the
TreeCacheListener interface. It just prints out the key/value pairs of the
node that the other VMs are working with so I can determine which VM won in the
race I am creating. It prints out these values once every 30 seconds.
I start the listener VM first, and put an arbitrary key/value pair into the
node that every VM is using in order to make sure the node already exists.
Then I start the other two VMs as close to simultaneously as possible.
All three VMs get timeout exceptions, and neither VM 1 nor VM 2 place anything
in the map (one of them does sometimes but it is auto-rolled back because of
the timeout exception). VM 3 appears to hang sometimes when it locks the cache
to update VM 1 / VM 2 because only a single locking message appears for state
transition rather than one for each of the other VMs, but this does not happen
every time.
This is the listener VM's timeout stacktrace log:
| 00:07:27,584 ERROR [TreeCacheAop] method invocation failed
| org.jboss.cache.lock.TimeoutException: lock could not be acquired after
15000 ms. Lock map ownership Read lock owners: []
| Write lock owner: devns02:34215:3
|
| at
org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:146)
| at org.jboss.cache.Node.acquireWriteLock(Node.java:422)
| at org.jboss.cache.Node.acquire(Node.java:388)
| at org.jboss.cache.TreeCache.findNode(TreeCache.java:3295)
| at org.jboss.cache.TreeCache._put(TreeCache.java:2341)
| at org.jboss.cache.aop.TreeCacheAop._put(TreeCacheAop.java:611)
| 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:324)
| at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:223)
| at org.jboss.cache.TreeCache.prepare(TreeCache.java:2736)
| 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:324)
| at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:223)
| at
org.jboss.cache.interceptors.CallInterceptor.invoke(CallInterceptor.java:14)
| at
org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:39)
| at
org.jboss.cache.interceptors.ReplicationInterceptor.replicate(ReplicationInterceptor.java:144)
| at org.jboss.cache.TreeCache._replicate(TreeCache.java:2674)
| at
[JBoss-dev] [JBossCache] - Remote TreeCacheListener Not Notified On remove(fqn, key) Ca
Due to the issues I had with the TreeCacheView class, I wrote a command line
implementation of TreeCacheListener. In doing so, I happened upon a quirk. It
turns out that TreeCacheListener instances are not notified when the
remove(fqn, key) method is invoked on remote instances. I have not tested with
a listener that is local to the cache, but in looking at the code, I think that
the result might be the same.
Using the JBossCache 1.1 tagged version of TreeCache I tracked the actual
removal (on a remote instance from the remove invocation) to line 2517. In the
latest revision, the line is 2576. The method containing these lines of code
never issues a nodeModified event to the listeners, however it is a bit more
complicated because the method does issue nodeRemoved events. They are
suppressed for the context of this call due to a boolean parameter on the
method itself.
Should invocations of remove(fqn, key) cause nodeModification events? It seems
like they should, but the presence of the other (suppressed) events confuses
me. I supposed this method is used for both the removal of nodes and of values
from a node's map. Am I reading this correctly?
For reference, the JBossCache 1.1 tagged version of TreeCache's _remove method
is below. Line 2517 is the line containing old_value=n.remove(key).
| public Object _remove(GlobalTransaction tx, Fqn fqn, Object key,
| boolean create_undo_ops, boolean sendNodeEvent)
| throws LockingException, TimeoutException {
| Node n=null;
| MethodCall undo_op=null;
| Object old_value=null;
|
| if(log.isDebugEnabled())
| log.debug(_remove( + tx + , \ + fqn + \, + key + ));
|
| try {
| // Find the node. This will lock it (if ttlocking/tt is true)
and
| // add the temporarily created parent nodes to the TX's node list
if tx != null)
| n=findNode(fqn, true, locking, tx, NODE_WRITE);
| if(n == null) {
| log.error(_remove(): node + fqn + not found);
| return null;
| }
| old_value=n.remove(key);
|
| // create a compensating method call (reverting the effect of
| // this modification) and put it into the TX's undo list.
| if(tx != null create_undo_ops old_value != null) {
| undo_op=new MethodCall(put_key_val_method,
| new Object[]{tx, fqn, key, old_value,
| new Boolean(false)});
| // 1. put undo-op in TX' undo-operations list (needed to
rollback TX)
| tx_table.addUndoOperation(tx, undo_op);
| }
|
| if(sendNodeEvent)
| notifyNodeRemoved(fqn);
| return old_value;
| }
| finally { // we always unlock when no TX is present
(lock-update-unlock)
| if(tx == null locking == true)
| releaseLocks(tx, fqn);
| }
|}
|
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3854386#3854386
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3854386
---
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: Questions about functionality
anonymous wrote : If this functionality does not already exist, are there hooks where I could write my own implementations (and of course submit the changes back). I am sure that Ben and Bela can answer your questions more directly than I can, but I had some of the same requirements just from a testing point of view. Though JBossCache comes with a graphical viewer of the cache encapsulated by the TreeCacheView class, it did not always work correctly for me, so I implemented the TreeCacheListener interface to print out when cache access (there are a variety of different methods) occurred to verify that my code was working as expected. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3854097#3854097 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3854097 --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Has TreeCacheView Been Updated?
Has anyone else noticed that the TreeCacheView class/application does not always correctly reflect cache access/changes? I figured that part of the problem might be related to how the GUI and cache are connected, so to prove that was the case, I implemented the TreeCacheListener interface to print cache access/changes to the console, and ran that inside another VM. That testing indicated that the cache was correctly getting all of the changes I thought it should. In the future, I would be happy to look at the TreeCacheView class/application to try to figure out what is wrong, but I was curious if some of these issues have already been fixed. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3854098#3854098 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3854098 --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: Has TreeCacheView Been Updated?
I may look into making some changes to the TreeCacheView application/class, and if I improve it, I will e-mail those changes to you. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3854114#3854114 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3854114 --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: Use JBossCache without clustering configuration
Could you not set the CacheMode MBean attribute in the configuration file from REPL_ASYNC to LOCAL as illustrated below? attribute name=CacheModeLOCAL/attribute In my short bit of testing, this explicitly logged that the JGroups channel would not be opened (regardless of the presence of JGroups protocol stack configuration information in the file). View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3853958#3853958 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3853958 --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: Node Locking
So, my code looks something like this:
| if (cach.containsKey(key))
| {
| throw something;
| }
|
| acquire lock/begin transaction
| if (cach.containsKey(key))
| {
| release lock/rollback transaction
| throw something;
| }
|
| cache.put(blah, key, value);
| release lock/commit transaction
|
Given these semantics, would I need to use a SERIALIZABLE isolation level, or could I
get by with REPEATABLE_READ?
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3853653#3853653
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3853653
---
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: Node Locking
bela wrote : Yes, use a TxManager. If you don't run inside the container, use DummyTransactionManager. Check the XML file(s) for an example. Great! Thanks for the advice. I have looked at the code/XML examples where the DummyTransactionManager was used, but I assumed it was just a dummy/mock obect for testing because of its name. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3853442#3853442 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3853442 --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Node Locking
I have a situation where I might attempt to add some information to the cache with the put(FQN, String, String) method across multiple VMs. How can I ensure that this information is written to the cache only once such that I can check for presence of the stuff to add in the cache and then add it only if necessary and not have it added by another VM between the check and the add code? I've noticed that nodes appear to have locks, but I can not figure out how to explicitly set them. Do I have to use a transaction manager to do this? What if I am running standalone? Is there a transaction manager I can use? Any ideas on how I might accomplish this? View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3853350#3853350 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3853350 --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: TreeCacheView/TreeCacheViewAop MBean Purpose
I had already used the described workaround...works like a charm! ;) I'll make the bug report. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3852227#3852227 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3852227 --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - TreeCacheView/TreeCacheViewAop MBean Purpose
Some (if not all) of the JBossCache configuration files contain the following MBean definition: !-- Uncomment to get a graphical view of the TreeCache MBean above -- |!-- mbean code=org.jboss.cache.TreeCacheView name=jboss.cache:service=TreeCacheView-- |!-- dependsjboss.cache:service=TreeCache/depends-- |!-- attribute name=CacheServicejboss.cache:service=TreeCache/attribute-- |!-- /mbean-- I thought I would get a GUI with which I could inspect the cache, but instead I got a multiple MBean exception. I am running JBossCache in standalone mode, is this the issue? Are multiple MBeans per JBossCache instance supported only when running inside JBoss 4? View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3851966#3851966 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3851966 --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: TreeCacheView/TreeCacheViewAop MBean Purpose
Oops... I meant I get the multiple MBean exception when I uncomment the XML configuration section denoted in the previous post. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3851967#3851967 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3851967 --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Caches on JBoss (Caches/JBoss)] - Which Version Of JGroups?
Which version of JGroups does JBossCache 1.1 include? View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3849013#3849013 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3849013 --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
