perfsonar development work

[Szymon Trocha <>]

Nina Jeliazkova pisze:
> > > The interface is modest on purpose (currently no support for event types
> > > and service types). At this moment, one can query for a network element
> > > and retrieve the services, responsible for it (if available). 
> > What is the purpose of "Select service addresses" window here?
> Well, it is the default implementation from the parent class and no real
> use here, will remove it.    It could be replaced with an option to
> select an alternative location for gls.root.hints.

Indeed. That would be a good idea to view (select from) the content of 
hints file

> > > It turned out the old LS client jars , distributed with the previous
> > > releases of perfsonarUI (<= 0.15) has a a bug, chopping the last symbol
> > > of the network element (e.g. IP address) and thus sending a wrong
> > > query.  The current LS client jars are compiled from the source
> > > available at SVN trunk.
> > > http://anonsvn.internet2.edu/svn/perfsonar/trunk/perfsonar_java-lsclient-api
> > >
> > > http://anonsvn.internet2.edu/svn/perfsonar/trunk/ps-mdm-lsclient-impl
> > >
> > > If stable builds of LSClient API is available elsewhere, I would
> > > appreciate a pointer. 
> > Is this something what you would require or it would make your work
> > easier?
> The latter :)  The source at trunk might not be bug free all the time
> and it will be good to have stable ls client jars at the repository anyway.

ok
So that's a clear request to Krzysztof

> > > Also, a log file is attached ,resulting from querying  for
> > > 150.254.185.146 . You might notice PIONIER gLS service doesn't respond
> > > (connection refused) and thus it is not possible to find network
> > > elements, registered under PIONIER gLS.  Yet, the response is somewhat
> > > undeterministic, sometimes list of services are returned, sometimes not. 
> > Let's clarify this.
> > - There was only one GN2 gLS under ls.perfsonar.pionier.net.pl
> The PIONIER gLS is retrieved from 
> http://www.perfsonar.net/gls.root.hints . Could you confirm it runs on 9990?

Yes, it does

[...]
> > - Under the above IP address was test server which is not working now.
> > To be honest I don't remember there was gLS there but probably not
> Ah, ok, it is from an old test setup indeed.  

Yes, could be from some testing

> > - PIONIER *hLS* is running under
> > http://ls.perfsonar.pionier.net.pl:8180/geant2-java-xml-ls/services/LookupService
> It should be retrieved automatically with the discovery process, if
> PIONIER gLS is running

Yes, it's already visible but doesn't contain all information until 
synchronisation process ends.

> > Did you try with any other address from Internet2 domain?
> Yes, several addresses.
>
> Today experiment with the updated views Jason send, is as follows:
>
> http://dc211.internet2.edu/cgi-bin/perfSONAR/view.cgi?hls=http://p-mdm.ps-lhcopn.fnal.gov:8080/geant2-java-xml-ls/services/LookupService
>
> According to the tree view, 192.16.166.26 is served by 
> http://p-mdm.ps-lhcopn.fnal.gov:8080/geant2-java-rrd-ma/services/MeasurementArchiveService 
> ( resolves to 131.225.204.1 ) and I would expect this service to appear
> in the results. Unfortunately , this is not the case - could anyone
> please provide an explanation?  I assume the tree view is up to date.
>
> First try:
> 40963 ms
> Query
> urn:ogf:network:node=192.16.166.26
> Services
>         http://216.255.240.2:8085/perfSONAR_PS/services/pSB
>         http://rrdma.net.internet2.edu:8080/perfSONAR_PS/services/IUsnmpMA
>         http://rrdma.net.internet2.edu:8080/perfSONAR_PS/services/snmpMA
>         http://ps3.es.net:8080/perfSONAR_PS/services/snmpMA
>         http://frown.es.net:8085/perfSONAR_PS/services/pSB
>         http://perfsonar-1.t2.ucsd.edu:8085/perfSONAR_PS/services/pSB
>
> Second try:
> 41670 ms
> Query
> urn:ogf:network:node=192.16.166.26
> Services
>         http://rrdma.net.internet2.edu:8080/perfSONAR_PS/services/IUsnmpMA
>         http://rrdma.net.internet2.edu:8080/perfSONAR_PS/services/snmpMA
>         http://frown.es.net:8085/perfSONAR_PS/services/pSB
>         http://perfsonar-1.t2.ucsd.edu:8085/perfSONAR_PS/services/pSB
>         http://ps3.es.net:8080/perfSONAR_PS/services/snmpMA
>         http://216.255.240.2:8085/perfSONAR_PS/services/pSB
>
> Third try:
> 433 ms
> Query
> urn:ogf:network:node=192.16.166.26
> Services
>
> Fourth try:
> 3518 ms
> Query
> urn:ogf:network:node=192.16.166.26
> Services
>
>
> Fifth try:
> 3518 ms
> Query
> urn:ogf:network:node=192.16.166.26
> Services

This is very strange why the results are not the same

> And on subsequent attempts no services were retrieved as well
>
> Obviously, we need to think of a systematic testing approach.
>
>
> > I just run query with this playground using 150.254.185.146 and got:
> > 26344 ms
> > Query
> > urn:ogf:network:node=150.254.185.146
> > Services
> >     http://216.255.240.2:8085/perfSONAR_PS/services/pSB
> >     http://ps3.es.net:8080/perfSONAR_PS/services/snmpMA
> >
> > Strange. You mentioned you weren't able to find network elements.
> > Moreover this is strange because PIONIER hLS doesn't contain the
> > aforementioned IP address so it couldn't be registered anywhere (even
> > by mistake) and above pS services are for sure not from PIONIER domain :)
> The response is non-deterministic - I guess this is due to summarisation
> mechanism and timeouts. 
>
> I would indeed not expect to find anything for  an IP address which is
> not registered  anywhere, but this happens all the time (again due to
> simmarisation).

Agree. I think we highlighted this problem earlier.

This needs more in depth testing together with LS and maybe API 
developers which your Playground will ease much.

regards,
--
Szymon Trocha

Poznan Supercomputing & Netw. Center ::: NETWORK OPERATION CENTER
Tel. +48 618582022 ::: http://noc.man.poznan.pl