- **Milestone**: 4.5.2 --> 4.6.2
---
** [tickets:#484] Improper implementer prefix: MsgQueueService131343**
**Status:** unassigned
**Milestone:** 4.6.2
**Created:** Fri Jul 05, 2013 08:04 AM UTC by Anders Bjornerstedt
**Last Updated:** Wed Jul 15, 2015 02:02 PM UTC
**Owner:** nobody
The MQSv creates implementers with names like:
MsgQueueService?131343
MsgQueueService?131599
MsgQueueService?131855
etc.
Implementer-names, AdminOwner-names, Class-names and root object names in
the imm service are all GLOBAL name spaces.
This is an open-source project. It is therefore important that components that
register themselves in global name spaces use proper prefixing. This is both to
avoid name collisions but also to allow identification of the component during
troubleshooting (done by others than the maintainer of that service).
As far as I know, the message queue service is the only service currently
violating this.
An implementer name should have a prefix that eliminates the
risk of naming conflicts and that makes it clear where it belongs.
If the imm-implementer is part of a SAF standard service,
then it should have the prefix "saf", like:
safAmfService
safSmfService
safCheckPointService
safLckService
safEvtService
safLogService
safMsgGrpService
If the implementer is part of an OpenSAF service that is not a
standard SAF service then it should have a prefix like "OpenSAF"
or osaf, like:
OpenSAFDtsvService
--------------------------------------------------------------------
Because this was not caught and fixed early there is now an upgrade problem.
But that should not be too hard to solve.
At the place where the OI sets up its implementer-name and tries to set itself
as class-implementer for the relevant classes. It should:
1) Allocate two OI handles and set implementername to the old bad name in one
and to the new good name in the other. If it fails to set either implementer
name with ERR_EXIST then it should behave the way it currently behaves when the
implementer-name is occupied.
2) For each class it is to be class implementer for it does:
Try to set class-implementer to the new good name (using the good handle).
If this fails with ERR_EXIST then (i) try to set class-implementer to the
old bad name (using the bad handle). This should succeed. (ii) clear the
implementer-name using saImmOiClassImplementerRelease() this should
succeed and is one of the rare occurrences where this api function is needed.
(iii) Set implementer to the new good name (using the good handle).
Repeat (2) for all classes used by the service.
I am raising the priority to major (from previously being minor) because:
- This is easy to fix.
- The current setup looks bad and sets a bad example.
- The current setup can cause confusion or uncertainty during troubleshooting
or when just trying to understand the system.
---
Sent from sourceforge.net because [email protected] is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.------------------------------------------------------------------------------
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
