We're running JBC 1.4.1SP9 under WebSphere Application Server 6.0. In our
application, we're processing multiple file imports in parallel threads.
In this scenario we observe lost cache locks. In other words, the lock table
contains locks from transactions that have been rolled back or
Hi Manik,
I also thought that GMS messages shouldn't be delayed. My assumption from
browsing through the source and debugging was that JGroups messages don't use
the Message's buffer, but JBC messages do. So my condition for delaying is if
(msg.getBuffer()!=null msg.getBuffer().length0)
Would
Thank you for your answer, genman.
Evicting every 5 seconds would kill our performance, as we would rarely have a
cache hit.
I've managed to get my FIXED_DELAY protocol to work. It sits on the very top of
the stack and delays all Messages with getBuffer()!=null. Unit tests look good
so far, I
We're about to deploy our application using JBC. We have several systems that
work on two databases: The master DB that's always up to date and the slave DB
that is synchronized 5 seconds after the master DB. We use DB queue
replication.
All systems use the same cache. We do not always use
In our application, we need to remove some nodes (FQNs) from the cache before
reinserting them. We do not know which nodes must be removed exactly, so we
just remove their nearest FQN parent. The nodes are loaded using a CacheLoader
later in the same transaction.
For simplicity, let's say we
Hi Manik,
thank you for your response. This indeed makes sense, though I forgot to
mention that our custom CacheLoader is one-way; it does not write any values
back to the store.
Is there a way I can configure JBC so it does not try to persist the data using
the CacheLoader?
Regarding locks,
For all readers, the issue is http://jira.jboss.com/jira/browse/JBCACHE-1352.
I fear the workaround you propose will not work for us, as deploying as an
MBean is not an option.
What are the plans regarding the next SP for 1.4.1?
Do you expect the workaround of adding the channel members to the
Sure. It is the same as in replAsync-service.xml, safe for the loopback and
num_initial_members attributes.
config
| !-- UDP: if you have a multihomed machine,
| set the bind_addr attribute to the appropriate NIC IP address --
| !-- UDP: On Windows machines, because of the
The trace.log starting from the call of startService() follows:
[5/16/08 16:01:21:840 CEST] 0027 TreeCache I org.jboss.cache.TreeCache
_createService No transaction manager lookup class has been defined.
Transactions cannot be used
| [5/16/08 16:01:21:934 CEST] 0027 TreeCache
My JGroups version is 2.4.2. So far I haven't found anything on their site, but
I'm still searching.
The Multiplexer doesn't seem to be the reason anyway. I've narrowed down the
problem to the following code:
// Builds a properties String
| JGroupsProperties props = new JGroupsProperties();
Hi Manik, thank you for your reply, I haven't seen it until now.
The reason we're on 1.4.1 is that we're stuck to using WebSphere 6.0 for now,
which means Java 1.4.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4150614#4150614
Reply to the post :
No view change messages. I've seen them before using the multiplexer, but not
now:
[5/14/08 12:48:16:183 CEST] 0028 TreeCache I org.jboss.cache.TreeCache
_createService channel is already running
| [5/14/08 12:48:16:215 CEST] 0029 UDP I
org.jgroups.protocols.UDP
Hi there,
thank you, Shorrockin, for describing the problem and more importantly the
solution in detail. In fact, I'm having the very same problem of creating a
TreeCache instance with a multiplexer channel (JBoss Cache 1.4.1.SP9).
Here's my code:
JChannelFactory factory=new
13 matches
Mail list logo
