[JBoss JIRA] Created: (JGRP-628) Discovery: add cluster name to discovery request to be able to discard responses from different clusters
by Bela Ban (JIRA)
Discovery: add cluster name to discovery request to be able to discard responses from different clusters
--------------------------------------------------------------------------------------------------------
Key: JGRP-628
URL: http://jira.jboss.com/jira/browse/JGRP-628
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.6.1, 2.7
When we have 2 groups ONE and TWO:
ONE: 228.8.8.8:7500 and
TWO: 228.1.2.3:7500
In some cases, they will receive each other's traffic (http://wiki.jboss.org/wiki/Wiki.jsp?page=PromiscuousTraffic).
Assume ONE has members {A,B,C} and TWO has no members yet. When D (in cluster TWO) starts up and sends out a discovery request, it might also receive discovery responses from ONE (A,B,C). D might now identify A as coordinator and send a JOIN-REQ to A. However, A will discard that request as the group name of D's request is TWO rather than ONE !
Result: D's JOIN-REQ will hang !
Note that the transport (TP) does drop messages from different clusters, but this happens only after the new member has joined the group, so discovery requests/responses from different groups are *not* discarded.
Tasks:
- Verify that the transport-name matching algorithm in TP is correct
- Confirm that - on initial discovery - discovery requests and responses are not matched
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 11 months
[JBoss JIRA] Created: (JGRP-656) Flag to determine when a message is considered delivered
by Bela Ban (JIRA)
Flag to determine when a message is considered delivered
--------------------------------------------------------
Key: JGRP-656
URL: http://jira.jboss.com/jira/browse/JGRP-656
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.7
Attachments: tmp.java
Okay, I know what the problem is.
When a multicast message is received from sender A, then a lock is acquired for A (or we block until A's done processing the message and releases the lock).
When the receive() method would send more messages down the stack, that lock might get held for potentially a long time. So I made the following change: I assume that calling down() from within receive() means that the message has been *delivered*, so I release the lock held for A and someone else can now acquire that lock. If you comment the lines of ProtocolStack.down() and recompile JGroups, then you will always see a count of 1:
public Object down(Event evt) {
ReentrantLock lock=locks.remove(Thread.currentThread());
//if(lock != null && lock.isHeldByCurrentThread()) {
// lock.unlock();
//if(log.isTraceEnabled())
// log.trace("released lock held by " + Thread.currentThread());
//}
if(top_prot != null)
return top_prot.down(evt);
return null;
}
The issue here is that I don't want to block incoming calls just because the receive() method sends other messages. This is described in http://jira.jboss.com/jira/browse/JGRP-535.
I might introduce a flag in ProtocolStack to configure this behavior...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 11 months
[JBoss JIRA] Assigned: (JBAOP-256) java.lang.RuntimeException: defrost(): org.jboss.jms.client.delegate.ClientBrowserDelegate$... was pruned
by Flavia Rainone (JIRA)
[ http://jira.jboss.com/jira/browse/JBAOP-256?page=all ]
Flavia Rainone reassigned JBAOP-256:
------------------------------------
Assignee: Flavia Rainone
> java.lang.RuntimeException: defrost(): org.jboss.jms.client.delegate.ClientBrowserDelegate$... was pruned
> ---------------------------------------------------------------------------------------------------------
>
> Key: JBAOP-256
> URL: http://jira.jboss.com/jira/browse/JBAOP-256
> Project: JBoss AOP
> Issue Type: Bug
> Affects Versions: 1.5.0.GA
> Reporter: Ovidiu Feodorov
> Assigned To: Flavia Rainone
>
> Messaging build fails at the AOPC phase if we dont' do a full clean after modifying advised clases.
> An example of exception that is thrown by the AOPC in such cases follows:
> compile-classes:
> [javac] Compiling 1 source file to C:\work\src\cvs\jboss-head\jms\output\classes
> [aopc] java.lang.RuntimeException: defrost(): org.jboss.jms.client.delegate.ClientBrowserDelegate$close_N4742752445160157748 was pruned.
> [aopc] at javassist.CtClassType.checkPruned(CtClassType.java:1093)
> [aopc] at javassist.CtClassType.defrost(CtClassType.java:272)
> [aopc] at org.jboss.aop.instrument.OptimizedInvocations.defrostClassIfExists(OptimizedInvocations.java:66)
> [aopc] at org.jboss.aop.instrument.OptimizedInvocations.makeInvocationClass(OptimizedInvocations.java:96)
> [aopc] at org.jboss.aop.instrument.OptimizedMethodInvocations.createOptimizedInvocationClass(OptimizedMethodInvocations.java:78)
> [aopc] at org.jboss.aop.instrument.OptimizedMethodExecutionTransformer.transformMethod(OptimizedMethodExecutionTransformer.java:59)
> [aopc] at org.jboss.aop.instrument.MethodExecutionTransformer.instrument(MethodExecutionTransformer.java:137)
> [aopc] at org.jboss.aop.instrument.Instrumentor.transform(Instrumentor.java:654)
> [aopc] at org.jboss.aop.AspectManager.translate(AspectManager.java:835)
> [aopc] at org.jboss.aop.AspectManager.transform(AspectManager.java:747)
> [aopc] at org.jboss.aop.standalone.Compiler.compileFile(Compiler.java:345)
> [aopc] at org.jboss.aop.standalone.Compiler.compile(Compiler.java:234)
> [aopc] at org.jboss.aop.standalone.Compiler.main(Compiler.java:90)
> [aopc] [error] failed to transform: org.jboss.jms.client.delegate.ClientBrowserDelegate.. Do verbose mode if you want full stack trace.
> [aopc] java.lang.RuntimeException: failed to transform: org.jboss.jms.client.delegate.ClientBrowserDelegate
> [aopc] at org.jboss.aop.instrument.Instrumentor.transform(Instrumentor.java:728)
> [aopc] at org.jboss.aop.AspectManager.translate(AspectManager.java:835)
> [aopc] at org.jboss.aop.AspectManager.transform(AspectManager.java:747)
> [aopc] at org.jboss.aop.standalone.Compiler.compileFile(Compiler.java:345)
> [aopc] at org.jboss.aop.standalone.Compiler.compile(Compiler.java:234)
> [aopc] at org.jboss.aop.standalone.Compiler.main(Compiler.java:90)
> [aopc] Caused by: java.lang.RuntimeException: defrost(): org.jboss.jms.client.delegate.ClientBrowserDelegate$close_N4742752445160157748 was pruned.
> [aopc] at javassist.CtClassType.checkPruned(CtClassType.java:1093)
> [aopc] at javassist.CtClassType.defrost(CtClassType.java:272)
> [aopc] at org.jboss.aop.instrument.OptimizedInvocations.defrostClassIfExists(OptimizedInvocations.java:66)
> [aopc] at org.jboss.aop.instrument.OptimizedInvocations.makeInvocationClass(OptimizedInvocations.java:96)
> [aopc] at org.jboss.aop.instrument.OptimizedMethodInvocations.createOptimizedInvocationClass(OptimizedMethodInvocations.java:78)
> [aopc] at org.jboss.aop.instrument.OptimizedMethodExecutionTransformer.transformMethod(OptimizedMethodExecutionTransformer.java:59)
> [aopc] at org.jboss.aop.instrument.MethodExecutionTransformer.instrument(MethodExecutionTransformer.java:137)
> [aopc] at org.jboss.aop.instrument.Instrumentor.transform(Instrumentor.java:654)
> [aopc] ... 5 more
> [aopc] Exception in thread "main"
> BUILD FAILED
> C:\work\src\cvs\jboss-head\jms\build.xml:339: Java returned: 1
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 11 months
[JBoss JIRA] Created: (JBCACHE-1251) Re-adding invalidated node fails with invalidation + pessimistic locking
by Brian Stansberry (JIRA)
Re-adding invalidated node fails with invalidation + pessimistic locking
------------------------------------------------------------------------
Key: JBCACHE-1251
URL: http://jira.jboss.com/jira/browse/JBCACHE-1251
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.1.0.CR2
Reporter: Brian Stansberry
Assigned To: Manik Surtani
Scenario is one where a parent node represents a structural node, and then child nodes represent different data elements.
Such data structures are set up on both caches, and then the parent node is removed (globally, via INVALIDATION) and re-added (locally) on one cache. This represents an attempt to clear the region -- removing a node and re-adding is one of the only ways to do this.
On the second cache, the fact that the structural node is missing is detected, and an attempt is made to re-add it locally. This fails with pessimistic locking:
18:50:34,821 TRACE PessimisticLockInterceptor:71 - PessimisticLockInterceptor invoked for method MethodName: _put; MethodIdInteger: 1; Args: (null, /test/com/foo/test/ENTITY, null, true)
18:50:34,821 TRACE PessimisticLockInterceptor:292 - Attempting to lock node /test/com/foo/test/ENTITY for owner Thread[main,5,main]
18:50:34,822 TRACE PessimisticLockInterceptor:334 - Directly got child node null
18:50:34,822 TRACE IdentityLock:264 - acquiring RL: fqn=/, caller=Thread[main,5,main], lock=<unlocked>
18:50:34,823 TRACE IdentityLock:270 - acquired RL: fqn=/, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,823 TRACE PessimisticLockInterceptor:334 - Directly got child node test
18:50:34,824 TRACE IdentityLock:264 - acquiring RL: fqn=/test, caller=Thread[main,5,main], lock=<unlocked>
18:50:34,824 TRACE IdentityLock:270 - acquired RL: fqn=/test, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,825 TRACE PessimisticLockInterceptor:334 - Directly got child node com
18:50:34,825 TRACE IdentityLock:264 - acquiring RL: fqn=/test/com, caller=Thread[main,5,main], lock=<unlocked>
18:50:34,826 TRACE IdentityLock:270 - acquired RL: fqn=/test/com, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,826 TRACE PessimisticLockInterceptor:334 - Directly got child node foo
18:50:34,827 TRACE IdentityLock:264 - acquiring RL: fqn=/test/com/foo, caller=Thread[main,5,main], lock=<unlocked>
18:50:34,827 TRACE IdentityLock:270 - acquired RL: fqn=/test/com/foo, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,828 TRACE PessimisticLockInterceptor:334 - Directly got child node test
18:50:34,828 TRACE IdentityLock:264 - acquiring RL: fqn=/test/com/foo/test, caller=Thread[main,5,main], lock=<unlocked>
18:50:34,829 TRACE IdentityLock:270 - acquired RL: fqn=/test/com/foo/test, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,829 TRACE PessimisticLockInterceptor:334 - Directly got child node ENTITY
18:50:34,830 TRACE IdentityLock:164 - acquiring WL: fqn=/test/com/foo/test/ENTITY, caller=Thread[main,5,main], lock=<unlocked>
18:50:34,830 TRACE IdentityLock:170 - acquired WL: fqn=/test/com/foo/test/ENTITY, caller=Thread[main,5,main], lock=write owner=Thread[main,5,main]
18:50:34,831 TRACE PessimisticLockInterceptor:292 - Attempting to lock node /test/com/foo/test/ENTITY for owner Thread[main,5,main]
18:50:34,831 TRACE PessimisticLockInterceptor:334 - Directly got child node null
18:50:34,832 TRACE IdentityLock:264 - acquiring RL: fqn=/, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,832 TRACE IdentityLock:307 - acquireReadLock(): caller Thread[main,5,main] already owns lock for /
18:50:34,833 TRACE IdentityLock:270 - acquired RL: fqn=/, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,833 TRACE PessimisticLockInterceptor:334 - Directly got child node test
18:50:34,834 TRACE IdentityLock:264 - acquiring RL: fqn=/test, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,834 TRACE IdentityLock:307 - acquireReadLock(): caller Thread[main,5,main] already owns lock for /test
18:50:34,835 TRACE IdentityLock:270 - acquired RL: fqn=/test, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,835 TRACE PessimisticLockInterceptor:334 - Directly got child node com
18:50:34,836 TRACE IdentityLock:264 - acquiring RL: fqn=/test/com, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,836 TRACE IdentityLock:307 - acquireReadLock(): caller Thread[main,5,main] already owns lock for /test/com
18:50:34,837 TRACE IdentityLock:270 - acquired RL: fqn=/test/com, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,837 TRACE PessimisticLockInterceptor:334 - Directly got child node foo
18:50:34,838 TRACE IdentityLock:264 - acquiring RL: fqn=/test/com/foo, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,838 TRACE IdentityLock:307 - acquireReadLock(): caller Thread[main,5,main] already owns lock for /test/com/foo
18:50:34,839 TRACE IdentityLock:270 - acquired RL: fqn=/test/com/foo, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,839 TRACE PessimisticLockInterceptor:334 - Directly got child node test
18:50:34,840 TRACE IdentityLock:264 - acquiring RL: fqn=/test/com/foo/test, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,840 TRACE IdentityLock:307 - acquireReadLock(): caller Thread[main,5,main] already owns lock for /test/com/foo/test
18:50:34,841 TRACE IdentityLock:270 - acquired RL: fqn=/test/com/foo/test, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,841 TRACE PessimisticLockInterceptor:334 - Directly got child node ENTITY
18:50:34,842 TRACE IdentityLock:164 - acquiring WL: fqn=/test/com/foo/test/ENTITY, caller=Thread[main,5,main], lock=write owner=Thread[main,5,main]
18:50:34,842 TRACE IdentityLock:187 - acquireWriteLock(): caller already owns lock for /test/com/foo/test/ENTITY (caller=Thread[main,5,main])
18:50:34,843 TRACE IdentityLock:170 - acquired WL: fqn=/test/com/foo/test/ENTITY, caller=Thread[main,5,main], lock=write owner=Thread[main,5,main]
18:50:34,843 TRACE PessimisticLockInterceptor:292 - Attempting to lock node /test/com/foo/test/ENTITY for owner Thread[main,5,main]
18:50:34,844 TRACE PessimisticLockInterceptor:334 - Directly got child node null
..... continues looping through the hierarchy until the timeout kicks in and a TimeoutException is thrown
The above described scenario describes what happens with the "region clearing" operations in the Hibernate/JBC integration.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 11 months
[JBoss JIRA] Created: (JASSIST-40) Bug with 'insertAfter' called with 'asFinally' and the '$w' keyword on methods with a 'void' return type
by Patrice Bouillet (JIRA)
Bug with 'insertAfter' called with 'asFinally' and the '$w' keyword on methods with a 'void' return type
--------------------------------------------------------------------------------------------------------
Key: JASSIST-40
URL: http://jira.jboss.com/jira/browse/JASSIST-40
Project: Javassist
Issue Type: Bug
Reporter: Patrice Bouillet
Assigned To: Shigeru Chiba
Altering a method with a void return type by calling insertAfter containing the $_ keyword results in the following exception for example:
Exception in thread "main" java.lang.VerifyError: (class: VoidReturnType, method: doNothing signature: ()V) Register 2 contains wrong type
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:1618)
at java.lang.Class.getConstructor0(Class.java:1930)
at java.lang.Class.newInstance0(Class.java:278)
at java.lang.Class.newInstance(Class.java:261)
at InsertAfterAsFinally.main(InsertAfterAsFinally.java:16)
The test source code to generate this error:
public class InsertAfterAsFinally {
public static void main(String[] args) {
ClassPool cp = ClassPool.getDefault();
try {
CtClass cc = cp.get("VoidReturnType");
CtMethod cm = cc.getDeclaredMethod("doNothing");
cm.insertAfter("System.out.println(\"return value: \" + $_);", true);
Class clazz = cc.toClass();
VoidReturnType vrt = (VoidReturnType) clazz.newInstance();
vrt.doNothing();
} catch (NotFoundException e) {
e.printStackTrace();
} catch (CannotCompileException e) {
e.printStackTrace();
} catch (InstantiationException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
}
}
}
public class VoidReturnType {
void doNothing() {
}
}
========================================
The problem seems to be in the insertAfterHandler method in the CtBehaviour class. The following modification from
if (rtype.isPrimitive())
to:
if (rtype.isPrimitive() && (rtype != CtClass.voidType))
fixes the error.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 11 months