private class FiddlerImpl.SnapshotThread extends InterruptedStatusThread
A snapshot is taken when -- after writing a new record to the log file -- it is determined that the size of the log file has exceeded a certain threshold. The code which adds the new record to the log file and which, in turn, decides that a snapshot must be taken is "wrapped" in a writer mutex. That is, synchronization of processing is achieved in this service through a "reader/writer" mutex construct. This construct allows only one writer at any one time; but allows an unlimited number of simultaneous readers as long as no writer has locked the mutex. During steady-state, it is anticipated that far more "read actions" will occur (e.g. discovery events being sent) than "write actions" (e.g. modifying the managed sets). Since the process of taking a snapshot can be time-consuming, if the whole snapshot-taking process occupies that single writer mutex, then a significant number of read actions will be un-necessarily blocked; possibly resulting in an unacceptable degradation in response time.
It is for the above reason that the process of taking a snapshot is performed in a separate thread. The thread waits on the monitor belonging to the snapshotThreadSyncObj instance until it is notified (or "signalled") that a snapshot must be taken. The notification is sent by another thread, created by this service, which determines when the conditions are right for a snapshot. The notification takes the form of an interrupt indicating that the snapshot monitor is available. Although the interrupt is sent while the writer mutex is locked, the act of sending the notification is less time-consuming than the act of taking the snapshot itself. When the thread receives a notification, it awakens and requests a lock on the reader mutex (this is all done in the readerWait() method). Because a reader -- not a writer -- mutex is locked, read-only processes still have access to the system state, so discovery events can be sent and the service's state can be queried; but the reader mutex prevents changes to the state while the snapshot is in progress.
Note that the current snapshot is guaranteed to complete before the next snapshot request is received. This is because even though the act of taking a snapshot can be viewed as a writer process, the fact that the next snapshot notification will be wrapped in a writer mutex, combined with the fact that a writer mutex can not be locked while a reader mutex is locked, allows the snapshot to be treated as a reader process.
Thread.State, Thread.UncaughtExceptionHandlerMAX_PRIORITY, MIN_PRIORITY, NORM_PRIORITY| Constructor and Description |
|---|
FiddlerImpl.SnapshotThread()
Create a daemon thread
|
| Modifier and Type | Method and Description |
|---|---|
void |
run() |
hasBeenInterrupted, interruptactiveCount, checkAccess, clone, countStackFrames, currentThread, destroy, dumpStack, enumerate, getAllStackTraces, getContextClassLoader, getDefaultUncaughtExceptionHandler, getId, getName, getPriority, getStackTrace, getState, getThreadGroup, getUncaughtExceptionHandler, holdsLock, interrupted, isAlive, isDaemon, isInterrupted, join, join, join, resume, setContextClassLoader, setDaemon, setDefaultUncaughtExceptionHandler, setName, setPriority, setUncaughtExceptionHandler, sleep, sleep, start, stop, stop, suspend, toString, yieldCopyright 2007-2013, multiple authors.
Licensed under the Apache License, Version 2.0, see the NOTICE file for attributions.