We had a similiar problem some months ago. It turned out to be that we were
using an old parser that didn't support schemaSource.
We're using weblogic, and our config was explicitly setting the parser to use,
the solution for us was to stop the config doing so, and use the parser that
comes in
We're wondering what the best practise to establish if a node has children is.
"Node" doesn't appear to have anything to directly to this (a hasChildren()
method for example), and the closest thing we've found is getChildrenNames(),
which is relatively slow.
"NodeSPI" has a "hasChildrenDirect()
Have you tried turning on the following log4j logging to see what's happening
with the transactions?
org.jboss.cache.interceptors.TxInterceptor=TRACE
(in our properties file that turns into
log4j.logger.org.jboss.cache.interceptors.TxInterceptor=TRACE, JBossAppender)
3.0.2 did have a bug that u
It's now quite happy with a 3.0 config file, thanks
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213009#4213009
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213009
___
jbo
I'm not sure if this is intentional or not. I tried out the 3.0.3CR1 release,
and was able to use that as a drop in replacement for 3.0.2GA.
However when upgrading to 3.0.3GA I now have to change my config file to
http://www.w3.org/2001/XMLSchema-instance";
xmlns="urn:jboss:jbosscache-core:con
It is quite big isn't it?
The largest amount of nodes any transaction should have been able to hit would
be around 22000, when we're bouncing the cache, although that would remove the
node that was parent to them all, and then re-added them, so I guess that's
22000 removals and 22000 adds.
Vi
This one is less obscure, we had an OutOfMemoryError during rollback.
<19-Feb-2009 15:50:06 o'clock GMT>
<[ACTIVE] ExecuteThread: '19' for queue: 'weblogic.kernel.Default
(self-tuning)'> <> <> <> <1235058606291> <182721306
[[ACTIVE] ExecuteThread: '19' for queue: 'weblogic.kernel.Defau
We've just had an orphaned lock again, so we may have an additional problem.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211528#4211528
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211528
__
I thought you might be interested in feedback.
In my local testing I was unable to reproduce the problem of orphaned locks,
and after two days being in our product and tested here we've not had any
problems.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211
Excellent news! I'm downloading to test now.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210277#4210277
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210277
___
jboss-user
Forgot to mention, the interesting part is the locking of the node
/Parameters/ISchmParam/4686570 in GlobalTransaction::42 and
GlobalTransaction::43
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209645#4209645
Reply to the post :
http://www.jboss.org/inde
It does look like the latest 3.1.0 SNAPSHOT fixes our problem.
In the meantime, would this problem also apply in other locking schemes besides
MVCC locking? I'm not seeing it when using either Pessimistic or Optimistic
locking, but I'm wondering now if that's just luck with the timings.
View th
I've turned trace logging on for
org.jboss.cache.interceptors.PessimisticLockInterceptor
but all it gave me was the following.
I'm trying to get more comprehensive logs for you, but it's proving difficult
to get the app up with a lot of trace logging turned on.
[ACTIVE] ExecuteThread: '0' for
They are indeed 3.0.2.GA logs.
I'm in the process of getting hold of what I need to do a trunk build. I don't
suppose there's a built jar available anywhere is there?
Is this going to be a problem with pessimistic and optimistic locking as well
then?
Any idea when 3.1.0 is due? And is there li
anonymous wrote : I've started looking through the log files you sent, and
while this doesn't solve your problem, why do you have your transaction timeout
set as low as this? Is this intentional? You would minimise your error rate by
increasing this so that not as many transactions time out.
Y
I can't reproduce the issue with either pessimistic or optimistic locking.
I've tried configuring the cache to use syncRollback and commit phases
(although given I'm not in a cluster I don't that that would have any effect
anyway), and it made no difference.
View the original post :
http://www
I'm not sure my understanding of pessimistic locking is correct, as I have a
situation which is working but I don't understand why.
My understanding is that:
1) Locks are held for the duration of a transaction
2) Writers must wait until there are no read locks on a node
I have a transaction T1,
Is this is a manifestation of previous JIRA 923 relating to Weblogic's
transaction manager, which would be the safest locking mechanism for us to use
until MVCC locking is fixed, pessimistic or optimistic?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209
I've attached logs to the JIRA I created, which have the thread name.
I've logged the following categories, which if your loggers names are all the
class name should include the MVCCLockingInteceptor you asked for. If there's
any other categories that would be helpful, just let me know.
log4j.l
I also realise my config file didn't come out very well in the forum posting,
here it is:
|
| http://www.w3.org/2001/XMLSchema-instance";
xmlns="urn:jboss:jbosscache-core:config:3.0">
|
|
|
|
|
|
|
|
|
|
View the original post :
ht
The full trace log for TxInteceptor and org.jboss.cache.lock, just for this
transaction is 50MB, however I've attached the last few lines here in case
they're helpful
[ERR] 2009-02-10 10:58:36,581 259269 DEBUG Associated gtx in txTable is
GlobalTransaction::28
org.jboss.cache.interceptors.TxIn
We have a problem with JBoss Cache 3.0.2 (also present on 3.0.0) using MVCC
locking, on Weblogic 10.3, running in a single instance, whereby a transaction
can rollback due to a timeout but not release the locks it's holding.
In normal use this happens fairly rarely, but often enough to be worryi
I haven't yet been able to reproduce the problem in a controlled manner,
although I'm trying.
All I can confirm at the moment is that we've seen a stale/unreleased lock,
reporting that it's held be a transaction that doesn't exist anymore, after
having a transaction rolledback by a timeout (I c
Is the issue raised in JBCACHE-923 likely to be an issue with Weblogic using
MVCC locking?
We're using Weblogic 10.3
We're currently seeing a situation, after a transaction timed out while making
a lot of modifications to our cache, where a particular node in the cache is
locked.
The behaviou
Does your node exist before you call putForExternalRead? The putForExternalRead
method will do nothing if the node already exists.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4192389#4192389
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=
In answer to my own question, in case anyone else has similiar difficulties, it
seems I was using node incorrectly.
The API documentation states:
A Node is a named logical grouping of data in the JBoss Cache. A node should be
used to contain data for a single data record, for example informatio
I've been trying to setup JBoss cache to use invalidation in a cluster.
I'm handling the re-reading of the entry from the database myself, however I'm
not sure how to put the entry in the cache.
The issue is when Cache instance A has sent out an invalidation message, and
Cache instance B is now
27 matches
Mail list logo
