Skip to Content.
Sympa Menu

perfsonar-dev - Re: [pS-dev] Lookup service playground tab

Subject: perfsonar development work

List archive

Re: [pS-dev] Lookup service playground tab


Chronological Thread 
  • From: Nina Jeliazkova <>
  • To: Szymon Trocha <>
  • Cc: "" <>, GN3 JRA2 T3 <>,
  • Subject: Re: [pS-dev] Lookup service playground tab
  • Date: Mon, 10 Aug 2009 14:16:03 +0300

Hi Szymon, Jason,

Thanks for the actual links to the LS tree.

Szymon Trocha wrote:
> Hi Nina,
>
> Nina Jeliazkova pisze:
>> Hello All,
>>
>> As agreed within GN3 JRA2 T3, an initial implementation of a "Lookup
>> service playground" tab for PerfsonarUI is available at
>> http://perfsonar.acad.bg/psui_beta/perfsonar.jnlp
>
> Great to hear it!
> And thank you for the first tests. I think the implementation and
> tests will be very useful for the LS infrastructure, algorithm and API
> verification and make it easier (like below).
>
>> 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.


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

http://ndb1.internet2.edu:9991/perfSONAR_PS/services/gLS
http://ale.damsl.cis.udel.edu:9991/perfSONAR_PS/services/gLS
http://ps1.es.net:9990/perfSONAR_PS/services/gLS
http://ps4.es.net:9990/perfSONAR_PS/services/gLS
http://ls.monipe.rnp.br:9990/perfSONAR_PS/services/gLS
http://tukki.fnal.gov:9990/perfSONAR_PS/services/gLS
http://ls.perfsonar.pionier.net.pl:9990/perfSONAR_PS/services/gLS
http://ps1.jp.apan.net:9990/perfSONAR_PS/services/gLS
http://moonshine.damsl.cis.udel.edu:9991/perfSONAR_PS/services/gLS

> - And it's true it was not working. I will try to relaunch it and you
> will be able to repeat tests with GN2 domain
OK, thank you.
> - 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.
> - 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
> 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

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).
>
>> Another weird observation it seems the list of services returned doesn't
>> always depend of the query IP address; for a set of subsequent queries
>> from diverse sites , the same list of services is retrieved for a given
>> time interval
>> (https://dc211.internet2.edu/cgi-bin/perfAdmin/serviceList.cgi was
>> used to select random nodes for testing) .
>> If the test is repeated later, the list of services is different, but
>> again doesn't always depend on the query. The logs show a correct query
>> has been send. Any hint what is going wrong (or what I am doing wrong)
>> will be very useful.
>
> I'm not sure what you are describing here. Can you give an example?
This might be wrong observation of mine I had the impression all the
time one and the same services are returned, regardless of the query or
at least the returned entries didn't entirely correspond to what I was
looking at https://dc211.internet2.edu/cgi-bin/perfAdmin/tree.cgi ; I
was not aware this script is outdated. See my tests above.

Regards,
Nina
>
> Regards,




Archive powered by MHonArc 2.6.16.

Top of Page