JBossDeveloper

"mplesser" wrote:

You're right sorry, i just double checked again, although it is readable from the local instance outside of the transaction.

By other threads ? No, they are blocked unless the isolation level is NONE or READ_UNCOMMITTED (we use r/w locks here)

It does, but only if you are using it inside of JBoss. This is an issue though if used in another Application Server - only workaround for me was to declare a Logger inside TreeCache.java.

I'll fix this

I had a chance only to test it with OC4J and JBoss (cvs jboss-head) so far and it works.

Thanks

it happens on a put(String,String,Vector) and only during the 'startup phase'. I use a maybe odd concept here:
Whenever the coordinator receives a view-change from jgroups he issues a (rpc) method call via jgroups to all members in the cluster.

I hope you don't use a synchronous group RPC out of the viewChange() callback. This might lead to a distributed deadlock. viewChange() actions are supposed to be short-lived, or have to run in a separate thread.

Yes, this could be an initialization issue - apparently the interceptor chain has not yet been fully initialized.

It does, but only if you are using it inside of JBoss. This is an issue though if used in another Application Server - only workaround for me was to declare a Logger inside TreeCache.java.

It doesnt work to filter out the log messages in TreeCache using log4j.
If i set a category "org.jboss.cache" to say "WARN" then the TreeCache ignores that level and still logs all the "INFO" messages. This is because TreeCache is derived from ServiceMBeanSupport which is defined in package "org.jboss.system" and thus is using the Logger declared in ServiceMBeanSupport which is declared protected.
This causes confusion since you'd have to configure a category for "org.jboss.system" in log4j to control the log level of the TreeCache.

-markus

By other threads ? No, they are blocked unless the isolation level is NONE or READ_UNCOMMITTED (we use r/w locks here)

I hope you don't use a synchronous group RPC out of the viewChange() callback. This might lead to a distributed deadlock. viewChange() actions are supposed to be short-lived, or have to run in a separate thread.

Yes, this could be an initialization issue - apparently the interceptor chain has not yet been fully initialized.

"mplesser" wrote:
It doesnt work to filter out the log messages in TreeCache using log4j.
If i set a category "org.jboss.cache" to say "WARN" then the TreeCache ignores that level and still logs all the "INFO" messages. This is because TreeCache is derived from ServiceMBeanSupport which is defined in package "org.jboss.system" and thus is using the Logger declared in ServiceMBeanSupport which is declared protected.
This causes confusion since you'd have to configure a category for "org.jboss.system" in log4j to control the log level of the TreeCache.

-markus

"mplesser" wrote:

From within the same thread, isolation level is REPEATABLE_READ. I add a listener to the cache which performs a get() operation on the cache on a nodeModified() event. This might of course look for the cache to appear within the same TX and may not be fixable. Only option i could think of is using a backing cache or add a method to the cache that signals if it is in an uncommited TX state.

No, this is done in an asynchronous manner with callbacks.
I 'have' to do it that way since i can not add user defined properties to Address objects used by jgroups and have them replicated to the other nodes. Else each node could add a property to its own address for other nodes to read them. IF there is a way to do so already i just haven't found it out yet :)

Seems so - maybe add some checks here or buffer the operation till it is set up?

When the logger is created, we use getClass() which returns TreeCache.class and *not* ServiceMBeanSupport.class ! So logging works, just tested again with INFO and WARN. Maybe you're picking up the wrong log4j.props ? Do you use -Dlog4j.configuration, eg.

-Dlog4j.configuration=file:c:\log4j.properties ?

The same thread will of course see its changes made in the same TX. Only other threads are blocked. This is all as designed.

Do you have a small test case that reproduces the problem ?

There is :-) Have a look at ClusterPartition.startService() and search for the CONFIG event. You can set some user-defined bytes in an IpAddress, using {set,get}AdditionalData().

200c200
<
---
> protected HashMap channelConfig=null;
1000a1001,1009
> /**
> * Set configuration options for JChannel, that are passed
> * down as a CONFIG event upon connection.
> * @param channelConfig configuration options for the channel
> */
> public void setChannelConfig(HashMap channelConfig) {
> this.channelConfig=channelConfig;
> }
>
1053a1063,1066
> if( channelConfig != null ) {
> channel.down(new org.jgroups.Event(org.jgroups.Event.CONFIG, channelConfig));
> channel.getProtocolStack().flushEvents();
> }

"mplesser" wrote:

Hmm makes it hard - maybe you could think of adding a method that tells the user if the cache is in an uncommited transaction?

Took me a while to figure out that you are talking about the jboss clustering classes :)

I tried it but it seems that it doesn't work once the channel is connected. I do get access to the channel by using a class that is derived from TreeCache but the creation of the channel is immediatly followed by a connect in the startService()-method if TreeCache.

My suggestion would be to apply this patch to TreeCache (current cvs head):

This adds a setChannelConfig() method where a HashMap can be supplied that is passed down the channel right before it connects.

"bela" wrote:

Suggestion: why don't you override startService() in your subclass ?

Made those methods protected, so go and override startService()

Bela

Thanks a lot again :)

I can now finally confirm that the TX-lookups work under WebSphere 5.1 !
(And you can't imagine how i hate WebSphere by now ....)

good !