[JBoss JIRA] Created: (JBESB-659) 2 JBossAS instances cannot share the same JBossMQ service for JMS gateways if JMS is installed
by James Williams (JIRA)
2 JBossAS instances cannot share the same JBossMQ service for JMS gateways if JMS is installed
----------------------------------------------------------------------------------------------
Key: JBESB-659
URL: http://jira.jboss.com/jira/browse/JBESB-659
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: JBossAS 4.2GA, JBossESB - Head as of 07/05.2007.
Reporter: James …
[View More]Williams
Assigned To: Mark Little
I am trying to get 2 JBossAS instances to share the same JMS Server for gateways. There's a lot of moving parts, but I'll try to explain the configurations:
1. JBossAS 4.2.0-GA default config with all .ESB archives, minus the quickstart_helloworld.esb. This server is started using the "-b localhost -c node0" startup parameters.
2. JBossAS 4.2.0-GA default config with "jbossesb.sar" and "quickstart_helloworld.esb". All other .ESB archives are removed and my goal is to use the JMS service in server #1 for gateways/listeners. The quickstart_helloworld.esb archive in this server has its own gateway/listener queues. This server is started using the "-b 192.168.200.1 -c node1" startup parameters.
3. JBossAS 4.2-GA default config with "jbossesb.sar" and "quickstart_helloworld.esb". All other .ESB archives are removed and my goal is to use the JMS service in server #1 for gateways/listeners. The quickstart_helloworld.esb archive in this server has its own gateway/listener queues that are different from the gateways/listeners in #2. This server is started using the "-b 192.168.200.2 -c node2" startup parameters.
I'm not having any problems with nodes #2 and #3 sharing the JMS service that's running on #1, so long as JBossMQ isn't installed on node #2 or #3. If JMS is installed, quickstart_helloworld.esb archive fails to deploy on both #2 or #3. It complains that the Gateway queue does not exist, but it most certainly does. Worse yet, when I run the SendJMSMessage test class, it cannot find the queue either. It's as if jbossesb.sar is somehow screwing up all jndi lookups for the queue.
There are a couple things I've done to try to rule out other potential root causes:
1. I tried running #1, #2, #3 w/out any .ESB archives or jbossesb.sar to verify that a JMS client can indeed drop requests into queues on all servers. To me, this validates that 3 unclustered JBossAS instances can each have their own JMS queues that are all accessible on a single machine, like my test environment, just by having the app servers bootstrapped by unique config and ip address. I was worried that the JMS service might be the culprit, but that doesn't appear to be the case.
2. I removed JMS from #2 and #3 to verify that the queues are setup correctly on #1 and to verify that #2 and #3 can indeed share the same JMS service provided they do not have JMS running themselves.
--
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
[View Less]
14 years, 10 months
[JBoss JIRA] Created: (JBESB-476) Make action, listener etc configuration setting by setter method the default
by Tom Fennelly (JIRA)
Make action, listener etc configuration setting by setter method the default
----------------------------------------------------------------------------
Key: JBESB-476
URL: http://jira.jboss.com/jira/browse/JBESB-476
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 4.0
Reporter: Tom Fennelly
Assigned To: Mark Little
Fix For: 4.2
We …
[View More]currently configure everything by constructor. This is not great for a number of reasons:
1. It can't be compile time validated.
2. Not as "obvious" to someone developing against the API. If in an interface, their IDE (or at least compiler - if using a stone ax) will complain immediately that they're not implementing the interface correctly.
3. Makes our code a little bit more complicated re the reflection code that needs to be implemented.
So I suggest making the interface (that all these things implement) contain a setter method that takes the config. The mandate on the implementation is that they contain a public default constructor.
--
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
[View Less]
14 years, 10 months