[AG-DEV] Parallelize some of the functions of the Start-Up for the Venue Client

[Andrew A Rowley]

Hi,

A lot of this problem is caused by the fact that no one can currently run their own bridge registry and so the registry at ANL is being used by everyone in the world, regardless of if their bridge is accessible to the world or not.  As you say, there is also a loop in the code that does not exit until every bridge has responded to a ping request - note that this is tried through https first, then using the "ping" command if this fails.

I think there is a "RegistryPeer.py" class in the "Registry" sub folder of the AccessGrid python library - I am fairly sure that this is what you need to use to run your own registry and so isolate your bridge from the rest of the world.  What I don't know is if you can then configure your server or client to use this registry without hacking the code.

Andrew :)

============================================
Access Grid Support Centre,
RSS Group,
Manchester Computing,
Kilburn Building,
University of Manchester,
Oxford Road,
Manchester, 
M13 9PL, 
UK
Tel: +44(0)161-275 0685
Email: Andrew.Rowley at manchester.ac.uk 

> -----Original Message-----
> From: owner-ag-dev at mcs.anl.gov [mailto:owner-ag-dev at mcs.anl.gov] On Behalf
> Of Jason Bell
> Sent: 04 September 2006 07:10
> To: Rhys Hawkins
> Cc: ag-dev at mcs.anl.gov
> Subject: RE: [AG-DEV] Parallelize some of the functions of the Start-Up
> for the Venue Client
> 
> G'day Rhys and everyone
> 
> Another thing to consider, which may also be problematic, is that as
> more and more people start to use AG 3 (Which is a good thing), they are
> creating their own bridges which is compounding the issue....  The more
> bridges are running, the slower the startup time is.
> 
> 1 second start-up time, now it would be nice to have that again :-)
> 
> On another note, one thing that I would also like to be able to do, is
> configure a bridge specifically for a single VenueServer???  That would
> then hopefully reduce bridge congestion for everyone's VenueServer, in
> which I may only want it running for my VenueServer and no-one else's.
> Just a thought anyway!
> 
> Cheers,
> Jason.
> 
> -----Original Message-----
> From: owner-ag-dev at mcs.anl.gov [mailto:owner-ag-dev at mcs.anl.gov] On
> Behalf Of Rhys Hawkins
> Sent: Monday, 4 September 2006 3:45 PM
> To: Jason Bell
> Cc: ag-dev at mcs.anl.gov
> Subject: Re: [AG-DEV] Parallelize some of the functions of the Start-Up
> for the Venue Client
> 
> 
> Hi Jason,
> 
> I've noticed the same thing as I've been doing a lot of testing recently
> that has involved restarting the VenueClient. The slow part (for me at
> least) is sorting the bridges which I don't need for my testing so I've
> commented out that bit and the VenueClient starts up in less than a
> second.
> 
> I've commented out line 125 in AccessGrid/Registry/RegistryClient.py,
> ie:
>     #self.bridges = self._sortBridges(maxToReturn)
> I don't know whether this will help your colleague or not. It certainly
> makes things quicker for me. If you're just testing a local bridge then
> you could just stick you local bridge description in the beginning of
> the
> list to fake the sort. Although this is just hacking for testing
> purposes
> and doesn't solve the actual problem.
> 
> The thing that was killing me was a bridge was non-existent/down and the
> socket had to timeout (ie number of minutes) before the sort could
> complete.
> If a bridge can't be contacted after a small number of seconds then it
> probably isn't going to be much good for realtime conferencing so
> perhaps
> another solution (as well as parallelizing or instead of) would be to
> prematurely terminate any "ping" that is taking too long.
> 
> Cheers,
>     Rhys
> 
> On Mon, 04 Sep 2006 12:42:47 +1000
> Jason Bell <j.bell at cqu.edu.au> wrote:
> 
> > G'day all
> >
> > Not sure if this is the list I should be sending this email too, but I
> > was just wondering if there is a way to parallelize some of the
> > functions of the Start-Up for the Venue Client.
> >
> > The reason why I suggest this is that we currently have someone that
> has
> > been doing some testing, running their own unicast bridge.
> > Unfortunately whenever they run their unicast bridge, it causes the
> > startup of the VenueClient to take over 5 minutes (Maybe even
> longer)...
> >
> >
> > What I really like to see is things like the loading of the bridge
> > conf's and stuff to be made separate.  Is there any reason why the
> > VenueClient cannot start without having loaded the bridges
> > beforehand????  Other than having the bridges listed within the
> bridges
> > menu, I cannot see any reasons why.
> >
> > Making the user wait an extremely long time is not really a good thing
> > and will cause people to simply stick with AG2.
> >
> > It should be noted, that this problem doesn't occur if booting with AG
> > 3.0.1, only AG 3.0.2.
> >
> > Anyway, that's my 2 cents worth.
> >
> > Cheers,
> > Jason.
> >
> > --------------------------------------------
> >
> > Jason Bell, B.I.T.
> > B. Info. Tech. (Honours) Student
> >
> > Network Engineer
> > Information Technology Division
> > Central Queensland University
> >
> > High Performance Computing Support Officer
> > Central Queensland University
> >
> > E-mail : j.bell at cqu.edu.au
> > Phone : 07 4930 9229
> >
> > --------------------------------------------
> >
> > Patience is a virtue.
> >
> > But if I wanted Patience,
> > I would have become a Doctor.
> >
> > --------------------------------------------
> >
>