perfsonar development work

[Roman Lapacz <>]

Szymon Trocha wrote:
> Nina,
>
> Nina Jeliazkova wrote:
> > Hello Szymon,
> >
> > We have analyzed the problems you’ve reported and came to the following
> > conclusions:
>
> First of all thank you for your thorough investigation.
>
> > 1) N/A values in perfsonarUI’s summary table and bar chart (when data is
> > actually available in the service) are most probably due to an 
> > unresolved
> > issue either in client/server side Axis or in the RRD MA service 
> > itself. The
> > problem is occurring whenever aggregated and/or parallel requests are 
> > sent
> > through Axis calls and is more frequently exhibited when more queries 
> > are
> > aggregated in a single Axis call. The N/A values correspond to broken 
> > strings
> > (e.g. for eventType or other query parameters), reported by the service:
> >
> > <nmwg:data id="resultDescriptionData_for_resultCodeMetadata_22"
> > metadataIdRef="resultCodeMetadata_22">
> >     <nmwgr:datum
> > xmlns:nmwgr="http://ggf.org/ns/nmwg/result/2.0/";>MetadataQueryGeneratorFactory.getMetadataQueryGenerator: 
> >
> > eventType f.org/ns/nmwg/characteristic/utilization/2.0 is not
> > supported</nmwgr:datum>
> >   </nmwg:data>
> >
> > This happens for random interfaces and random positions in the parameter
> > strings. However, perfsonarUI sends the correct strings in its queries,
> > regardless if they’re aggregated, parallel or simple. As a workaround 
> > we have
> > reduced the default level of query aggregation from 32 to 8 
> > interfaces which
> > mitigates the issue for PIONIER RRD MA. However, even with these more
> > conservative settings some erroneous N/A values are reported by GEANT 
> > RRD MA,
> > illustrating the fact that the problem depends on other factors as 
> > well (e.g.
> > number of available interfaces in a given RRD MA, load of the RRD MA, 
> > etc). We
> > have reproduced the above problem with the Python client as well, 
> > which points
> > to the server side Axis or the RRD MA service itself as the culprit, 
> > because
> > the Python client doesn’t use client side Axis and moreover is a 
> > completely
> > independent client implementation.
>
> Did it happen before? I don't remember someone reported it (but I may 
> be wrong)
> Roman - could you investigate it where the problem could be located 
> within the service and how we can fix it?

Today Maciej and I were discussing the problem of text cutting. The bug 
was in the SAX parser of NMWG implementation. Maciej has already updated 
this parser in svn trunk and it should work fine now. Soon I will focus 
on the service performance issue and try to find other places to improve.

Roman