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
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
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 :
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
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
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
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 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
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
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 :
[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
[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
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
[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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 :
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
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);
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
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
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
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--
|!--
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 :
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
38 matches
Mail list logo
