EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Support for larger messages in IOC Error Logging facility
From: Andrew Johnson <[email protected]>
To: "J. Lewis Muir" <[email protected]>
Cc: [email protected]
Date: Wed, 08 Nov 2006 16:11:15 -0600
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

References:
Support for larger messages in IOC Error Logging facility J. Lewis Muir
Re: Support for larger messages in IOC Error Logging facility Andrew Johnson
Re: Support for larger messages in IOC Error Logging facility J. Lewis Muir

Navigate by Date:
Prev: Re: Support for larger messages in IOC Error Logging facility J. Lewis Muir
Next: Re: ant problem when building Irmis Lecorche Eric
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Support for larger messages in IOC Error Logging facility J. Lewis Muir
Next: calcout without update Emmanuel Mayssat
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·