Fqn

[belaban]

Is anyone using FQNs where not all elements are strings, e.g. new Fqn[] {new Integer(1), new Integer(2), "three"}; ?

I'm thinking of making all elements strings. The reason is that we are having problems mapping FQNs of non-strings to (a) Sleepycat and (b) relational DBs when using a CacheLoader.

Anyone raise their hands who object making all elements of an FQN strings.

Bela

[belaban]

Sometimes:
The First Node:

48949 [main] INFO org.jboss.cache.PropertyConfigurator - configure(): attribute size: 18
49246 [main] INFO org.jboss.cache.TreeCache - setEvictionPolicyConfig(): [config: null]
49473 [main] INFO org.jboss.cache.TreeCache TreeCache - interceptor chain is:
class org.jboss.cache.interceptors.CallInterceptor
class org.jboss.cache.interceptors.ReplicationInterceptor
49474 [main] INFO org.jboss.cache.TreeCache TreeCache - cache mode is REPL_SYNC
51198 [DownHandler (UDP)] INFO org.jgroups.protocols.UDP - unicast sockets will use interface 172.19.66.58
51214 [DownHandler (UDP)] INFO org.jgroups.protocols.UDP - socket information:
local_addr=s58:41041, mcast_addr=224.0.0.36:55566, bind_addr=/172.19.66.58, ttl=32
sock: bound to 172.19.66.58:41041, receive buffer size=64000, send buffer size=32000
mcast_recv_sock: bound to 172.19.66.58:55566, send buffer size=150000, receive buffer size=80000
mcast_send_sock: bound to 172.19.66.58:41042, send buffer size=150000, receive buffer size=80000

-------------------------------------------------------
GMS: address is s58:41041
-------------------------------------------------------
53314 [main] INFO org.jboss.cache.TreeCache TreeCache - state could not be retrieved (must be first member in group)
53315 [main] INFO org.jboss.cache.eviction.LRUPolicy TreeCache - Starting eviction policy using the provider: org.jboss.cache.evi
ction.LRUPolicy
53343 [MessageDispatcher up processing thread] INFO org.jboss.cache.TreeCache - viewAccepted(): new members: [s58:41041]
53344 [MessageDispatcher up processing thread] INFO org.jboss.cache.TreeCache - new cache is null (maybe first member in cluster
)
53569 [main] INFO org.jboss.cache.eviction.LRUPolicy TreeCache - Starting a eviction timer with wake up interval of (secs) 5

The Second Node:

-------------------------------------------------------
GMS: address is s66:43373
-------------------------------------------------------
0 [MessageDispatcher up processing thread] ERROR org.jboss.cache.TreeCache - failed setting transient state
java.lang.NullPointerException
 at org.jboss.cache.eviction.LRUPolicy.nodeAdded(LRUPolicy.java:53)
 at org.jboss.cache.eviction.LRUPolicy.nodeCreated(LRUPolicy.java:92)
 at org.jboss.cache.TreeCache.notifyNodeCreated(TreeCache.java:3449)
 at org.jboss.cache.TreeCache.notifyAllNodesCreated(TreeCache.java:3501)
 at org.jboss.cache.TreeCache$MessageListenerAdaptor._setState(TreeCache.java:3012)
 at org.jboss.cache.TreeCache$MessageListenerAdaptor.setState(TreeCache.java:2954)
 at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.passUp(MessageDispatcher.java:613)
 at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:331)
 at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:720)
 at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:553)
 at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:689)
 at java.lang.Thread.run(Thread.java:534)

[norbert]

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 specific cacheloaders have the documented limitation to only support objects that return a unique value when calling 'toString()' or support some plugin-mechanism or use AOP to do the object-to-String mapping that ist required for the keys to be used by relational dBs.

[belaban]

I have thought about such a solution as well. The thing is that when you store {1,2,"3"}, you will get back {"1","2","3"}. Comparison in this case would fail.

Hmm, maybe we leave it, document this, and see how people like it.
Thanks for the input,

[norbert]

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 fqn = new Fqn((Object)list);

I'm not a fried of overloading Constructors or methods while keeping the number of arguments constant. It's not compatible with the design of generics (as they are in JDK5.0).

We would be better off having a default constructor and a constructor accepting an array of elements. To construct a Fqn from a List having an addList(List)-method would be better.

Since it's not taking any Object 'as is' right now, it's not a huge benefit to be allowed to use Object instead of String. Basically an Fqn is just a hirarchical name. It points to a context with bound attributes.

This lead me to the following: It might be better to adhere to standards and make TreeCache implement javax.naming.DirContext and Fqn implement javax.naming.Name. This way a TreeCache might be bound to a NamingContext in a way that all Contents of the TreeCache appear seamlessly within the JNDI. TreeCache could also be used as a high-speed distributed Namingservice for JBoss itself.

... just a few ideas I had last night