[JBoss JIRA] (JGRP-1486) Merge failure when dead instances remain in view
by David Hotham (JIRA)
David Hotham created JGRP-1486:
----------------------------------
Summary: Merge failure when dead instances remain in view
Key: JGRP-1486
URL: https://issues.jboss.org/browse/JGRP-1486
Project: JGroups
Issue Type: Bug
Affects Versions: 3.0.10
Reporter: David Hotham
Assignee: Bela Ban
I've hit this testing my JGRP-1485 fix, but I think it's a logically independent issue.
So, I've reached a point where:
- A, B and C all have view {C,A,B}
- D has view {B', D', D, A', C}, in which B', D' and A' are all dead instances
As in JGRP-1485, an optimal fix would surely be to allow D to recover all by itself, but it's not clear to me how to do that. However, my expectation was that a merge should sort things out; and I think that if it did then that ought to be good enough.
But what's actually happening is this:
- C becomes merge leader
- determines that merge participants are C, D', D, A'
- sends MERGE_REQ to those members
- the MERGE_REQ to D' reaches D (and that to A' reaches A)
- D sends a positive response for the MERGE_REQ that was meant for it, but after 2.5 seconds also sends a negative response to the MERGE_REQ meant for D'. (I think that the negative response is because it can't fetch the digest from D')
- likewise A sends a negative response to the MERGE_REQ meant for A'
So what C sees is:
- good responses from C and D, followed by merge_rejected responses from A and D
- so it removes A' and D' from the merge (it didn't get responses from them)
- then it removes D from the merge (because the most recent response from D said merge_rejected)
- so it is left only with itself, and comes up with a consolidated view that is identical to its original view
in short: the merge doesn't do anything useful after all.
I think that the key here is the confusion between D and D'. Possibly the fix is as simple as: ignore MERGE_REQs where the destination address on the message is not the local address.
I'll try this out and, if it looks good, submit a pull request.
--
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
11 years, 10 months
[JBoss JIRA] (AS7-5119) JMS Bridge service is started before JMS resources are deployed in JNDI
by Jeff Mesnil (JIRA)
Jeff Mesnil created AS7-5119:
--------------------------------
Summary: JMS Bridge service is started before JMS resources are deployed in JNDI
Key: AS7-5119
URL: https://issues.jboss.org/browse/AS7-5119
Project: Application Server 7
Issue Type: Bug
Components: JMS
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
Fix For: 7.2.0.Alpha1
Steps to reproduce:
1. add a <jms-bridge> to standalone-full.xml which depends on local JMS resources for its source or target destinations
2. start the AS7 instance
=> a stack trace is displayed because the JMS bridge is started before the JMS resources are available in the JNDI tree
{code}
08:45:59,638 INFO [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-1) HornetQ Server version 2.2.18.Final (HQ_2_2_18_FINAL, 122) [166a8a18-c5ec-11e1-b6e6-616f49f3825a]) started
08:45:59,641 INFO [org.hornetq.core.server.impl.HornetQServerImpl] (ServerService Thread Pool -- 63) trying to deploy queue jms.queue.sourceQueue
08:45:59,644 WARNING [org.hornetq.jms.bridge.impl.JMSBridgeImpl] (ServerService Thread Pool -- 61) Failed to connect bridge: javax.naming.NameNotFoundException: queue/sourceQueue -- service jboss.naming.context.java.queue.sourceQueue
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:97) [jboss-as-naming-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179) [jboss-as-naming-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:119) [jboss-as-naming-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:215) [jboss-as-naming-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_03-icedtea]
at org.hornetq.jms.bridge.impl.JNDIFactorySupport.createObject(JNDIFactorySupport.java:58) [hornetq-jms-2.2.18.Final.jar:2.2.18.Final (HQ_2_2_18_FINAL, 122)]
at org.hornetq.jms.bridge.impl.JNDIDestinationFactory.createDestination(JNDIDestinationFactory.java:40) [hornetq-jms-2.2.18.Final.jar:2.2.18.Final (HQ_2_2_18_FINAL, 122)]
at org.hornetq.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1124) [hornetq-jms-2.2.18.Final.jar:2.2.18.Final (HQ_2_2_18_FINAL, 122)]
at org.hornetq.jms.bridge.impl.JMSBridgeImpl.start(JMSBridgeImpl.java:358) [hornetq-jms-2.2.18.Final.jar:2.2.18.Final (HQ_2_2_18_FINAL, 122)]
at org.jboss.as.messaging.jms.bridge.JMSBridgeService.startBridge(JMSBridgeService.java:92) [jboss-as-messaging-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.as.messaging.jms.bridge.JMSBridgeService$1.run(JMSBridgeService.java:78) [jboss-as-messaging-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_03-icedtea]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_03-icedtea]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_03-icedtea]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA.jar:2.0.0.GA]
08:45:59,649 WARNING [org.hornetq.jms.bridge.impl.JMSBridgeImpl] (ServerService Thread Pool -- 61) Failed to start bridge
{code}
The JMS Bridge service has a dependency on the HornetQ service when one of its resources (source or target) is local but the JMS resources are bound to JNDI asynchronously *after* the HornetQ server is started.
The JMS bridge service should instead check whether its JMS resources are local or not. If they are local, it should add a direct dependency to the corresponding binder service (for both destination and CF resource)
--
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
11 years, 10 months
[JBoss JIRA] (AS7-5118) REGRESSION: JBoss 7 cannot process JBossXB in timer schedules
by Richard Kennard (JIRA)
Richard Kennard created AS7-5118:
------------------------------------
Summary: REGRESSION: JBoss 7 cannot process JBossXB in timer schedules
Key: AS7-5118
URL: https://issues.jboss.org/browse/AS7-5118
Project: Application Server 7
Issue Type: Bug
Components: Server
Affects Versions: 7.1.1.Final
Reporter: Richard Kennard
Assignee: Jason Greene
In JBoss AS 6, you could use 'JBossXB expressions' (sorry if that's the wrong terminology, I couldn't find much documentation on this) in ejb-jar.xml to configure timer schedules:
<session>
<ejb-name>Foo</ejb-name>
<timer>
<schedule>
<minute>*/${how.often:10}</minute>
<hour>*</hour>
</schedule>
The idea here is that 'minute' would default to 10, unless you passed -Dhow.often=5 as a VM arg.
This worked under AS 6, but under 7.1.1.Final you get:
Caused by: java.lang.NumberFormatException: For input string: "${how.often:10}"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) [rt.jar:1.6.0_24]
at java.lang.Integer.parseInt(Integer.java:449) [rt.jar:1.6.0_24]
at java.lang.Integer.parseInt(Integer.java:499) [rt.jar:1.6.0_24]
at org.jboss.as.ejb3.timerservice.schedule.attribute.IntegerBasedExpression.parseInt(IntegerBasedExpression.java:199)
at org.jboss.as.ejb3.timerservice.schedule.attribute.IntegerBasedExpression.processIncrement(IntegerBasedExpression.java:174)
at org.jboss.as.ejb3.timerservice.schedule.attribute.IntegerBasedExpression.<init>(IntegerBasedExpression.java:87)
at org.jboss.as.ejb3.timerservice.schedule.attribute.Minute.<init>(Minute.java:74)
at org.jboss.as.ejb3.timerservice.schedule.CalendarBasedTimeout.<init>(CalendarBasedTimeout.java:126)
at org.jboss.as.ejb3.timerservice.TimerServiceImpl.createCalendarTimer(TimerServiceImpl.java:477)
at org.jboss.as.ejb3.timerservice.TimerServiceImpl.loadAutoTimer(TimerServiceImpl.java:360)
at org.jboss.as.ejb3.timerservice.TimerServiceImpl.restoreTimers(TimerServiceImpl.java:681)
at org.jboss.as.ejb3.timerservice.TimerServiceImpl.start(TimerServiceImpl.java:190)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
--
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
11 years, 10 months
[JBoss JIRA] Created: (JBAS-5900) jars are not loaded from the lib directory of a sar in JBoss AS 5
by Matt Wringe (JIRA)
jars are not loaded from the lib directory of a sar in JBoss AS 5
-----------------------------------------------------------------
Key: JBAS-5900
URL: https://jira.jboss.org/jira/browse/JBAS-5900
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: ClassLoading
Affects Versions: JBossAS-5.0.0.CR2
Reporter: Matt Wringe
Assignee: Scott M Stark
Attachments: testsar.tar.gz
In JBoss AS 5, any jars placed in the lib directory of a sar are not loaded and results in a class not found exception. The classes are loaded if the jar is placed in the root directory of the sar.
On previous versions of JBoss AS, the classes would be loaded from either location. This prevents sars that would have worked on JBoss AS 4 to fail on JBoss AS 5.
Steps to reproduce:
1) take zip attached to this report.
2) deploy test-in-lib.sar to JBoss AS 5. The sar will not deploy and will fail with a classNotFoundException
3) deploy test-in-lib.sar to JBoss AS 4, the sar will deploy without issue.
test-in-root.sar will work on both versions of JBoss. The only difference between these sars is the location of the jar.
--
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
11 years, 10 months
[JBoss JIRA] (AS7-3854) MimeMappingAdd and MimeMappingRemove don't affect the runtime
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-3854:
-------------------------------------
Summary: MimeMappingAdd and MimeMappingRemove don't affect the runtime
Key: AS7-3854
URL: https://issues.jboss.org/browse/AS7-3854
Project: Application Server 7
Issue Type: Bug
Components: Domain Management, Web
Reporter: Brian Stansberry
Assignee: Tomaz Cerar
Fix For: 7.1.1.Final
While reviewing https://github.com/jbossas/jboss-as/pull/1549 I see that MimeMappingAdd and MimeMappingRemove just update the model but have no effect on the runtime services. If context.isNormalServer() == true, they should either impact a runtime service or put the server into reload-required.
Note that the current behavior may make sense during boot if the overall subsystem design has a parent resource adding a Stage.RUNTIME handler that reads child resources and uses their state to set up runtime services. But it's definitely not correct if these operations are performed independently.
As part of processing pull request 1549 I'll add TODO comments in these classes referencing this JIRA.
--
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
11 years, 10 months
[JBoss JIRA] (AS7-4858) jconsole.sh does not start on Mac OSX
by Jim Tyrrell (JIRA)
Jim Tyrrell created AS7-4858:
--------------------------------
Summary: jconsole.sh does not start on Mac OSX
Key: AS7-4858
URL: https://issues.jboss.org/browse/AS7-4858
Project: Application Server 7
Issue Type: Feature Request
Components: Server
Reporter: Jim Tyrrell
Assignee: Jason Greene
jconsole.sh does not work on Mac OSX:
Jim-Tyrrells-MacBook-Pro-2:bin jimtyrrell$ ./jconsole.sh
CLASSPATH /lib/jconsole.jar:/lib/tools.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/remoting3/remoting-jmx/main/remoting-jmx-1.0.3.CR1-redhat-0-todo.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/remoting3/main/jboss-remoting-3.2.4.GA-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/logging/main/jboss-logging-3.1.0.GA-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/xnio/main/xnio-api-3.0.3.GA-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/xnio/nio/main/xnio-nio-3.0.3.GA-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/sasl/main/jboss-sasl-1.0.0.Final-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/marshalling/main/jboss-marshalling-1.3.13.GA-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/marshalling/river/main/jboss-marshalling-river-1.3.13.GA-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/as/cli/main/jboss-as-cli-7.1.1.Final-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/staxmapper/main/staxmapper-1.1.0.Final-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/as/protocol/main/jboss-as-protocol-7.1.1.Final-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/dmr/main/jboss-dmr-1.1.1.Final-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/as/controller-client/main/jboss-as-controller-client-7.1.1.Final-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/threads/main/jboss-threads-2.0.0.GA-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/as/controller/main/jboss-as-controller-7.1.1.Final-redhat-1.jar
Exception in thread "main" java.lang.NoClassDefFoundError: sun/tools/jconsole/JConsole
Caused by: java.lang.ClassNotFoundException: sun.tools.jconsole.JConsole
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
--
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
11 years, 10 months
[JBoss JIRA] (AS7-5110) Destructive Change to the .xml file ie Losing comments in the file.
by Jim Tyrrell (JIRA)
Jim Tyrrell created AS7-5110:
--------------------------------
Summary: Destructive Change to the .xml file ie Losing comments in the file.
Key: AS7-5110
URL: https://issues.jboss.org/browse/AS7-5110
Project: Application Server 7
Issue Type: Feature Request
Components: Console
Affects Versions: 7.1.2.Final (EAP)
Reporter: Jim Tyrrell
Assignee: Heiko Braun
Run the following commands with a clean EAP install:
./domain.sh --host-config=host-master.xml
Edit the host-slave.xml file, by changing the default 9999 port to 29999 as shown:
<native-interface security-realm="ManagementRealm">
<socket interface="management" port="${jboss.management.native.port:29999}"/>
</native-interface>
Start up the host slave:
./domain.sh --host-config=host-slave.xml -Djboss.domain.master.address=127.0.0.1
Create a generic admin user of your choosing.
Look at the host-slave.xml file and note this section:
<!-- server-two avoids port conflicts by incrementing the ports in
the default socket-group declared in the server-group -->
Add in an auto-start="true" flag as shown:
<server name="server-two" group="other-server-group" auto-start="true">
<!-- server-two avoids port conflicts by incrementing the ports in
the default socket-group declared in the server-group -->
<socket-bindings port-offset="150"/>
</server>
Change in the console auto start to false:
Now more the contents of the host-slave.xml file:
<server name="server-two" group="other-server-group" auto-start="false">
<socket-bindings port-offset="150"/>
</server>
Note your comments are gone.
Imagine I was an admin for whatever reason and I had commented out a section and it was now removed. This is kind of bad.
--
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
11 years, 10 months