Bug 1138112

Created attachment 934270 [details]
coreb.xml

Attached the core bridge configuration

I'm setting flags for EAP 6.4.0 so we don't loose this from focus. If this is required to have in EAP 6.2.x.CP or 6.3.x.CP then new bz must be created and discussed with PM.

Hi Mirek and Tyronne,

I wonder if this is a valid case. My reason is that this test uses a core bridge that points to a configured jms source queue, which seems not right because hornetq core stuff shouldn't be depending on jms stuff.

I think the correct test is that the core bridge only references core queues, thus, for this test to be valid, you need a core queue "jms.queue.A" configured.

What's your thoughts?


Howard

Hi Howard,

I've taken a look at attached xml and there are used core name of the queues in configuration of core bridge:

...
<bridge name="notification-queue-bridge">
   <queue-name>jms.queue.A</queue-name>
   <forwarding-address>jms.queue.B</forwarding-address>
...

Thanks,
Mirek

I think you've just pointed out a usability problem. You're right that HornetQ is using core names for configuration of core bridges and in EAP 6 queues are defined like:

<jms-queue name="A">
   <entry name="queue/A"/>
   <entry name="jboss/exported/queue/A"/>
</jms-queue>

and bridges like:
...
<bridge name="notification-queue-bridge">
   <queue-name>jms.queue.A</queue-name>
   <forwarding-address>jms.queue.B</forwarding-address>
...

It's not intuitive for admins/users to use "jms.queue.A" in configuration of core bridge when name of the queue was defined just "A".

Hi Mirek,

Any jms queue will cause a corresponding core queue to be deployed, its name is just the jms queue name prefixed with jms.queue. The problem is that core bridge will always start before any jms artifacts are deployed.

The core bridge refers to a core queue, not a jms queue. For it to work you need add a core queue in the config, i.e.

<core-queues>
    <queue name="jms.queue.A">
        <address>jms.queue.A</address>
    </queue>
</core-queues>


Thanks
Howard

Hi Howard,

I understand. But with this we force users to have one destination twice in the configuration if they wish to have one queue for core bridge and also to have defined JNDI entry for JMS clients to lookup it in <jms-queue>. We should try to simplify it. 

Thanks,
Mirek

Core bridges require core queues.  A JMS queue uses a core queue under-the-covers but it's defined differently because its use-case is different from a core queue.  If the user doesn't want to define a core queue which corresponds to their JMS queue to use with a core bridge then they can simply use a JMS bridge.

+1 Justin.

Mirek we can't make core-bridge depends on jms stuff. Core bridge works with core queues, Jms bridge works with jms queues.

Howard

Ok, I understand that making core bridge dependent on JMS stuff is not the right way. But is it possible to retry deployment of the core bridge so it succeeds eventually? Similarly as it's retried deployment of JMS bridges.

Mirek

Hi Mirek,

Yes it is possible, but as I said, the overall design is that the core has nothing dependent on jms. Rather the jms depends on core for its functionalities. So the core services are starting first and then JMS services.

So if we want the core bridge to retry, we need to allow JMS service to be activated even if the core service (bridge) is not fully started yet, which means we will have core to be dependent on jms, which I don't think is a good idea.


Howard

Hi Howard,

at this moment if core bridge fails to be deployed then jms service starts anyway. I don't think that with retrying core bridge we'd make it dependent on jms.

Mirek

Hi Mirek,

Core bridge does have retry in place, but the checking of the source queue is done before the bridge is started. This is because if the bridge find its source queue is not there, there is no point to retry for that purpose.

Howard

Hi Howard,

would it be possible to retry deploy of core bridge when something in hornetq core changes? In this case jms queue is deployed later and causes that core queue is deployed. Can this trigger hornetq bridge redeployment? We would bind redeployment of core bridge to change in hornetq core.

Mirek

Core bridges should be startes after the JMS queue is crested. Although um not sure why it's hunging

Hi Clebert,

I didn't see any specific hanging in the test, it may just appears so as the bridge wan't get deployed due to this exception.

Howard

I will close this as not a bug. If the user wants a core-bridge, he can just define the core-queue