perfsonar development work

["Nina Jeliazkova" <>]

Roman,

Thanks, we'll try to update ISTF's Java RRD MA asap. Are the changes related
to aggregated key requests included in today's snapshot?

http://monstera.man.poznan.pl/jra1-wiki/images/files/perfSONAR-RRD_MA-src-snapshot-20060825.tar.gz

Best regards,
Nina


Roman Lapacz 
<>
 wrote:

> 
> Nina, could you update your Java RRD MA from SVN and test it with that 
> example request again?
> 
> Roman
> 
> 
> Nina Jeliazkova wrote:
> > Hi,
> >
> > We would like to make use of aggregated SetupDataRequests with keys in the
> > next release of perfsonarUI. The motivation for this move is twofold:
> >
> > 1)  avoid stressing perfSONAR services as much as possible (make use of
> keys);
> > 2)  avoid the multiplication of network latency with number of (not
> aggregated)
> > consecutive requests sent to a given service;
> >
> > While playing with Java RRD MA (perfSONAR-1.0), we noticed that it is
> > impossible to achieve the above goal, because the service returns a
response
> > in which there is no way to identify the correspondence between data and
> > interfaces (see attached request and response). The same holds true for
> Python
> > RRD MA as well.
> >
> > The questions are:
> > 1)  Is this service behaviour intentional?
> > 2)  What’s the recommended workaround?
> >
> > So far we’ve figured out that we could send aggregated SetupDataRequests
> > *without* keys and make use of the metadata returned by the service for
> > identifying the above mentioned correspondences. Another possibility would
> be
> > to send many not aggregated requests simultaneously (in this case the
> network
> > latency multiplication problem would be also avoided and the
correspondence
> > could be derived by comparing the request with the response). However, the
> > later would most probably also stress the services too much (imagine 500
> > simultaneous requests, each of them for one interface) and the former
isn’t
> > optimal either (doesn’t make use of the key mechanism). Which of those
> > solutions should be preferred? Are there any plans for something better in
> the
> > longer term on the service side?
> >
> > Kind regards,
> > Nina
> >   
>