1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
-
+
-
+
|
Backoffice
==========
This is technical documentation about the internal workings of Fossil.
Ordinary Fossil users do not need to know about anything covered by this
document. The information here is intended for people who want to enhance
or extend the Fossil code, or who just want a deeper understanding of
or extend the Fossil code, or who just want a deeper understanding of
the internal workings of Fossil.
What Is The Backoffice
----------------------
The backoffice is a mechanism used by a
The backoffice is a mechanism used by a
[Fossil server](/doc/trunk/www/server.wiki) to do low-priority
background work that is not directly related to the user interface. Here
are some examples of the kinds of work that backoffice performs:
1. Sending email alerts and notifications
2. Sending out daily digests of email notifications
3. Other background email handling chores
|
| ︙ | | |
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
|
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
|
-
-
+
+
-
+
|
request.
The backoffice is not a daemon. Each backoffice process runs for a short
while and then exits. This helps keep Fossil easy to manage, since there
are no daemons to start and stop. To upgrade Fossil to a new version,
you simply replace the older "fossil" executable with the newer one, and
the backoffice processes will (within a minute or so) start using the new
one. (Upgrading the executable on Windows is more complicated, since on
Windows it is not possible to replace an executable file that is in active
one. (Upgrading the executable on Windows is more complicated, since on
Windows it is not possible to replace an executable file that is in active
use. But Windows users probably already know this.)
The backoffice is serialized and rate limited. No more than a single
backoffice process will be running at once, and backoffice runs will not
occur more frequently than once every 60 seconds.
If a Fossil server is idle, then no backoffice processes will be running.
That means there are no extra processes sitting around taking up memory
That means there are no extra processes sitting around taking up memory
and process table slots for seldom accessed repositories.
The backoffice is an on-demand system.
A busy repository will usually have a backoffice
running at all times. But an infrequently accessed repository will only have
backoffice processes running for a minute or two following the most recent
access.
|
| ︙ | | |
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
|
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
|
-
+
-
+
|
> fossil test-backoffice-lease -R _REPOSITORY_
If a system has been idle for a long time, then there will be no
backoffice processes. (Either the process id entries in the lease
will be zero, or there will exist no process associated with the
process id.) When a new web request comes in, the system
sees that no backoffice process is active and so it kicks off a separate
process to run backoffice.
process to run backoffice.
The new backoffice process becomes the "current" process. It sets a
The new backoffice process becomes the "current" process. It sets a
lease expiration time for itself to be 60 seconds in the future.
Then it does the backoffice processing and exits. Note that usually
the backoffice process will exit long before its lease expires. That
is ok. The lease is there to limit the rate at which backoffice processes
run.
If a new backoffice process starts up and sees that the "current" lease has
|
| ︙ | | |
178
179
180
181
182
183
184
185
186
187
188
189
|
178
179
180
181
182
183
184
185
186
187
188
189
|
-
+
|
can be fixed. The "backoffice-logfile" setting is the name of a log
file onto which is appended a short message everything a backoffice
process actually starts to do the backoffice work. This log file can
be used to verify that backoffice really is running, if there is any
doubt. The "backoffice-disable" setting prevents automatic backoffice
processing, if true. Use this to completely disable backoffice processing
that occurs automatically after each HTTP request. The "backoffice-disable"
setting does not affect the operation of the manual
setting does not affect the operation of the manual
"fossil backoffice" command.
Most installations should leave "backoffice-nodelay" and "backoffice-disable"
set to their default values of off and
leave "backoffice-logfile" unset or set to an empty string.
|