Its for using the JMS client with the broadcast bits from an ActiveMQ
5.x broker (or alternatively by watching a files contents) so not
really what you wanted.

On 20 September 2017 at 15:22, Thomas Hartwig <[email protected]> wrote:
> Hi Ted,
>
> it looks like, there is already something provided, this is probably what I
> want, I will check deeper if it applies for my use:
>
> https://qpid.apache.org/releases/qpid-jms-0.24.0/docs/index.html#discovery-configuration-options
>
> The question remains if the dispatcher is supporting this also. (I want to
> use only the dispatcher without any brokers)
>
> Thomas
>
>
> On 20.09.2017 14:41, Ted Ross wrote:
>>
>> Hi Thomas,
>>
>> Thanks for the note.  We've heard several requests for similar discovery
>> features, but specific requirements have been somewhat elusive.  The
>> EnMasse project (Messaging as a service in Kubernetes/OpenShift) has a
>> platform-specific solution to this problem.  Other environments would
>> require other solutions.
>>
>> Are you suggesting that a protocol be established for "finding my closest
>> messaging access point"?  Perhaps something similar to DHCP or ARP.  For
>> example, the AMQP clients could be modified to send a broadcast query that
>> any listening Dispatch Router (or broker) would respond to.  The client
>> would then use the hostname/IP-address from the first response it receives
>> to establish an AMQP connection.
>>
>> Other possibilities include extensions to DNS (similar to MX records for
>> email) or DHCP (adding the host's configured messaging access point).
>>
>> -Ted
>>
>> On Wed, Sep 20, 2017 at 4:27 AM, Thomas Hartwig <[email protected]>
>> wrote:
>>
>>> Hi,
>>>
>>> I really like the dispatch router project. I only have one wish remain:
>>> Is
>>> it somehow possible to "detect" a router present in the local network?
>>> Once
>>> a router is detected it can be used to establish high level connections
>>> by
>>> any client without the need of configure it to a static address.
>>> I think of something like broadcast or multicast announcement mechanism.
>>> Did you ever consider a solution for this?
>>>
>>> Thanks
>>> Thomas
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to