perfsonar development work

[Roman Lapacz <>]

Nina Jeliazkova wrote:
> 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?
>   

No, not yet. I will create the snapshot next week. So, for now use SVN.

Roman

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