September 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-1326) Gossip Router dropping message for node that is in its routing table list

by vivek v (JIRA)

Gossip Router dropping message for node that is in its routing table list ------------------------------------------------------------------------- Key: JGRP-1326 URL: https://issues.jboss.org/browse/JGRP-1326 Project: JGroups Issue Type: Bug Affects Versions: 2.10 Environment: Linux, Windows Reporter: vivek v Assignee: Bela Ban We are using Tunnel protocol with two Gossip Routers. For some reason we start seeing lots of suspect messages in all the nodes - there are 7 nodes in the group. Six of the nodes (including the coordinator) was suspecting node A (manager_172.27.75.11) and node A was suspecting the coordinator, but no new view was being created. After turning on the trace on both gossip routers (GR1 and GR2) I see following for every message that's sent to Node A (manager_172.27.75.11), {noformat} 2011-05-20 15:56:21,186 TRACE [gossip-handlers-6] GossipRouter - cannot find manager_172.27.75.11:4576 in the routing table, routing table= 172.27.75.11_group: probe_172.27.75.13:4576, collector_172.27.75.12:4576, probe_172.27.75.15:4576, manager_172.27.75.11:4576, probe_172.27.75.16:4576, probe_172.27.75.14:4576 {noformat} Now, the issue is the routing table does indeed shows that there is "manager_172.27.75.11" - so why is the GR dropping messages for that node. I suspect that somehow the Gossip Router has got some old entry which has not been cleaned up - different UUID with same logical address. I tried going through the GossipRouter.java code, but couldn't find how would this be possible. As I understand a node randomly chooses a GR if there are multiple of them for its communication. Each GR would keep a separate list of physical addresses for each node - so is it possible somehow it uses physical address instead of UUID for cleaning/retrieving the node list? This seems to be creating big issue and the only work around is to restart the Gossip Routers. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

4
13
0 / 0

[JBoss JIRA] (AS7-5574) Switch to standard Java debug options -agentlib

by Cheng Fang (JIRA)

Cheng Fang created AS7-5574: ------------------------------- Summary: Switch to standard Java debug options -agentlib Key: AS7-5574 URL: https://issues.jboss.org/browse/AS7-5574 Project: Application Server 7 Issue Type: Feature Request Components: Documentation, Scripts Affects Versions: 7.2.0.Alpha1 Reporter: Cheng Fang Assignee: Brian Stansberry AS7 currently has the Java debug options -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n This uses non-standard options, which may be removed in future JDK, and may not work with other vendors' JDK. How about switching to use the standard options, to make it easier to maintain and port? -agentlib:jdwp=transport=dt_socket,address=localhost:8787,server=y,suspend=n -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
4
0 / 0

[JBoss JIRA] (AS7-5059) Deprecate no-arg OperationContext.completeStep() variant

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-5059: ------------------------------------- Summary: Deprecate no-arg OperationContext.completeStep() variant Key: AS7-5059 URL: https://issues.jboss.org/browse/AS7-5059 Project: Application Server 7 Issue Type: Task Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Deprecate OperationContext.completeStep() in favor of OperationContext.completeStep(RollbackHandler) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
5
0 / 0

[JBoss JIRA] (AS7-5637) Broken footer layout

by Heiko Braun (JIRA)

Heiko Braun created AS7-5637: -------------------------------- Summary: Broken footer layout Key: AS7-5637 URL: https://issues.jboss.org/browse/AS7-5637 Project: Application Server 7 Issue Type: Feature Request Components: Console Reporter: Heiko Braun Assignee: Heiko Braun Fix For: 7.2.0.Alpha1 See JBPAPP-10016 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
3
0 / 0

[JBoss JIRA] (AS7-5447) The footer linkes (rhs) overlay each other

by Heiko Braun (JIRA)

Heiko Braun created AS7-5447: -------------------------------- Summary: The footer linkes (rhs) overlay each other Key: AS7-5447 URL: https://issues.jboss.org/browse/AS7-5447 Project: Application Server 7 Issue Type: Bug Components: Console Reporter: Heiko Braun Assignee: Heiko Braun Fix For: 7.2.0.Alpha1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
3
0 / 0

[JBoss JIRA] Created: (JGRP-1165) Out-of-sync views in the cluster causes NAKACK issues and invalid node list at application layer

by vivek v (JIRA)

