[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ptp-dev] on moab integration
|
Feiyi,
On Jul 24, 2007, at 11:54 AM, Feiyi Wang wrote:
hi, folks -
Moab document says it can interface with both java and c, but
looking into the API, I have two concerns:
- It doesn't have callback function to update node and job status,
meaning if I want to update eclipse front, I have to probe
periodically.
Is orte actively updating the front? how does it handle this?
ORTE gets it's information via callbacks that are generated only when
state changes occur, which is much more efficient than polling. I'm
not sure what Dave is doing for the PE case, but he might want to
comment also.
Polling would probably be ok as long as you keep the frequency fairly
low. This is going to be a tradeoff with the responsiveness you want
to deliver to the user. You should also keep a snapshot of the state
internally in your proxy so that you only need to send differences to
Eclipse. That way you'll be able to minimize the load on Eclipse.
Does Moab have a tool to monitor status? How does that work?
- It is strange that I couldn't find API/structure to query system
resource. Most API documented there are job related. One Moab
developer suggested me to use their so-called "XML api", some C
function will take a XML string, and return XML result, the same as
you would get from their command line tool.
The issue with getting XML string *not* C structure is, I need to
re-parse the result and set up the correct structure again. As a
side note, these returned xml string can be very very large:
For example, on ORNL jaguar system with over 11000 nodes, to
implement get_node_attributes(), a query to system yields 6.8M XML
string, the worst of it is, *a single string* - so far it render
Eclipse, Emacs, Gedit not responsive anymore when trying to load
it. Even if I parse it right eventually, it feels so ugly, do you
folks see this is a long term solution?
It sounds like this will generate a lot of overhead just parsing the
string every time. Is there any way to only generate differences or
do you just get a full dump every time?
You're going to be restricted by whatever API Moab provides. If it
proves unworkable, then getting Moab to add a better interface might
be one option.
Greg
