[jira] [Commented] (DISPATCH-437) Reconcile C and python management agents

["Alan Conway (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DISPATCH-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15372889#comment-15372889 ] 

Alan Conway commented on DISPATCH-437:
--------------------------------------

Update: the C "identity" is in fact unique per-agent, we should probably adopt a short numeric identity for all entities.
Multi-type query (e.g. query with no type, or query with a base type) presently does not work, only python entities are returned.

The old python agent has a nasty interface with C code, which is the main motivation for the new C agent.

# Proposal:

Keep just the schema-based request validator from the python agent. Have it validate *all* requests, but not execute them: just forward the
valid requests to the C runtime. The python agent can also break multi-type queries into a series of leaf-type queries before forwarding to C.

C agent handles all interactions with core data and formats/sends responses for *all* operational entites handling locking etc. C doesn't need to worry about schema validation, conversions etc.  it can assume pre-validated requests.

Presently only the router core agent is implemented in C, to complete the picture we will need to compose response data for queries from multiple thread contexts (at least core and connection threads) We will need a thread-safe "composer" or cache to maintain query data from multiple contexts. Not clear if that should be C or python.

As a first step we could
- separate the validator
- have it forward to both python and C agents
- make identities consistent
- compose query results in python

That would solve the immediate user-visible inconsistencies. We can move other entities into C later, but we should get to a clear division of labour sooner rather than later as having multiple approaches is confusing . It may make sense to keep configurationEntities in python as they don't suffer the same locking issues as operationlEntities.



> Reconcile C and python management agents
> ----------------------------------------
>
>                 Key: DISPATCH-437
>                 URL: https://issues.apache.org/jira/browse/DISPATCH-437
>             Project: Qpid Dispatch
>          Issue Type: Bug
>          Components: Management Agent
>    Affects Versions: 0.6.0
>            Reporter: Alan Conway
>            Assignee: Ted Ross
>
> The router now has two management agents, one in C and one in Python. They have overlapping and inconsistent functionality, which creates a difficult user experience. They need to be more closely aligned.
> Issues noted so far:
> - python agent "identity" attribute is unique per-agent. C agent "identity" is only unique per type and cannot be used in READ requests  (DISPATCH-409)
> - python agent allows delete by name or identity alone, C agent requires the client specify the type as well (DISPATCH-408)
> - C agent does not do string conversions for integral attribute types as reqiured by the management spec. The "fix" in qdmanage is incorrect (DISPATCH-411)
> - There are two address types - org.apache.qpid.dispatch.router.config.address and org.apache.qpid.dispatch.router.address. There is no shortname for org.apache.qpid.dispatch.router.address. Should short names be removed ?
> I recommend that we need:
> 1. A single code path to validate/convert/insert defaults in incoming requests based on the schema.
> 2. A clear, documented statement of what "identity" means and whether it is type-scoped or agent-scoped, with a re-implementation of either the C or python entities to comply.
> We may need to rework the interface between python and C to make it efficient and thread-safe, or refactor some/all of the python functionality as C, but we do need to get rid of the redundancy and inconsistency.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org