Article:
 |
|
jRendezvous: Java and Rendezvous Working Together
|
| Subject: |
|
server patch broke jrendezvous? |
| Date: |
|
2003-10-22 01:24:12 |
| From: |
|
sethladd1
|
Response to: server patch broke jrendezvous?
|
|
Hi,
It's quite possible that the "patch" I provide only does handle that one case. I'm glad you found a way around it. Honestly I haven't approached this topic in a long time. I hope one day someone is able to collect all these patches and knowledge and release a new version of the library. It looks like people find it useful!
Thanks,
Seth
|
Showing messages 1 through 2 of 2.
-
server patch broke jrendezvous?
2003-10-22 15:14:37
anonymous2
[View]
-
server patch broke jrendezvous?
2003-10-23 00:56:18
anonymous2
[View]
http://foo.example.com
rather than
http://seth-ladds-computer.local./index.html
however I'm not sure this is a useful change for two reasons:
(a) mod_apache_rendezvous does not exhibit this behaviour, so why
should tomcat try to do something different?
(b) and more importantly any browser capable of doing rendezvous
service discovery should be quite able to handle a URL
of the second type. you say on page one of the article:
"While this server name resolves to a physical IP address,
clients should never cache that address. Rendezvous works so
well because services may move around on the network, even
changing IP addresses. Clients should cache the Service
Instance Name instead, allowing the service the flexibility
of movement."
from that I understand that the _correct url for this service
is the latter type, as it will still be correct even if the
service is no longer available on foo.example.com. I guess
the argument could be made that seth-ladds-computer might
not always be valid either, but one would think that if you've
found the resource via rendezvous, you continue to locate it
in that manner, and if you've found the resource via some other
means then you should stick with that access type.