Re: Support for larger messages in IOC Error Logging facility

[Andrew Johnson <anj@aps.anl.gov>]

Hi Lewis,

J. Lewis Muir wrote:
> To make it work from iocsh, I needed to make iocsh aware of this new 
> errlogInit2 function so I modified
>
>   src/iocsh/iocCoreLimitsRegister.c

Oops, sorry I forgot to include that change in the patch I sent.


> Here are the results of my tests. When I refer to the number of 
> characters, I am including the terminating null character in the count.

Thanks for doing this.

> 1. errlogInit2(1280, 1024)

>    Tried writing 1025 characters via errlogPrintf:
>     ?: Wrote full message on IOC console. I was a little surprised by
>        this, but maybe this is the expected behavior.

From looking at the errlog.c source code that is the expected behaviour 
- it actually converts the argument list twice, once to stdout and again 
to the log client buffer.

> 2. errlogInit2(20000, 2050)

>    Tried writing 1026 characters via errlogPrintf:
>    OK: Wrote full message on IOC console.
>     ?: Wrote full message in iocLogServer output, but as two entries
>        (i.e. two timestamped entries with the first entry containing the
>        first 1024 characters and the second entry containing the 1025th
>        character). I think this might be because iocLogServer handles
>        input 1024 characters at a time. This behavior is OK with me, but
>        even nicer would be for it to handle messages longer than 1024
>        characters by not splitting them into multiple entries.

If the split is due to the iocLogServer (which does currently have a 
fixed 1024 character receive buffer for each client) then you should be 
able to solve the problem by building a version of the server with a 
larger iocLogClient.recvbuf array.  Ideally the buffer size could be set 
as a program argument or possibly even an environment variable, but 
making either change would take a bit more work than just making the 
buffer bigger. If you feel like implementing either (or even making the 
server work on any size message independent of the buffer size) I'd be 
happy to include the patch.

> Thanks again for making the change and being willing to get this into a 
> future release!

Ok, I'll commit my changes which will appear in R3.14.9, due sometime in 
December.

- Andrew
--
There is considerable overlap between the intelligence of the smartest
bears and the dumbest tourists -- Yosemite National Park Ranger