[JBoss JIRA] Created: (JASSIST-137) getDeclaringClass() throws IncompatibleClassChangeError on copy of inner class
by Ragnar Rova (JIRA)
getDeclaringClass() throws IncompatibleClassChangeError on copy of inner class
------------------------------------------------------------------------------
Key: JASSIST-137
URL: https://issues.jboss.org/browse/JASSIST-137
Project: Javassist
Issue Type: Bug
Affects Versions: 3.14.0.GA
Environment: sun jdk1.6.0_21
Reporter: Ragnar Rova
Assignee: Shigeru Chiba
Creating a copy of a inner class and then calling getDeclaringClass() on the copied class causes error. How to create a copy of such a class?
java.lang.IncompatibleClassChangeError: foo.GetDeclaringClassTest and foo.GetDeclaringClassTest$Foo$BackRef disagree on InnerClasses attribute
at java.lang.Class.getDeclaringClass(Native Method)
at foo.GetDeclaringClassTest.get_declaring_class_should_not_throw_error(GetDeclaringClassTest.java:20)
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[JBoss JIRA] Created: (JGRP-1272) FC: all threads are blocked at credits_available.await
by Victor N (JIRA)
FC: all threads are blocked at credits_available.await
------------------------------------------------------
Key: JGRP-1272
URL: https://issues.jboss.org/browse/JGRP-1272
Project: JGroups
Issue Type: Bug
Affects Versions: 2.11
Environment: ubuntu 10.04.1
Reporter: Victor N
Assignee: Bela Ban
Attachments: jgroups-tcp.xml
After several days of working one node can not rejoin because of FC protocol issue. The situation is reproduced once or several times per week.
The problematic node is called "gate9", its view is outdated:
[gate10.mydomain|1175] [gate10.mydomain, gate7.mydomain, gate8.mydomain, gate9.mydomain, gate11.mydomain, gate14.mydomain, gate5.mydomain, gate12.mydomain, gate2.mydomain, gate4.mydomain, gate3.mydomain, gate6.mydomain]
Actual view (seen by all other nodes) is: [gate10.mydomain|1176] [gate10.mydomain, gate7.mydomain, gate8.mydomain, gate11.mydomain, gate14.mydomain, gate5.mydomain, gate12.mydomain, gate2.mydomain, gate4.mydomain, gate3.mydomain, gate6.mydomain]
In log file at gate9 I can see that it sends CREDIT_REQUEST constantly:
17/01/2011 09:55:52 UTC| TRACE | org.jgroups.protocols.TP.down(): sending msg to gate10.mydomain, src=gate9.mydomain, headers are FC: CREDIT_REQUEST, UNICAST: DATA, seqno=4308, conn_id=14, TCP: [channel_name=GateCluster]
17/01/2011 09:55:52 UTC| TRACE | org.jgroups.protocols.BasicTCP.sendUnicast(): dest=192.168.1.10:40001 (94 bytes)
17/01/2011 09:55:52 UTC| TRACE | org.jgroups.protocols.UNICAST.retransmit(): gate9.mydomain --> XMIT(gate10.mydomain: #2014)
17/01/2011 09:55:52 UTC| TRACE | org.jgroups.protocols.TP.down(): sending msg to gate10.mydomain, src=gate9.mydomain, headers are FC: CREDIT_REQUEST, UNICAST: DATA, seqno=2014, conn_id=14, TCP: [channel_name=GateCluster]
17/01/2011 09:55:52 UTC| TRACE | org.jgroups.protocols.BasicTCP.sendUnicast(): dest=192.168.1.10:40001 (94 bytes)
17/01/2011 09:55:52 UTC| TRACE | org.jgroups.protocols.UNICAST.retransmit(): gate9.mydomain --> XMIT(gate10.mydomain: #1124)
...
At gate10 (the coordinator) I see that it receives the requests and responds:
17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.TP.passMessageUp(): received [dst: gate10.mydomain, src: gate9.mydomain (3 headers), size=9 bytes], headers are FC: CREDIT_REQUEST, UNICAST: DATA, seqno=2397, conn_id=14, TCP: [channel_name=GateCluster]
17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.UNICAST.handleDataReceived(): gate10.mydomain <-- DATA(gate9.mydomain: #2397, conn_id=14)
17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.UNICAST.sendRequestForFirstSeqno(): gate10.mydomain --> SEND_FIRST_SEQNO(gate9.mydomain)
17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.TP.down(): sending msg to gate9.mydomain, src=gate10.mydomain, headers are UNICAST: SEND_FIRST_SEQNO, seqno=0, TCP: [channel_name=GateCluster]
17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.TP.passMessageUp(): received [dst: gate10.mydomain, src: gate9.mydomain (3 headers), size=9 bytes], headers are FC: CREDIT_REQUEST, UNICAST: DATA, seqno=1202, conn_id=14, TCP: [channel_name=GateCluster]
17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.UNICAST.handleDataReceived(): gate10.mydomain <-- DATA(gate9.mydomain: #1202, conn_id=14)
17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.UNICAST.sendRequestForFirstSeqno(): gate10.mydomain --> SEND_FIRST_SEQNO(gate9.mydomain)
17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.TP.down(): sending msg to gate9.mydomain, src=gate10.mydomain, headers are UNICAST: SEND_FIRST_SEQNO, seqno=0, TCP: [channel_name=GateCluster]
...
but I do not see any answer to this at gate9.
My config and stack traces are attached below. I do not know how to reproduce the problem in tests. But it occurs, so I can provide you with any details, just let me know.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[JBoss JIRA] Created: (JGRP-1238) STABLE: determine best value for max_bytes
by Bela Ban (JIRA)
STABLE: determine best value for max_bytes
------------------------------------------
Key: JGRP-1238
URL: https://jira.jboss.org/browse/JGRP-1238
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.11
max_bytes should be determined as a function of the available memory, a max value that cannot be exceeded and the number of nodes in the cluster.
If we have more cluster nodes, and everyone sends messages, then *not* changing max_value would lead to too many STABLE messages being sent !
An example could be: max_bytes="1m" cap="0.25" // 25% of the available heap
If we have 5 nodes in the cluster, max_bytes would be set to 5m. With a heap of 100MiB, if we have 30 nodes, max_bytes would be set to max(30Mib, 0.25 * 100 Mib) == 25 MiB.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[JBoss JIRA] Created: (LOGTOOL-8) Exception create methods fail to compile if the exception type appears in source code (as opposed to being on the class path)
by David Lloyd (JIRA)
Exception create methods fail to compile if the exception type appears in source code (as opposed to being on the class path)
-----------------------------------------------------------------------------------------------------------------------------
Key: LOGTOOL-8
URL: https://issues.jboss.org/browse/LOGTOOL-8
Project: Log Tool
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: David Lloyd
For methods which construct an exception, if the returned exception type is part of the module being compiled (as opposed to being on the compiled class path), processing fails with this exception:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.1:compile (default-compile) on project invocation-api: Compilation failure
[ERROR] /home/david/src/java/rws/invokable-container/api/src/main/java/org/jboss/invocation/InvocationLogger.java:[38,24] Return type org.jboss.invocation.InvocationException for method invocationException(java.lang.Throwable) is not in the classpath
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months