In fact I had problems with our AG3.1 bridge server being able to get its RegistryClient connected to the peers repository. However this seemed to be a temporary probelm has gone away now, which makes it even harder to track down. I just realised that at the same time while I had the problem, after doing a bridge cache update, around 80% of the bridges were unreachable, which seemed for me not to be a coincidence.
Cheers, Michael Adam Carter schrieb: > Hi Chris (cc list), > > Thanks for your reply. I can see now the difference between the web > service that returns the bridge list and the list of bridges itself, > so the fact that the list only has one entry no longer worries me. > > However, is it possible that bridges are trying to add their entry to > the Argonne server, failing for some reason (possibly due to the way > that the server at Argonne has been configured?), and then not > launching properly themselves because of this? This would explain the > behaviour that I've had reported to me that bridges will not go back > up when they've gone down... If others who are using a bridge have not > noticed the problem, then I guess it's some other problem with the > bridge, but I thought I'd check first. I see that Michael M has > restarted his bridge, apparently with no problems, so I assume that > it's something at the other end... > > Cheers, > > Adam > > > > Christoph Willing wrote: >> >> On 16/06/2009, at 11:07 PM, Adam Carter wrote: >> >>> >>> Hi, >>> >>> Recently I've noticed that a couple of unicast bridges I've tried to >>> contact have been unavailable. When I spoke to Michael Braitmaier in >>> Stuttgart he said that his bridge server was not restarting because >>> it couldn't access the peers.txt list on the Argonne Server. >>> Checking in the Venue Client in my list of bridge servers, nearly >>> all of them show up as unreachable. I can still connect to those >>> which are still up and running at their original addresses, but I >>> suspect this is also related to the peers file. When I put the peers >>> file url into a browser it shows only one entry, namely that of >>> Argonne. Is this deliberate, or an oversight? >> >> >> Adam, >> >> The peers.txt will normally contain just a single entry consisting of >> the name of a machine and the port at which a particular web service >> is running. Bridges register with that web service when they start up >> and, when queried the right way, that web service returns the list of >> bridges that have registered. >> >> In short, the minimal content of peers.txt is not the reason why some >> bridges end up being unreachable. >> >> >> chris >> >> >> Christoph Willing +61 7 3365 8316 >> QCIF Access Grid Manager >> University of Queensland >> >> > >
