ankit.thakkar wrote : Dear All,
|
| can anybody please suggest some approach on this, we are facing lots of
trouble in production due to this issue.
|
| Thanks All
If you're having issues at production and this is urgent stuff, you might wanna
get professional support? :)
In which cases do you wanna use PL instead of MVCC?
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4269287#4269287
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4269287
___
I'm not sure what you're using RMI for exactly these days since EJBs and JNDI
are accessed via JBoss Remoting these days, and have no idea what AS version
you're using but there's some documentation already available wrt accessing
this stuff via firewalls:
If you look at existing CacheLoader implementations such as JDBCCacheLoader,
you'll see that we call cf.commit(tx);.
cf.commit(tx) does not do anything in a managed environment, such as the JBoss
Application server since it's the JBoss JCA layer that will make sure that
anything that the
What do you mean in your comment by batching is enabled ? Is this something
that the exception indicated? Or something you added yourself?
In general, doing reentrant calls from the cache loader to the cache is not a
good idea, particularly using cache.get() methods since these go via the
That looks pretty hacky. You shouldn't be fiddling with the component registry.
Looks to me the following would be much simpler to do:
public class MyInterceptor extends CommandInterceptor {
|private final InterceptorParameter ip;
|public MyInterceptor(InterceptorParameter ip) {
|
So Sean, what was the issue? Maybe other readers can benefit from the same fix
you did...
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4268459#4268459
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4268459
Dustin, search before posting:
http://www.jboss.org/index.html?module=bbop=viewtopict=157686postdays=0postorder=ascstart=0
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4268464#4268464
Reply to the post :
As indicated in the documentation, JBoss Cache uses lock stripping by default
and you can control the shared pool of locks by tweaking the concurrency level,
as you already did. However, lock striping, under certain circumstances, can
lead to deadlocks as indicated in
See
http://anonsvn.jboss.org/repos/jbossas/branches/Branch_5_0/tomcat/src/resources/jbossweb-cluster-jboss-beans.xml
(included in AS 5.1) for example on how to get cache configurations working on
that AS version
View the original post :
Maybe you wanna try with JBoss Transactions which is a JTA TM as well? To try,
download or set correct dependencies to JBoss Transactions (see jbc trunk for
example) and use
Modifications are only rolledback when there're transactions and for such
notifications, there's @TransactionCompleted and its TransactionCompletedEvent
that contains:
/**
| * @return if tttrue/tt, the transaction completed by committing
successfully. If ttfalse/tt, the transaction
|
Or you could just simply catch any Throwable which would include other
Exceptions, RuntimeExceptions and Errors. Also, I'd do so at the top level, in
EvictionTimerTask.Task class.
How about you fill up a JIRA and attach a source patch with your suggestion? :)
View the original post :
Hi, apologies for the delay.
Re 1: The problem resides in your test. Whenever you call the following code,
you're traversing /user FQN and so it's the same as you were doing
cache.get(/user/1), cache.get(/user/2), cache.get(/user/3),
cache.get(/user/4)...etc. So, 4 and 5 are always used and
angusm, re: http://www.jboss.org/index.html?module=bbop=viewtopict=159042,
JBC is only supported as either read only or transactional cache, never
read-write.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4254455#4254455
Reply to the post :
It's fine that it's in the jar but it's not a problem related to that. Looking
at the trace provider, you seem to be clustering different AS versions. As
suggested earlier, try to create a cluster of AS 5.1 in the localhost and see
if they cluster fine.
View the original post :
JBossCache does not act as an XA resource but participates in transactions via
javax.transaction.Synchronization
See
http://www.jboss.org/file-access/default/members/jbosscache/freezone/docs/3.1.0.CR1/userguide_en/html_single/index.html#transactions.jta
View the original post :
It appears you're trying to cluster different AS versions since
CacheMarshaller200 appears to be in use.
AS 5.1 uses JBoss Cache 3.1 and hence should be using CacheMarshaller300
marshaller.
Try to create a cluster of AS 5.1 instances in your localhost and see if u see
the same issue.
View
I believe we use the transactional one. Here's the pom of the je dependency:
http://download.oracle.com/maven/com/sleepycat/je/3.3.75/je-3.3.75.pom
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4245905#4245905
Reply to the post :
andresp21, the 1st the eviction thread is executed, it's executed at
wakeUpInterval/2, the rest of the times at wakeUpInterval.
With regards to the wrong nodes being removed, could you show us the client
code you're executing and explain which of the nodes you're putting are you
seeing being
With regards to the performance issue, please send me several thread dumps
taken with 30s-1m difference each using the kill -3 or Ctrl+Break method
explained in http://www.jboss.org/community/wiki/StackTrace and enable garbage
collection logging
Read docu: The expiration time is indicated using the
org.jboss.cache.Node.put() method, using a String key expiration and the
absolute time as a java.lang.Long object, with a value indicated as
milliseconds past midnight January 1st, 1970 UTC (the same relative time as
provided by
niuxuetao_fiserv wrote : I just realized that since I am using Pojo cache, I
am not sure how Pojo cache creates the FQN when I pass a string id to the
PojoCache.attach(String id,Object obj).
|
| Suppose I pass id as X/Y what FQN will be really created?
|
| What will be the performance
Indeed but we're undeprecating them for JBoss Cache 3.2 since they're still
valid ways of accessing the cache via jmx.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4244600#4244600
Reply to the post :
Could you please create a bug report in
https://jira.jboss.org/jira/browse/JASSIST including the the code and full
stacktrace that you got you encountered?
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4244596#4244596
Reply to the post :
We agreed undeprecate the CacheJmxWrapper method for JBoss Cache 3.2 since it's
still a valid method and we're not planning to do further changes to the JMX
layer in JBoss Cache.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4244604#4244604
Reply to the post
Right, I suspect that your lock timeout issues might be related to your current
fqn structure. If you bear in mind that locks are acquired on a per FQN basis,
storing a lot keys within an FQN leads to lock contention. Instead, I'd suggest
you add more FQNs and reduce the number of keys stored
@amurugan, maybe you wanna enable TRACE logging and add thread information to
the logs to see what's going on underneath.
@mjdinsmore region names for entities are not simply constructed with the class
names, there's more information that you need to take in account such as the
persistence
niuxuetao_fiserv wrote : Btw, can I use the GenericTransactionManagerLookup
in Websphere6.1?
It should do.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4243564#4243564
Reply to the post :
How many A objects do you expect to have in the system? Are all A objects
stored under the same FQN?
Also, of those A objects, take for example instance A1. Are you calling
multiple attach/detach for the same A1 instance? Or for each A instance, i.e.
A1, there's only one attach and one detach?
Yeah, PojoCache 3.0.0.GA works with JBoss Cache 3.1.0.GA.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4243567#4243567
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4243567
___
You can such information via CacheJmxWrapperMBean. See
http://www.jboss.org/index.html?module=bbop=viewtopict=156458postdays=0postorder=ascstart=10
for more information on how you can get hold of that interface.
Are you running within an application server or standalone?
View the original post
Even if running standalone, you can get hold of that interface programmatically
following steps in
http://www.jboss.org/file-access/default/members/jbosscache/freezone/docs/3.1.0.GA/userguide_en/html_single/index.html#jmx.registration
Remember that from JDK5 onwards, you can get hold of an
If you want an Entity to be cached, I'd suggest you avoid @Replicable and
instead configure it with @Cache annotation (see Hibernate/JPA annotations) so
that the entity is added to the 2nd level cache. The 2nd level cache use case
has been more road tested than what you're trying to do.
See
The fact that all regions where not online at the same time wouldn't be a
problem. When a new store comes in, it could retrieve the state from a
persistent store or from another node in the cluster.
How many retail branches are we talking about here? What type of data would
these retail
niuxuetao_fiserv wrote : About the write-intensive stuff, yes, we will have a
lot more calls to attach() than modifying the already cached Pojos.
Attaching a pojo is an expensive operation where the pojo is dissected and
mapped to the cache, hence such operation should be used as less as
Hi again, I think I have replicated the issue that you're encountering with the
code from the UserGuide. I'm currently investigating it.
With regards to your 2nd questions, Cache has no getChild() method, I suppose
you're refering to getNode() instead? If so, this is indentical to calling
FYI: https://jira.jboss.org/jira/browse/JBCACHE-1518
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4240976#4240976
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4240976
___
Hi again, actually, I have to apologise because my previous comment was not
entirely correct. getChild() takes only the name of the direct child, so
root.getChild(content/timestamp) and
root.getChild(Fqn.fromString(content/timestamp)) should be return null as
well.
Only,
We haven't got such information published in a wiki or documentation but I
believe you should be able to figure out what the state is composed of by
looking at the code in the different
org.jboss.cache.remoting.jgroups.ChannelMessageListener.setState calls that
effectively delegate the state
getChild() takes the fqn of the child, it's a relative method. Root already
provides the first /, so the name of the child is without that first /:
content/timestamp
If u used Cache rather than Node, you'd do the following using the absolute
path:
cache.getNode(/content/timestamp);
View the
First of all, to generate thread dumps and see where threads holding write
locks might be stuck, see generating thread dumps wiki:
http://www.jboss.org/community/wiki/StackTrace
I must say that 100ms for lock timeout is pretty small. Something around 10-20
seconds is more usual. Rather than
Ah, I see what you're trying to do now. What JBoss Cache version are you using
exactly? I need that info to be able to help you further.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4239260#4239260
Reply to the post :
I don't you understood what I meant. I'm not asking whether other queries get
cached or not. You already mentioned that they do. What I'm asking is the
following:
Can you use a different cache provider, i.e. HashtableCacheProvider (i.e. see
Ah Ok. I'm glad that you're aware of this :). Your use case sounded very
similar to the 2nd level cache use case and the reason explained earlier is why
when using a standard 2nd level cache, caches need to be somehow clustered.
Hey, once you've got the solution complete, why don't you write a
No, the FQN is only the location of the data. The object passed around is a bit
more complex, varies depending on the situation, but generally contains an FQN
plus key+value pair(s) sent around.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4239048#4239048
H, I'm not sure what's the effect of querying view tables and spatial
fields and I dunno whether the question has really anything to do with JBoss
Cache itself. Have you tried to cache the query using standard hash table cache
provider and see if that works? If it does, then there might
drcallaway wrote : galder.zamarr...@jboss.com wrote :
| | What do you exactly mean with data changing? Is data changing as a
result of your interaction with the cache? Are you changing the data directly
in the cache store? I don't understand why you'd want the data to be replaced
How big are the Pojos that you're storing? Several kbs/megs...etc?
Did you try getting some thread dumps to see what the thread holding the lock
to the database is doing?
Can you try commenting preloading and trying again?
View the original post :
drcallaway wrote : .. Though mostly static, this data may occasionally
change. When this happens, is there a way to force the cache to refresh this
node with data from the cache loader? This process would be similar to removing
the node and then running preload again.
What do you exactly mean
It's in
http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/core/src/main/java/org/jboss/ejb3/cache/tree/
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4237840#4237840
Reply to the post :
tcp stack still uses MPING, multicast based member discovery, to find other
members in the cluster, so maybe the cluster did not form correctly, which
would explain why invalidation does not happen.
Check for view messages for the MVCCEntityCache cache instance in the logs. See
if the view
Those lock timeouts with 0ms timeout are not important. These timeouts come
when reading an entity from database into the 2nd level cache and it puts it
with a timeout of 0ms, so if succeeds, great, if not, it's ignored (someone
else might be putting the same entity in the database).
View the
Guillaume, we've been discussing best practices for sharing Cache instances
between apps and currently, the best way to do so from AS is explained in
http://tinyurl.com/lq688t, section 11.2. Paraphrasing Brian Stansberry, the AS
Clustering Lead:
anonymous wrote : 1) Use the CacheManager to
http://tinyurl.com/lq688t
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4237893#4237893
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4237893
___
jboss-user mailing list
See my comment in
http://www.jboss.org/index.html?module=bbop=viewtopict=156458start=10
I believe your method is still valid in spite of the deprecation. I'm trying to
get further clarification on this and will let u know.
View the original post :
Pojo cache could help reduce the replication payload when replicating that 10MB
object because only the fields of the pojo that have changed would be
replicated. With jboss cache core, the entire object would need to be
serialized and sent around whenever there's a slight change to it.
View
If you're looking for an example on how to create eviction regions
programatically with latest JBoss Cache, I'd suggest you check out EJB3 trunk
(http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/) and have a look
to org.jboss.ejb3.cache.tree.StatefulTreeCache where we create an
58 matches
Mail list logo
