We have a PrinceXml 9 installation on Windows 2008 Server that recently had started to behave strangely. The problem seems to be fixed for now, but I'm posting this message in an attempt to find root cause.
We have always used a single princexml.log file for all prince runs, all of which are started via the .NET wrapper call ConvertString(string xmlInput, Stream pdfOutput) where the passed Stream is a newly created FileStream object pointing to a new file. This has worked fine for years.
For the last month or so the prince processes have started to now and then "hang" while consuming cpu time. The process would then have to be killed manually. In the last week or so the problem had become urgent: the hosting provider would have to kill the prince processes several times per hour.
Looking through the log file we noticed occasional occurrences of "internal error: error writing to buffer" messages. It is unclear if these are in any way related to the hanging prince processes, since we could not correlate the messages to the processes, as we only had the single >70MB logfile. The messages were always immediately followed by "end" messages with the same date/time, which argued against it (of course the hang could have occurred after the writing of that message).
During the analysis last Friday we renamed the old log file and then modified our code to start using separate logfiles for each prince process, so that we could correlate the errors and/or hangs to the specific print jobs. However, since the renaming (a few hours before the deployment of our modified code) the problems have not occurred again (neither the hangs nor the internal errors).
Is it possible that Prince 9 has a problem with writing to a large existing logfile? The first internal error message occurred on April 6 when the logfile was a little over 40 Mb; when the logfile went over around 70 Mb the messages occurred more often, ending about 40 times per day (we average around 2000 print jobs per weekday). The frequency sort-of looks in the right ballpark for the reported number of hangs, but that is circumstantial evidence at best....
We have always used a single princexml.log file for all prince runs, all of which are started via the .NET wrapper call ConvertString(string xmlInput, Stream pdfOutput) where the passed Stream is a newly created FileStream object pointing to a new file. This has worked fine for years.
For the last month or so the prince processes have started to now and then "hang" while consuming cpu time. The process would then have to be killed manually. In the last week or so the problem had become urgent: the hosting provider would have to kill the prince processes several times per hour.
Looking through the log file we noticed occasional occurrences of "internal error: error writing to buffer" messages. It is unclear if these are in any way related to the hanging prince processes, since we could not correlate the messages to the processes, as we only had the single >70MB logfile. The messages were always immediately followed by "end" messages with the same date/time, which argued against it (of course the hang could have occurred after the writing of that message).
During the analysis last Friday we renamed the old log file and then modified our code to start using separate logfiles for each prince process, so that we could correlate the errors and/or hangs to the specific print jobs. However, since the renaming (a few hours before the deployment of our modified code) the problems have not occurred again (neither the hangs nor the internal errors).
Is it possible that Prince 9 has a problem with writing to a large existing logfile? The first internal error message occurred on April 6 when the logfile was a little over 40 Mb; when the logfile went over around 70 Mb the messages occurred more often, ending about 40 times per day (we average around 2000 print jobs per weekday). The frequency sort-of looks in the right ballpark for the reported number of hangs, but that is circumstantial evidence at best....