Skip to Content.
Sympa Menu

perfsonar-dev - Re: [pS-dev] Add geant2-java-rrdma to psUI

Subject: perfsonar development work

List archive

Re: [pS-dev] Add geant2-java-rrdma to psUI


Chronological Thread 
  • From: Nina Jeliazkova <>
  • To: "Jeff W.Boote" <>
  • Cc: Szymon Trocha <>, "" <>
  • Subject: Re: [pS-dev] Add geant2-java-rrdma to psUI
  • Date: Wed, 11 Mar 2009 18:13:22 +0200

Jeff W.Boote wrote:
>
> On Mar 11, 2009, at 9:27 AM, Szymon Trocha wrote:
>>
>>> Since this is a Java hLS, I would ask Maciej to please look at his
>>> summarization code to ensure the proper ranges are being reported,
>>> 150.254.162.229/32 is rather specific :) As for the other ranges,
>>> if you know which hLS is summarizing for them I can do the same
>>> analysis to get us closer to debugging the problem.
>>
>> So the above shows that after summarization the data is there
>> (generally speaking).
>> So if there are sources of data which announce themselves correctly
>> to LS infrastructure why does psUI get MAs which are completely
>> different than PIONIER correct ones (which don't appear at all)? They
>> shouldn't appear in the list as they do not contain PIONIER data. Is
>> it wrong API request, wrong response from LS, wrong response
>> interpretation?
>>
>>> The bottom line is that if there is not data in the gLS cloud this
>>> will not work. The results for the Interet2/IU services would still
>>> show up, but the 'correct' hLS would as well and proper answer can
>>> be discovered.
>>
>> Let me know if you need more details.
>
> It is not clear if this is a discovery issue, or an advertising
> problem at this point.
>
> One aspect of this is that the pS-PS hLS summarization algorithm is
> advertising too-wide of ranges, and we are working on fixing that.
> But, we also need to understand better the summarization algorithm of
> the MDM hLS. It looks suspect that it is advertising /32's.
>
> As mentioned before - we need to see the actual messages that the Java
> gLS-API is sending to debug this. Obviously the discovery query that
> is being sent from pS-UI is not finding those /32's - and we won't be
> able to figure out why until we can see the specific query messages it
> is sending.
>
> There is no reason to arrange a call until more information is shared
> asynchronously. All we would be doing is reiterating the already
> demonstrated problem. For this debugging to work, we will need Mac
> involved to explain how MDM hLS summarization works, and we will need
> Michael and/or Nina to explain the queries pS-UI is attempting.
I will need a help from Michael how to log/view messages gLS
API/implementation is sending.

Regards,
Nina
>
> If we determine that the interaction model used by pS-UI is not
> compatible with the current design of the gLS, then we should setup a
> call to work out the expected use-cases better for a redesign. (And at
> that time we can determine if the specific use case is reasonable for
> a distributed information architecture or not.) But, our first task
> should be to understand the current problem so we can determine if it
> is simply a bug or something more fundamental. And as I said, to do
> that we need the specific query messages - and the ability to ask Mac
> questions about MDM-hLS summarization.
>
> jeff




Archive powered by MHonArc 2.6.16.

Top of Page