[
https://issues.jboss.org/browse/JBAS-8895?page=com.atlassian.jira.plugin....
]
Jack van Ooststroom commented on JBAS-8895:
-------------------------------------------
I also tried the snapshot and verified things work now for the stand-alone case. However,
I also wanted to verify the cluster case, as we need to support that as well, but I
encounter the following warning message:
10:09:27,053 WARN [org.hornetq.core.cluster.impl.DiscoveryGroupImpl] There are more than
one servers on the network broadcasting the same node id. You will see this message
exactly once (per node) if a node is restarted, in which case it can be safely ignored.
But if it is logged continuously it means you really do have more than one node on the
same network active concurrently with the same node id. This could occur if you have a
backup node active at the same time as its live node.
nodeID=38438e5b-6bec-11e0-a63d-001a6411d7e1
I understand that the nodeID normally gets generated when first starting a node. I
downloaded the bundle separately on each node and started them individually. It looks
like they both use the same nodeID. I suspect this nodeID
(38438e5b-6bec-11e0-a63d-001a6411d7e1) to be part of the jboss-6.1.x.zip archive, as on
each machine I download this bundle to, the nodeID is always the same. This prevents me
to confirm the fix in a cluster environment. Is there a way I can enforce the
regeneration of the nodeID?
Can't connect to JMS before server has started up completely
------------------------------------------------------------
Key: JBAS-8895
URL:
https://issues.jboss.org/browse/JBAS-8895
Project: Legacy JBoss Application Server 6
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: JMS (HornetQ)
Affects Versions: 6.0.0.Final
Environment: JBoss 6.0.0.Final with HornetQ configured
Reporter: Jack van Ooststroom
Assignee: jaikiran pai
Fix For: 6.1.0
Attachments: jmstest.war
It seems that with JBoss AS 6.0.0.Final I can't connect to JMS before the application
server itself has started up completely. I'm using the InitialContext approach as I
can't use Message Driven Beans in the project.
I created a JMS Topic in [jboss-home]/server/default/deploy/hornetq/hornetq-jms.xml as
follows:
<topic name="MyTopic">
<entry name="/topic/test"/>
</topic>
Next I'm trying to connect to JMS from my JMSServlet's init(ServletConfig)
method, but that seems to fail when executing the JMS detection on the original thread
(that is the thread supplied by the application server) as follows:
Unable to validate user: null for check type CREATE_NON_DURABLE_QUEUE for address
jms.topic.MyTopic
I'd prefer not having to specify the user/password, but even if I do it fails in a
similar fashion:
Unable to validate user: guest for check type CREATE_NON_DURABLE_QUEUE for address
jms.topic.MyTopic
When I do the detection of JMS on a seperate thread it eventually seems to work, as long
as the application server started up completely. However, timing is then a bit
undeterministic. When running this test on earlier versions of JBoss AS, namely 5 and 4,
or other application servers the detection seems to succeed on the first try on the
original thread.
Why does JBoss AS 6.0.0.Final behave differently? Is there some configuration I am
missing? Is this a potential bug?
I'll attach my JMS Test application which tries to connect to JMS using 6 different
strategies:
* On original thread
* On original thread after sleep
* On spawned thread with await/signal
* On spawned thread with await/signal after sleep
* On spawned thread without await/signal
* On spawned thread without await/signal after sleep
The source is included in the jmstest.war file.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira