perfsonar development work

["Michael Bischoff" <>]

This is a bit orthogonal to what's noted below so take it as such:

Setting logging to trace (Java LS Client RI uses SLF4J so it's hooked into 
the logging of
psUI if I remember correctly.) will print all the requests being send - I 
would opt for
filtering/using xml output as the messages will be large in number(psUI wide) 
and size(LS
Messages and stacktraces)

Also note that enabling trace kills the streaming nature as documented here:
http://wiki.perfsonar.net/jra1-wiki/index.php/Lookup_Service_API_RI_functions

This might or might not have an impact on speed - it will have an impact on 
the amount of
memory the LS Client RI uses.

-Michael

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