activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sridhar Komandur (JIRA)" <>
Subject [jira] Commented: (AMQ-920) Two TCP connection requirement for bidirectional message flow ...
Date Thu, 14 Sep 2006 14:22:23 GMT
    [ ] 
Sridhar Komandur commented on AMQ-920:

Jon brought up another important use case related to  brokers outside the Firewall  (perhaps
in the DMZ) ...

---------- Forwarded message ----------
From: Jon <>
Date: Sep 14, 2006 6:34 AM
Subject: Re: Firewall

I gave it a vote.

This problem should be a quite common problem i would guess. Accessing a
broker behind firewall would simply not be done without reusing the
connection from the broker behind firewall. So if a broker outside a
firewall detects brokers inside the firewall (by the inside connecting to
the outside), it should make the broker inside the firewall available to all
other brokers on the outside-network. So if it was possible to build a
network of brokers and address them by an unique name, and let all brokers
know of everybody - i quess the problem was solved.

Since my network topology often is a mix of firewalls i have no control over
and them i have control over, i really need something like this.

Anyone who knows of a JMS project supporting this?


> Two TCP connection requirement for bidirectional message flow ...
> -----------------------------------------------------------------
>                 Key: AMQ-920
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Improvement
>          Components: Connector
>            Reporter: Sridhar Komandur
> We noticed the following during our testing ....
> When a broker A establishes connection to broker B, the message flow is unidirectional
from A to B.
> This is a an issue for us: For example, consider brokers associated with business critical
services X and Y. There are many secondary services that either monitor/feed off of the messages
coming from them.
> A FOO service would like to process messages going from X to Y. So in FOO's broker configuration
we add X's name. However,  messages are not going to flow from X to FOO, till X initiates
a connection to FOO. It may not be desirable/possible to change business critical brokers'
configuration for usage scenarios like this.
> TCP is bidirectional and asymmetry at connection establishment should not be translated
to the higher level network connector. Is there a fundamental need/justification for this
design that I may not be aware of ? Otherwise I would like to explore other design options.
> Thanks
> Regards
> - Sridhar Komandur

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message