Ok,

ACK.

-AVM


On 10/12/2016 12:27 PM, Vu Minh Nguyen wrote:
> Hi Mahesh,
>
> In README file, there is a note on this. Refer to "Note on memory handling
> for writting log record"
>
> And caller here means the one that call the function `log_stream_write_h`,
> not log client.
>
> Regards, Vu
>
>> -----Original Message-----
>> From: A V Mahesh [mailto:mahesh.va...@oracle.com]
>> Sent: Wednesday, October 12, 2016 1:47 PM
>> To: Vu Minh Nguyen <vu.m.ngu...@dektech.com.au>;
>> lennart.l...@ericsson.com
>> Cc: opensaf-devel@lists.sourceforge.net
>> Subject: Re: [PATCH 1 of 1] log: write_log_record_hdl get bad file
> descriptor
>> [#2028]
>>
>> Hi Vu,
>>
>> `Return (-1) to inform that it is caller's responsibility to free the
>> allocated mem` is this existing practices for application ?
>> or new , if new do we need to document it .
>>
>> -AVM
>>
>> On 10/12/2016 10:14 AM, A V Mahesh wrote:
>>> ACK
>>>
>>> -AVM
>>>
>>>
>>> On 9/13/2016 4:19 PM, Vu Minh Nguyen wrote:
>>>> osaf/services/saf/logsv/lgs/lgs_filehdl.cc |  16 +++++++++++-----
>>>>    osaf/services/saf/logsv/lgs/lgs_stream.cc  |   6 ++++++
>>>>    2 files changed, 17 insertions(+), 5 deletions(-)
>>>>
>>>>
>>>> logsv did pass the WRITE request to file handle thread even
>>>> the file descriptor was invalid. Also, when closing file,
>>>> the file handle thread did not set it to invalid.
>>>>
>>>> This patch fixes these things.
>>>>
>>>> diff --git a/osaf/services/saf/logsv/lgs/lgs_filehdl.cc
>>>> b/osaf/services/saf/logsv/lgs/lgs_filehdl.cc
>>>> --- a/osaf/services/saf/logsv/lgs/lgs_filehdl.cc
>>>> +++ b/osaf/services/saf/logsv/lgs/lgs_filehdl.cc
>>>> @@ -467,16 +467,15 @@ open_retry:
>>>>     */
>>>>    int fileclose_hdl(void *indata, void *outdata, size_t max_outsize) {
>>>>      int rc = 0;
>>>> -  int fd;
>>>> +  int *fd = static_cast<int *>(indata);
>>>>    -  fd = *static_cast<int *>(indata);
>>>> -  TRACE_ENTER2("fd=%d", fd);
>>>> +  TRACE_ENTER2("fd=%d", *fd);
>>>>        osaf_mutex_unlock_ordie(&lgs_ftcom_mutex); /* UNLOCK critical
>>>> section */
>>>>      /* Flush and synchronize the file before closing to guaranty that
>>>> the file
>>>>       * is not written to after it's closed
>>>>       */
>>>> -  if ((rc = fdatasync(fd)) == -1) {
>>>> +  if ((rc = fdatasync(*fd)) == -1) {
>>>>        if ((errno == EROFS) || (errno == EINVAL)) {
>>>>          TRACE("Synchronization is not supported for this file");
>>>>        } else {
>>>> @@ -485,9 +484,16 @@ int fileclose_hdl(void *indata, void *ou
>>>>      }
>>>>        /* Close the file */
>>>> -  rc = close(fd);
>>>> +  rc = close(*fd);
>>>>      if (rc == -1) {
>>>>        LOG_ER("fileclose() %s",strerror(errno));
>>>> +  } else {
>>>> +    // When file system is busy, operations on files will take time.
>>>> +    // In that case, file handle thread will get timeout and the
>>>> `requester`
>>>> +    // will put the `fd` into one link list to do retry next time.
>>>> +    // But if closing file succesfully, let the `requester` knows and
>>>> +    // no need to send `close file request` again.
>>>> +    *fd = -1;
>>>>      }
>>>>        osaf_mutex_lock_ordie(&lgs_ftcom_mutex); /* LOCK after critical
>>>> section */
>>>> diff --git a/osaf/services/saf/logsv/lgs/lgs_stream.cc
>>>> b/osaf/services/saf/logsv/lgs/lgs_stream.cc
>>>> --- a/osaf/services/saf/logsv/lgs/lgs_stream.cc
>>>> +++ b/osaf/services/saf/logsv/lgs/lgs_stream.cc
>>>> @@ -1122,6 +1122,12 @@ int log_stream_write_h(log_stream_t *str
>>>>        if (*stream->p_fd == -1) {
>>>>          TRACE("%s - Initiating stream files \"%s\" Failed",
>>>> __FUNCTION__,
>>>>                stream->name.c_str());
>>>> +      // Seems file system is busy - can not create requrested files.
>>>> +      // Let inform the log client TRY_AGAIN.
>>>> +      //
>>>> +      // Return (-1) to inform that it is caller's responsibility
>>>> +      // to free the allocated memmories.
>>>> +      return -1;
>>>>        } else {
>>>>          TRACE("%s - stream files initiated", __FUNCTION__);
>>>>        }
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Reply via email to