|
Hello, Jonathan.
What provokes that disgusting effect is that the
new server's URL is different from the old one's. Unfortunately, the only
solution I know for it requires that all client computers resolve the old
server's name as the new server's IP. 8-S Then, the server connection details
should be restored to the old ones, so that clients think they are still
connecting to the old one, though the repositories are in the new
server.
I now this explanation is a bit messy, so I'll try
and set an example. Imagine your old server had IP 10.0.0.7 and was called oldserver. URLs defined in the clients looked like http://oldserver:8080/sourcejammer/servlet/rpcrouter.
The new server has IP 10.0.0.15 and it's called
newserver (and therefore the URL is something
like http://newserver:8080/sourcejammer/servlet/rpcrouter).
If oldserver does
not exist anymore, you may rename the new one as oldserver, and restore all the URLs to their previous
value, and then everything should work fine again (except for the files that
have been managed with the new URL, but these are negligible compared to the
amount of those which have not).
Renaming the servers is also a simple shortcut when
possible. However, if that cannot be done because they are used in multiple
other contexts, then you'll have to force the client computers to believe they
are working with the old one when they in fact use the newer one. To achieve it,
you must define the IP in the hosts file (/etc/hosts for Unix, C:\WINNT\system32\drivers\etc\hosts for Windows). It's
a plain text file where you must add a line like the following:
10.0.0.15 oldserver
From now on, everytime you use a URL with oldserver, you'll be accessing newserver, whose IP is
10.0.0.15. So,
clients using the old URL will think it's the same repository and will check the
files update correctly.
The one drawback of this is that, in those
computers, you won't be able to use oldserver
as the name for the server at 10.0.0.7. The computers where the hosts file
has not been modified can indeed still use the old name, and often they are
a set different from the SJ clients and there's no problem with that. But if the
SJ clients need the old server for other purpuses as well, then there's a
conflict, and all this stuff will not suit you at all. I have no nice fix for
it, sorry.
Well, I hope this is useful some way or another to
you,
Albert.
|
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ SourceJammer-users mailing list SourceJammer-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sourcejammer-users
