Hi all,

We are using OpenSAF 5.2.0, and have recently begun using the SAF Message 
Service within our application.  We have uncovered the following 3 anomalies.   
If anyone could provide additional detail or clarification, that would be 
greatly appreciated:


  1.  saMsgQueueOpen() API, parameter QueueName - We were consistently getting 
the error SA_AIS_ERR_NO_RESOURCES (18) error code when initializing.  This was 
thoroughly misleading and led us down a path of OS/kernel parameter settings, 
user permissions issues, etc.  But the actual problem was an "invalid" queue 
name (which we don't believe is really invalid).  We were passing in the name 
"safMq=Testq,safApp=MySafApp".  What resolved the problem was when we passed in 
the name "safMq=Testq,safApp=safMsgService".  The OpenSAF documentation is 
severely lacking in this area.  This seems to be either inconsistent with, or 
in the worst case, in violation of, the SAF standard.  We feel the following 
changes should be considered and evaluated:
     *   Error Code should be updated to return invalid parameter, since that 
was the root cause.
     *   OpenSAF documentation needs to be updated to EXPLICITYLY clarify that 
"safApp=safMsgService" is REQUIRED in the queue name.
  2.  saMsgMessageCancel() API - is this call operational?  We only seem to get 
SA_AIS_ERR_TRY_AGAIN when it is invoked, and code blocked on saMsgMessageGet() 
doesn't unblock.  This should be explicitly documented in the Programmer's 
reference manual.
  3.  saMsgMessageGet() API - when the saMsgQueueClose() is called, this 
unblocks the "get" call as expected.  However, the return from 
saMsgMessageGet() also returns a non-zero value for the "length" of the 
"senderName" in the message.  Since we were keying off the non-zero length, 
this consistently resulted in a segfault.  We now only check this value if the 
error code is SA_AIS_OK.  We believe this should be zeroed out per SAF spec. 
Below is SAF text from MsgSvc. (the problem being the structure is invalid for 
use.)
     *   "senderName [in/out] If senderName as an in parameter is not NULL, it 
points to an area to contain the sender name. If the sender name is available 
in the received message, the Message Service places the sender name into this 
area; otherwise, message->senderName->length is set to zero. If senderName as 
an in parameter is NULL, no sender name is provided to the caller."

Thanks.

Jim

_______________________________________________
Opensaf-users mailing list
Opensaf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-users

Reply via email to