Out-of-sync views in the cluster causes NAKACK issues and invalid node list at application layer ------------------------------------------------------------------------------------------------- Key: JGRP-1165 URL: https://jira.jboss.org/jira/browse/JGRP-1165 Project: JGroups Issue Type: Bug Affects Versions: 2.9, 2.8 Reporter: vivek v Assignee: Bela Ban There is a logic in GMS (in the installView(..) method) where it checks whether the node itself is in the view or not, if not then just discard the view, if(checkSelfInclusion(mbrs) == false) { if(log.isWarnEnabled()) log.warn(local_addr + ": not member of view " + new_view + "; discarding it"); return; } Now, the problem /w this logic is that the node will remain /w the old view and when trying to send message to the members in the old view the messages would be discarded /w NAKACK as this node won't be there in their new view. So here is an example, 1) 3 nodes all with same view - V1 {n1, n2, n3} 2) n1 (coordinator) suspects (due to missing heartbeat) n2 and publishes new view - V2 {n1, n3} - n2 discards the suspect message from n1 as FD_SOCK is still connected 3) n2 receives this view, but discards it due to the logic in GMS 4) n2 still keeps the old view V1 and continue to send messages to n1 and n3. n1 and n3 will discard messages from n2 /w NAKACK as it's not in their view (V2). 5) After few minutes (could be 10-15 minutes or more) n1 will publish a merge view V3(n1, n2,n3} - joining V1 and V2. Now all nodes got the same view The problem is on n2 the application layer will never know that it can't talk to n1 and n3 - thus, the RPC calls will fail during the time the nodes had different views. I would assume if a node gets a view, which doesn't have itself in it - it should drop all the nodes that are in that new view. So, basically we will create two new subgroups. This way we won't discard messages from each other. The application layer needs to know at all times what nodes can it talk to. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

4
23
0 / 0

[JBoss JIRA] (AS7-5593) Provide a module alias for backward compatible bundle deployments

by Thomas Diesler (JIRA)

Thomas Diesler created AS7-5593: ----------------------------------- Summary: Provide a module alias for backward compatible bundle deployments Key: AS7-5593 URL: https://issues.jboss.org/browse/AS7-5593 Project: Application Server 7 Issue Type: Feature Request Components: OSGi Reporter: Thomas Diesler Assignee: Thomas Diesler Fix For: 7.2.0.Alpha1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
2
0 / 0

[JBoss JIRA] (AS7-5496) Hibernate proxy class not found in remote EJB call

by Uwe Seimet (JIRA)

Uwe Seimet created AS7-5496: ------------------------------- Summary: Hibernate proxy class not found in remote EJB call Key: AS7-5496 URL: https://issues.jboss.org/browse/AS7-5496 Project: Application Server 7 Issue Type: Bug Components: Class Loading Affects Versions: 7.1.2.Final (EAP), 7.1.3.Final (EAP) Environment: Java 1.6.0_35 and Java 1.7.0_07 Mac OS X 10.8.1, Windows XP and Gentoo Linux 3.5.3 Reporter: Uwe Seimet Assignee: David Lloyd Prerequisites: 1. A JPA entity A with a reference to a different JPA entity B. FetchType is FetchType.LAZY, e.g. @Entity public class A { @ManyToOne(fetch = FetchType.LAZY) private B refToB; } @Entity public class B { } 2. A remote interface with methods passing an instance of A, .e.g. @Remote public interface ITest { A test1(); void test2(A a); } 3. A process calling test1() and then test2() on the remote interface like this: @EJB(lookup = "...") private ITest iTest; public void ITest() { final A a = iTest.test1(); iTest.test2(a); } } Error description: When calling test1() an instance of A is returned. This instance is valid and works as expected. The reference to B is a proxy (something like B_$$_javassist_2), which was expected because B was loaded lazily and was never accessed in the remote process before. When passing the instance of A back by calling test2(a) an exception of this type is raised: java.lang.ClassNotFoundException: B_$$_javassist_2 from [Module "deployment.x.ear.y_ejb.jar:main" from Service Module Loader] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(Concurrent ClassLoader.java:468) It looks as if the proxy cannot be serialized or deserialized. The behavior is reproducible with different applications on different platforms. As soon as a proxy is passed as an argument in the remote call the exception is raised. The classloader settings are the standard JBoss settings. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

4
55
0 / 0

[JBoss JIRA] (JBRULES-3562) Drools cannot resolve functions when argument is a fact type

by Nedo Nedic (JIRA)

Nedo Nedic created JBRULES-3562: ----------------------------------- Summary: Drools cannot resolve functions when argument is a fact type Key: JBRULES-3562 URL: https://issues.jboss.org/browse/JBRULES-3562 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.3.0.Final Environment: Linux Ubuntu, JBoss 5.1.0 Reporter: Nedo Nedic Assignee: Mark Proctor Note that this only fails when MVEL dialect is used using non-primitive argument types (for an instance using fact types arguments). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

3
31
0 / 0

[JBoss JIRA] (AS7-5650) Upgrade JBoss Marshalling to 1.3.16.GA

by Scott Marlow (JIRA)

Scott Marlow created AS7-5650: --------------------------------- Summary: Upgrade JBoss Marshalling to 1.3.16.GA Key: AS7-5650 URL: https://issues.jboss.org/browse/AS7-5650 Project: Application Server 7 Issue Type: Feature Request Components: Build System Reporter: Scott Marlow Assignee: Paul Gier Fix For: 7.2.0.Alpha1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
2
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2012