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

[Jason Bell]

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.
> 
> --------------------------------------------  
>