Kejpa,
It sounds like each log object writes to a single log file, correct?
Each thread can have its own log object, although I normally have a single
log object (as its easier to share the padlock itself (the object that is
SyncLocked)). Either way: I am suggesting the log object does not do the
zipping.
I am suggesting creating a single zip object that based on a timer
(System.Timers. Timer or
System.Threadin g.Timer) adds the single log file to the zip file. The reason
I am suggesting this is that I expect the act of zipping takes longer then
the act of writing a log entry. The zip thread could rename the log & create
a new log allowing the other threads to keep running, then the zip thread
could save the log file to the zip file at its leisure.
I am using synclock on the zip file (IO.FileInfo object) but it still
messes
up now and then.
When you use SyncLock you need to be certain that the object that is being
locked is shared between all threads. Also you need to be certain you are
locking enough code without locking too much.
It might be helpful if you could show us your log & zipping code, that way I
or someone else may be able to see why the zipping doesn't work as you
expect.
Hope this helps
Jay
"Kejpa" <kS*******@saj. fi> wrote in message
news:cm******** **@gandalf.alco m.aland.fi...
Is each object running in their own thread?
Yup, each object is listening for messages and write down them to the log
as
they arrive.
I would consider separating the logic that creates the zip file from the
objects themselves. Let the objects themselves simply write to the log
file.
You mean I should create just one global log object and let the listeners
use that one?
Currently I'm creating a separate log object for each object, when the log
object discovers a change of hour it starts a separate thread that will
zip
the log.
Alternatively you can use one or more SyncLock statements to ensure that
only a single Thread is zipping the file at a time. Primarily you want a
SyncLock around the time check to see if zipping needs to occur. I would
consider putting a separate SyncLock (on a different lock object) around
the zipping itself, just to be certain.
I am using synclock on the zip file (IO.FileInfo object) but it still
messes
up now and then.
Hope this helps
Jay
Sure does,
At least I'm not sure I did the right thinking at first ;)
Regards
/Kejpa