[
https://issues.apache.org/jira/browse/OPENEJB-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13294261#comment-13294261
]
Andy Gumbrecht commented on OPENEJB-1838:
-----------------------------------------
The mechanism is as follows:
1. The server listens on the defined multicast channel for a client crafted
packet - A request for server information.
2. A client sends one (or more) request pulse(s) on the same channel - In
reality only one pulse is sent per remote InitialContext connection, but
multicast is not guaranteed. In load tests I have never seen a pulse dropped.
Clients can try/catch calls to 'new InitialContext(properties).lookup("EJB");'
as many times as required. It may be wise to introduce a 'retry' option.
The default discovery timeout is a conservative 250ms - This can be defined in
the multipulse URI - p.put(Context.PROVIDER_URL,
"multipulse://239.192.3.2:7142?group=YourGroupName&timeout=50"); - whereby 50
is the minimum. This 50ms is based on an in-house test where 11 multihomed
servers are consistently discovered (have all sent a response) within 35ms or
less. Therefore, 250ms is very unlikely to fail and is also negligible when
taken in the scope of a client login for example.
If no group is specified then 'default' is assumed. The wild-card symbol '*'
indicates 'all' groups, but is only really useful for testing.
3. Listening servers accept a client request and respond on the defined
multicast channel with a crafted packet. This packet contains the discovery
URI/s and all known hosts that the server itself is able to determine (This is
specifically designed to cope with multihomed systems that have several,
possibly dynamic, IP-Addresses).
4. The client parses the server response(s) and attempts a connection on all
server returned hosts until successful - Bad hosts are discarded, and good
connections are pooled.
That's it. Multicast traffic is kept to a bare minimum and only occurs as
required / initiated.
The negative aspect is that client firewalls must be configured to allow
multicast, but if server discovery via multicast is the requirement then this
is usually already the case.
> Add 'MultiPulse' discovery - An alternative multicast discovery option
> ----------------------------------------------------------------------
>
> Key: OPENEJB-1838
> URL: https://issues.apache.org/jira/browse/OPENEJB-1838
> Project: OpenEJB
> Issue Type: Improvement
> Components: server
> Affects Versions: (not version related)
> Environment: All
> Reporter: Andy Gumbrecht
> Assignee: Andy Gumbrecht
> Priority: Trivial
> Labels: MultiPulse, Multicast
> Fix For: (trunk/openejb)
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Add a multicast discovery feature that does not require a constant heartbeat.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
