you can pass all Properties to configure the JChannel via
TreeCache.setClusterProperties(String). This is exactly the String that is
passed to the Constructor of JChannel and allows to set whatever attributes you
like for any protocoll on the JGroups stack you define.
See JGroups-documentation
Bela wrote:
anonymous wrote : Set children=new TreeSet(result), no need for a clone().
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. (I
I just tracked this in the code - there seems to be no bug in this area.
Threadsafe access to the keyset is garanteed by a ReadLock on the Node.
The Concurrentmodificationexception should only be thrown, if
'getChildrenNames()' and the iteration over the keySet are not done within the
same tran
You are absolutely right - I did not read your posting carefully enaugh. Node's
'getChildren()' is known to be not threadsafe, while TreeCache's
'getChildrenNames(Fqn)' is intendet to be used by clients.
The ConcurrentModificationException is a bug. I'll fix this in cvs-head later
today, so it
jiwils wrote:
anonymous wrote : Since I am not using transactions...
I guess you should use transactions. Without transactions the
TransactionIsolationLevel is not imposed, there's no Node locking and as a
result the content of a Node might just be modified in the moment you are
calling 'get()'
Although the methods of 'Node' are declared as public, this class is
(currently) not intendet to be used directly by TreeCache-clients.
The only way to access TreeCache in a threadsafe manner is through TreeCache's
methods (put(), get() etc...)
The methods of Node are not threadsafe. Whenever
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).
View the original pos
So what? - Having 500k Nodes in a flat hirachy implies having 500k Entries in
the Root nodes 'children' HashMap. Not a big deal in terms of node-hirarchy.
Given you specify a reasonable evictiontimeout, you would not even have to
store 70% of 500k entries, but only the percentage that is actuall
It's absolutely unefficient to store a whole table in a single node -
Transactional locking, eviction and Cacheloading work on Node-level, not
key/value-pair level. As a result every 'put(Fqn,key,value)' would lock your
entire data if the Fqn being used is a constant.
You are better of if you m
You are right, as of JBossCache 1.1 get(Fqn,Key) is actually only being called
by the JUnit-testcases. In respect to TreeCache itself it's (yet) redundant.
Instead of returning null your CacheLoader should return a prefilled Map of
Key-Value-pairs when get(Fqn) is being called
Have a look into
The callbacks of TreeCacheListener run synchronous with the underlying method
that causes the event.
Locks generated by this underlying call are still held while the
callback-method is being executed.
e.g. there's a put(...) being executed. During the execution of the put a Node
is being creat
There's an Interface TransactionManagerLookup that you may implement. Your
TransactionManagerLookup-class simply returns the TransactionManager of your
choice.
Than you let TreeCache use this transactionmanagerlookup-class to make use of
the assigned transactionmanager by either passing an inst
The Exception you get ist expected behavior of synchronous replication.
With synchronous replication the caller will be notified of all
communication-errors that occour during replication. This is intendet
behaviour, your calling thread is notified so it can apply arbitrary actions.
TimeOutExce
You are right, that is how it's currently implemented. The read operation will
not create nodes not existing when there's no Cacheloader defined.
Thus without any previous 'put' there's not even the root-node to lock.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtop
actually isolationlevel SERIALIZABLE should result in what you expect to happen
since it makes use of EDU.oswego.cs.dl.util.concurrent.FIFOSemaphore wrapped
into an Identitylock as implementation of Sync. Thus read-locks are treated the
same as write-locks and will block until the end of Transac
If you use JBossCache as MBean-Service and put Objects into it that have been
loaded by the EJB-classloader from the ejb-jar, than you'l get a
ClassNotFoundException as soon you try to access the previously stored objects
after redeployment of your ejb-jar. This is because classes being loaded b
You are free in your decision how to map your 'keys' to the tree-structure that
TreeCache provides. You may also decide not to use the Tree-structure and store all
Records as Key-value-pairs in a single Node.
Keep in mind that locking is taking place on node-level. And the kind of lock being
us
given multicast is working on the machnice sample xml-files replSyncService.xml or
replAsyncService.xml will work out-of-the box without modification.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3851782#3851782
Reply to the post :
http://www.jboss.org/inde
mcast_addr has to be the same on both machines. Additionally the NIC has to setup that
multicast works (the route to 224.0.0.0 netmask 240.0.0.0 has to be bound to the NIC
and not the local loopback only so the ip-packages actually leave the machine). Just
search Google for 'multicast ip' to get
Ben, I'm using generic Objects in Fqn's in the DistributedState-Implementation I'm
currently working on. If I stay on this path this will not just be rarely used case
I know it's not easy implement configuration for eviction-policies that support this
or cache-loaders, but I'm shure we can s
u may want to check this out:
http://www.jboss.org/developers/guides/quickstart
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3850439#3850439
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3850439
it would be better design if Region.getFqn() returns an Fqn not a String so we could
use Fqn.isChildOf(Fqn) instead of String.startsWith()
BtW: Fqn are not just concatenated Strings - In the longrun we have to find a way to
configure Regions for eviction based on reall (Object-based) Fqn's.
If you are _not_ deploying the cache as MBean but instantiate it from your own code
(using the constructor and PropertyConfigurator) each instance will connect to the
same Group sharing the same data, but will not be the same cache instance. (As a
consequence the data would reside in memory mult
...so it's RTFFAQ instead of RTFM :-)
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3850159#3850159
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3850159
---
This S
Write an instance of org.jboss.cache.TreeCacheListener that logs what you want
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3850137#3850137
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3850137
--
I've seen in you other post, you use TreeCache from within hibernate, so as long the
bug in TreeCache is not fixed, you propably will not be able to use my workaround :-(
(that is: set FetchStateOnStartup to 'false' and call 'fetchState()' after 'start()')
maybe you change these few lines in hib
hmm in former times people just wouldt have posted a single word: RTFM
But to be fair - besides the code, there is not very much good documentation about
TreeCache out there. (So why don't read the code?)
ok:
eviction is supposed to happen locally. It's the mechanism being used to keep the size
I just sent you a first Draft of DistributedState based on TreeCache by email. Have
fun :-)
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3849811#3849811
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3849811
I'm allready working on this topic - Given it going to be incorporated in JBoss, it
should be there before the end of this year.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3849223#3849223
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=po
If not being evicted, all your objects will reside in memory. What takes the time is
the way you gonna access them.
Looking up a thousand Names first and then looking up a thousand Objects by name is
pretty much the slowest way at all to do this.
This is like a paperboy that just delivers one p
the NPE is due to regionManager being null in LRUPolicy.nodeAdded(Fqn):
| public void nodeAdded(Fqn fqn)
| {
| if(fqn.equals(ROOT))
| return;
| if(log_.isDebugEnabled())
| log_.debug("nodeAdded(): fqn- " + fqn);
| Region region
I did some brainstorming about this. I'm not satisfied with the design of Fqn as it is.
While components of the Fqn may be Object, if one wants to be a List be the component
of an Fqn he would have to cast the List to Object to call the intendet constructor
(which is not at all intuitive):
Fqn
Although I'm not using FQNs with elements other than String right now I think reducing
this to String-only makes the concept of FQN significantly less powerfull. Constrains
for keys in FQNs should be more or less equivalent to keys in Maps (e.g. must
implement 'equals()')
I'd rather see that sp
I'd suggest to make use of the oswego concurrent library instead of using simple
synchronisation.
e.g. use EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap instead of
HashMap
this will both:
- enshure we use the 'best-of-breed' solution for concurrent access
- be as close as possib
my company (10 empl., several hundred instances of J2EE-application-servers) is
planning to use JBoss application-server in production starting 2005. I'll be
technically responsible for this.
>From an enterprise customers standpoint anything that is known to fail 'every now and
>then' is not
I know about this - It's a decision whether to stay downwards compatible or change an
API for reasons of better design that helps to stay downwards-compatible later...
Any way - if we keep it this way (and there are good reasons for this) we must put in
the release-notes that this change might b
bela:
the price is that a business-transaction might fail just because loglevel is set to
'INFO'
I don't think this is a real good idea.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3847821#3847821
Reply to the post :
http://www.jboss.org/index.html?m
I agree.
It's a good idea to make LockingException und TimeoutException subclasses of a
CachingException, but it would be better if the method's signatures explicitly list
the exceptions that actually may be thrown.
The caller would still be free to just use a 'catch (CacheException ..)' instea
btw:
this is not just an issue of debugging - other methods like the various 'printInfo()'
(even in TreeCache()) eventually throwsConcurrentModificationException when being
called while the cache is in use.
If we want to keep the underlying Collections unsynchronized for performance-reasons,
w
e.g. in NodeMap it dosn't help that the method readerOwners() is synchronized, but the
Collection (readOwnerList_) being returned by it being unsynchronized.
It wouldn't even help to make the IdentityLock.toString()-method synchronized, since
the JVM's lock on the IdentityLock instance does not
I've notices these kind of exceptions in many areas of jboss-cache's 'toString()'
methods...
It's because all the Collections being used (e.g. ArrayList for readOwnerList in
LockMap.java, HashMap for data in Node.java ... ) are all unsynchronized and throw
ConcurrentModificationException whenev
self is choosen for the
local cache.
>Norbert: As a workaround you may include the >classes in the servers classpath, so
>the classes do >not have to be reloaded.
>That would mean that the those classes cannot be >hotdeployed at all!
also correct.
As you might see there is no way
just noticed that all methods in TreeCache that make use of invokeMethod are designed
to throw LockingException and TimeOutException but actually will allways throw
NestedRuntimeException which is the only Exception being thrown by invokeMethod().
as a result TreeCache behaves differently in res
using the files from JBossCache-1.1.zip (11.100.417 Bytes) that is currenly on
sourceforge
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3846764#3846764
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3846764
-
getting java.lang.UnsupportedClassVersionError: org/jboss/system/ServiceMBeanSupport
(Unsupported major.minor version 48.0) when trying to instantiate TreeCache on JDK
1.3.1...
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3846763#3846763
Reply to the post
this is due to the fact that objects in the cache that is residing in the same JVM as
the ejb are accessed by reference without any check whether the previous loaded
classes of these objects are accessible to the current ejb's classloader anymore. This
isn't easy to solve as long the objects the
thank you for the hint (must have been blind), but you must admit that it really sucks
when you start from scratch by downloading everything from JBoss-CVS and all
module-names are different from the directory-names that are refereced in the
build.xml's...
I had to change a few more lines to ge
I can't find TreeCacheMBean, TreeCacheViewMBean TreeCacheAOPMBean in CVS. I guess they
are without version-control placed on your harddisk.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3846296#3846296
Reply to the post :
http://www.jboss.org/index.html?modu
of course I checked this in separate code. Currenty I have a little trouble what
version / branch of jboss-cache to checkout from cvs to get it compiled against
jgroups 2.2.6
What do you recommend? jboss-cache 1.02 seems not to be tagged separately Check
out from CVS-head and work on the la
I suggest using jgroups 2.2.6 and change org.jgroups.util.ContextObjectInputStream as
it is implemented in JDK1.4:
package org.jgroups.util;
import java.io.IOException;
import java.io.ObjectStreamClass;
import java.io.InputStream;
import java.io.ObjectInputStream;
import java.util.HashMap;
/**
Ok, found it. It's caused by the design of org.jgroups.blocks.MethodCall.
MethodCall is used to call a remote method and for this it provides an an serialized
(externalized) Version of the method's signature.
primitive Types are externalized using their primitive Class (e.g. Boolean.TYPE).
Later
just digged a bit into the code, it seems that
org.javagroups.blocks.MethodCall.invoke() generates the IllegalArgumentException
because of the Boolean being passed in TreeCache.put():
public void put(Fqn fqn, Map data)
throws Exception
{
GlobalTransaction tx = getCurrentT
I'm getting the same problem with JBossCache 1.0.2 on JDK 1.3.
Here is what I get from the log:
first instance 1 is started in JVM 1
>15:14:29,148 [INFO] org.jboss.cache.TreeCache: cache mode is REPL_SYNC
>---
>GMS: address is siapp4c1:59485
>-
I'm going to use JBossCache as a distributed cache in an set of J2EE-applications for
8 registered Users / 2 per Day to share per-user-sessiondata across different
JSP/EJB-applications which reside on different BEA-6.1-Clusters. The applications are
allready productive and currenty using
54 matches
Mail list logo
