search

POETSII / Orchestrator

The Orchestrator is the configuration and run-time management system for POETS platforms.
1 stars 1 forks source link

Support for indexed pins #220

Open m8pple opened 3 years ago

m8pple commented 3 years ago

Indexed pins were proposed in PIP002, mostly to solve a need that Gaith from UoN had in terms of sending along one edge of the fanout. They were added during the v3 XML spec, and still exist in the v4 XML schema:

I don't know how widely they are used, but they are included in the reference XML applications send to Andrew from PIP20. In particular the betweeness centrality demo app won't work without them.

I don't think these appear anywhere in the Orchestrator, except for the copy of the v4 grammar. I can't see them anywhere in orchestrator documentation either.

If indexed sends aren't supported then it probably isn't a big problem for most applications, but it does represent a deviation from the existing functionality. Either we should bump the grammar to v5, or parse and then if it is used indicate that it is not supported. For example, if indexed="false" there is no problem, but if indexed="true" then some kind of "not implemented" error would be thrown.

m8pple commented 3 years ago

Workaround in this commit: Fixed by this commit: 74e27478dee3e7031cda1c608e8abb1080a83756

m8pple commented 3 years ago

BTW: this prints an error message, but I couldn't work out how to indicate "I have failed" from within the parsing code, short of aborting the process.

heliosfa commented 3 years ago

Reading through the pip, indexed sends should not be too difficult to implement on the softswitch side as we already have an (indexed) array of pins that we iterate through in the softswitch.

I think all I'd need to do is make a sendIndex pointer available in the OnSend handler and modify the internal pin structure and actual send logic to respect it.

The issue is likely to come from representation in the Orchestrator data structure: At the moment, pin targets are placed in the order in which they are encountered in the XML. If this order can deviate from the the declared sendIndex order, then we need to modify either how they are stored or how Composer interrogates them when generating code.

XML parsing shouldn't be too hard.

heliosfa commented 3 years ago

Having had a chat with ADB, we have an overview of how to implement it in the Orchestrator. That said, our current position is that if no one is currently using it, we will not implement it as a priority. If someone does need it, we will obviously implement it.

We will fix things so that an XML that uses this feature flags an error/warning.

m8pple commented 3 years ago

Implementing indexed sends is less important than being able to parse XML that declares that pins are not indexed. The V4 emitters often emit this attribute, so there is lots of extant XML with "indexed=false".

I've rebased the proposed patch from last month into #264 , as it is still a blocking issue.

m8pple commented 2 years ago

This feature is used by the betweeness_centrality suite from the benchmarks-2019-09-06 stress tests, so those tests can't be run. However, it is more a demo of graph processing than something we want to write a paer about right now.

I don't know if UoN still needs these before they can use the Orchestrator - it would be worth checking before encouraging them to migrate from POLite.