Mercurial > hg > blitz_stable

comparison docs/install_guide.html @ 0:3dc0c5604566

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Initial checkin of blitz 2.0 fcs - no installer yet.
author Dan Creswell <dan.creswell@gmail.com>
date Sat, 21 Mar 2009 11:00:06 +0000
parents
children
comparison
equal deleted inserted replaced
-1:000000000000 0:3dc0c5604566
1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
2 <html>
3 <head>
4
5
6
7
8
9 <title>Blitz Installation Guide</title>
10 <link rel="stylesheet" type="text/css" href="ssl.css">
11 </head>
12
13
14 <body>
15
16
17 <h1>Blitz Installation Guide</h1>
18
19
20 <h2>Table of Contents</h2>
21
22
23 <ol>
24
25
26 <li><a href="#intro">Installation Choices</a></li>
27
28
29 <li><a href="#start">Getting Started</a></li>
30
31
32 <li><a href="#running">Running Blitz</a></li>
33
34
35 <li><a href="#memory">Memory Usage</a></li>
36
37
38 <li><a href="#admin">Administration</a></li>
39
40
41 <li><a href="#storagemodels">Appendix A - Storage
42 Models</a></li>
43
44
45 <li><a href="#appb">Appendix B - Configuration
46 Variables</a></li>
47
48
49 </ol>
50
51
52 <a name="intro"></a>
53 <h2>Installation Choices</h2>
54
55 <h3>Installer</h3>
56
57 <h4>GUI Install</h4>
58
59 <p>If you're a new user or just want to get something up and
60 running, it's recommended that you download the installer which
61 includes a simple readme and does most of the configuration work for
62 you. The installer package is named <code>installer_pj_n_nn.jar</code>
63 where <code>n_nn</code> is the release version number.
64 Note that you'll still need to download and install the appropriate
65 version of JINI - see <a href="required_packages.html">required
66 packages</a>. &nbsp;To run the installer use <code>java
67 -jar</code> which will display a simple GUI for gathering paths
68 and port settings.</p>
69
70 <h4>Headless Install</h4>
71
72 <p>The installer can also be run in
73 headless mode (command-line install) where one should specify the paths
74 and port settings as follows:</p>
75
76
77 <pre>java -jar installer.jar JDK_Home Jini_Home Install_Dir HTTP_Port</pre>
78
79
80 <p>or</p>
81
82
83 <pre>java -jar installer.jar Jini_Home Install_Dir HTTP_Port </pre>
84
85 <h3>Manual Install</h3>
86
87 <p>If you're an experienced user who needs ultimate control over
88 installation layout or a developer seeking to make modifications to
89 Blitz, you will wish to download either a binary or source distribution
90 and read the rest of this guide which will guide you through the
91 installation process.</p>
92
93
94 <a name="start"></a>
95 <h2>Getting Started</h2>
96
97
98 <p>First, ensure that you have installed the <a href="required_packages.html">required packages</a>.</p>
99
100
101 <p>Second, if you are going to run blitz on JDK 1.4 you will need to modify the configuration files (located in the <code>config</code> directory), substituting <code>backport-util-concurrent50.jar</code> with <code>backport-util-concurrent.jar</code>.</p>
102
103 <p>Blitz is fully integrated with JINI 2.1 so the preferred
104 method of startup is via the ServiceStarter. However, it's possible to
105 run Blitz, for test purposes, in a standalone mode.
106 </p>
107
108
109 <p>If you've downloaded the source distribution, please read the <a href="dev_guide.html">Developer's Guide</a> and ensure
110 you've compiled the Blitz <code>.jar</code>'s (once you've
111 done the necessary editing of <code>build.xml</code> you
112 can create the <code>.jar</code>'s with a simple <code>ant
113 all</code>.
114 </p>
115
116
117 <h3>Assumptions</h3>
118
119
120 For the purposes of the following examples, I assume that:
121 <ul>
122
123
124 <li>You've unpacked the distribution in <code>/home/dan/src/jini/space</code></li>
125
126
127 <li>You've installed JINI 2.1 in <code>/home/dan/jini/jini2_1</code></li>
128
129
130 <li>You've installed Brian Murphy's starter kit in <code>/home/dan/jini/jini2_1/jini-start</code></li>
131
132
133 <li>Your machine's name is <code>yakuza</code></li>
134
135
136 </ul>
137
138
139 <h3>Configuration Basics</h3>
140
141
142 <p>Blitz is configured via a configuration file such as the
143 example <a href="../config/blitz.config">blitz.config</a>
144 file. This file contains options for determining security
145 configuration, remote functions and core functions such as the storage
146 model (see above).
147 </p>
148
149
150 <p>Blitz implements a concept of Storage Models which allows the
151 user to customize the level of persistence provided. The default
152 setting is transient but, should you wish to change this, please read <a href="#storagemodels">Appendix A</a>.</p>
153
154
155 <p>Additional configuration files are required for use with the
156 ServiceStarter:</p>
157
158
159 <ul>
160
161
162 <li> <a href="../config/activatable-group.config">activatable-group.config</a>
163 and <a href="../config/start-act-blitz.config">start-act-blitz.config</a>
164 are examples of configuration files suitable for starting an
165 Activatable instance of Blitz.</li>
166
167
168 <li> <a href="../config/start-trans-blitz.config">start-trans-blitz.config</a>
169 is an example configuration file suitable for starting a
170 non-Activatable instance of Blitz.</li>
171
172
173 </ul>
174
175
176 <p>Regardless of the storage model chosen, Blitz may need to, at
177 least temporarily, persist it's state so ensure that you have properly
178 configured the appropriate entries in the core config file (these are
179 the configuration parameters <code>persistDir</code> and <code>logDir</code>
180 in the configuration file). This is also important should you wish to
181 "clean up" after a Blitz instance as you must delete the contents of
182 the persistence and log directories specified by the configuration
183 parameters.
184 </p>
185
186
187 <p><b>Note: You <em>must</em> configure the
188 persistence and log directories as described above. Other default
189 settings can be left alone though you should probably review the <code>initialGroups</code>
190 setting (particularly if you choose to not use Brian Murphy's scripts).
191 You should also look at increasing the cache sizes to suit your
192 hardware.</b></p>
193
194
195 <hr align="center" size="3" width="70%">
196 <a name="running"></a>
197 <h2>Running Blitz</h2>
198
199
200 <h3>Starting JINI</h3>
201
202
203 Before starting Blitz, you should start up the necessary JINI services.
204 We can do this using Brian Murphy's starter kit scripts as follows:
205 <pre>cd /home/dan/jini/jini2_1/jini-start/example/scripts<br><br>./urun httpd<br><br>./urun jeri-transient-reggie<br><br>./urun jeri-transient-mahalo<br><br></pre>
206
207
208 You may also find it useful to run the ServiceBrowser so you can check
209 that things are performing as expected:
210 <pre>./urun jeri-browser<br></pre>
211
212
213 Now we must start a codebase server for Blitz:
214 <pre>./urun httpd -port 8081 -dir /home/dan/src/jini/space/lib<br></pre>
215
216
217 If you plan to deploy an Activatable Blitz instance you will also need
218 to start either Phoenix or RMID. Assuming you choose to use RMID (note
219 that there are various security options that RMID doesn't support):
220 <pre>rmid -J-Djava.security.policy=/home/dan/src/jini/space/config/policy.all<br></pre>
221
222
223 <h3>Using ServiceStarter</h3>
224
225
226 <p>First, edit the configuration files as desired (you will
227 almost certainly need to alter the <code>blitzCodebase</code>,
228 <code>jiniRoot</code>, <code>dbLib</code>, <code>blitzRoot</code>
229 variables and possibly <code>dbVersion</code>). To start
230 an Activatable Blitz instance:</p>
231
232
233 <pre>cd /home/dan/src/jini/space/<br><br>java -Djava.security.policy=config/policy.all -jar /home/dan/jini/jini2_1/lib/start.jar config/start-act-blitz21.config<br></pre>
234
235
236 Note that the default configuration files expect to create a log for
237 the shared activation group in <code>/tmp/sharedvm.log</code>
238 which you will need to delete if you wish to start again from scratch,
239 re-registering the Blitz instance etc.
240 To start a non-activatable instance:
241 <pre>cd /home/dan/src/jini/space/<br><br>java -Djava.security.policy=config/policy.all -jar /home/dan/jini/jini2_1/lib/start.jar config/start-trans-blitz21.config<br></pre>
242
243
244 <hr align="center" size="3" width="70%">
245 <h3>A Word on Configuration Files</h3>
246
247
248 <p>Example configurations for JINI 2.1 can be found in the <code>config</code>
249 directory and have a <code>21</code> subscript. Those
250 configurations without the subscript are examples of scripts which
251 provide backward compatibility with JINI 2.0. Note that existing Blitz
252 scripts from releases prior to Blitz Pure Java 1.13 will need
253 modifications in line with these examples.</p>
254
255
256 <h2><a name="memory">Memory Usage</a></h2>
257
258
259 <p><a name="memory">For background you should read
260 these:
261 </a></p>
262
263
264 <ul>
265
266
267 <li><a href="http://jroller.com/page/dancres?entry=javaspaces_fallacies">JavaSpaces
268 Fallacies</a></li>
269
270
271 <li><a href="http://www.jroller.com/page/dancres?entry=are_you_leaking_memory">Are
272 You Sure You're Leaking Memory?</a></li>
273
274
275 </ul>
276
277
278 <p>Blitz uses it's cache to hold both live and dead (taken or
279 lease expired) Entry's. It only clears it's cache once it is full.</p>
280
281
282 <p>i.e. If you set the cache size to 100 and you have only five
283 entry's with one writer and one taker, Blitz will have a cache
284 containing 5 live entries and 95 dead ones after things have run for a
285 while.</p>
286
287
288 <p><b>Important:</b> Each type of Entry is given it's
289 <em>own</em> cache (i.e. there isn't one cache shared
290 across all Entry's of all types). So approximate total memory usage (to
291 get an accurate figure would require estimating garbage requirements
292 etc) is:</p>
293
294
295 <pre>memory = 0;<br>for (X in all Entry types) {<br> memory = memory + (cache_size * size_of X)<br>}<br><br>memory = memory + Db database cache size</pre>
296
297
298 <p>Where Db database cache size is specified in the configuration
299 file under dbCache</p>
300
301
302 <p>Thus in OutOfMemory situations, the correct approach is to
303 reduce entry cache size or the db cache or increase available JVM heap
304 or a combination of the three. Note that in the case of a persistent
305 Blitz, you should also consider enabling log file serialization stream
306 reset by setting the first boolean parameter to the Persistent class
307 constructor (defined as the storageModel in the configuration file) to <code>true</code>.</p>
308
309
310 <p>Note that there is a tool (EntrySizer) in the Blitz
311 distribution (see Extensions in the documentation for your chosen
312 version) which can be used to compute the approximate size of an Entry
313 as it will be stored in Blitz's cache.</p>
314
315
316 <p>Note also that you can specify individual cache sizes per
317 Entry type using EntryConstraint examples of which can be found in the
318 configuration files. A good basic approach to using these constraints
319 would be to set <code>entryReposCacheSize</code> to
320 something small like 256 or 512 and then use the EntryConstraints to
321 allocate bigger caches (e.g. 1024, 4096) to specific Entry types.</p>
322
323
324 <p>In cases where you are submitting Blitz to high load for
325 sustained periods of time and the CPU usage is close to 100%, consider
326 enabling throttling to prevent overflow of internal queues. See <code>eventQueueBound</code>
327 and <code>taskQueueBound</code> in <a href="#appb">Appendix
328 B - Configuration Variables</a>.</p>
329
330
331 <a name="admin"></a>
332 <h2>Administration</h2>
333
334
335 <p>Blitz supports <code>JoinAdmin</code>, <code>DestroyAdmin</code>,
336 <code>JavaSpaceAdmin</code> and two custom management
337 interfaces (<code>BlitzAdmin</code> and <code>StatsAdmin</code>
338 and, therefore, can be managed by a variety of browser tools.</p>
339
340
341 <p>The first time a Blitz instance is started, it loads it's JINI
342 configuration information such as lookup groups and locators from it's
343 configuration file. These are then stored in a binary metadata file
344 along with the <code>serviceID</code> and various other
345 pieces of runtime information. <b>Future re-starts of the Blitz
346 instance will read the configuration information from the binary
347 metadata file (unless the StorageModel is Transient, in which case all
348 state is lost and the configuration file will be read again)</b>.
349 Thus, further configuration changes in respect of JINI state must be
350 done via JoinAdmin. Other non-JINI configuration information can be
351 changed in the configuration file and will take effect the next time
352 the Blitz instance is restarted.</p>
353
354
355 <p><code>DestroyAdmin::destroy</code> is usually
356 defined to shutdown the service instance and remove all it's persistent
357 state. As a convenience, Blitz provides a configuration variable, <code>compliantDestroy</code>,
358 which can be used to specify whether a Blitz instance should delete or
359 retain it's state when carrying out a destroy request. When <code>compliantDestroy</code>
360 is <code>false</code> Blitz simply shut's down in response
361 to a destroy call. If <code>compliantDestroy</code> is <code>true</code>
362 Blitz will delete all state before shutting down. If <code>compliantDestroy</code>
363 is not specified in the configuration file, the default is to retain
364 state when <code>destroy</code> is invoked.</p>
365
366
367 <p>It is my belief that, as well as destroy, there should be an
368 additional standardized method to trigger a shutdown whilst retaining
369 state. As there is no such standard, the <code>BlitzAdmin</code>
370 interface provides such a method.
371 </p>
372
373
374 <hr align="center" size="3" width="70%">
375 <a name="storagemodels"></a>
376 <h2>Appendix A - Storage Models</h2>
377
378
379 <p>As of Blitz 2.0, it is possible to configure a number of
380 different persistence profiles. They are currently:</p>
381
382
383 <ol>
384
385
386 <li><a href="javadocs/org/dancres/blitz/config/Persistent.html">Persistent</a>
387 - In this mode, Blitz behaves like a fully persistent JavaSpace such as
388 the persistent version of Outrigger.</li>
389
390
391 <li><a href="javadocs/org/dancres/blitz/config/Transient.html">Transient</a>
392 - (default setting) causes Blitz to act like a disk-backed cache. In
393 this mode, Blitz behaves like the transient version of Outrigger. No
394 logging is performed and, when Blitz is restarted, all state (including
395 Join state etc.) is lost. Memory-only transient implementations can
396 halt with <code>OutOfMemoryError</code>'s if they are
397 over-filled. Blitz avoids this problem by swapping to disk when the
398 number of stored <code>Entry</code>'s overflows it's
399 available cache space. Obviously, performance will degrade relative to
400 the amount of swapping Blitz is required to perform. When the caches
401 are sufficiently large, Blitz will make minimal use of disk, yielding
402 maximal performance.</li>
403
404
405 <li><a href="javadocs/org/dancres/blitz/config/TimeBarrierPersistent.html">TimeBarrierPersistent</a>
406 - provides a performance versus persistence QoS tradeoff. In this mode,
407 changes made more than a certain number of milliseconds ago are
408 guarenteed to be persistent. More recent changes are <em>not
409 guarenteed</em> persistent but <em>may be</em>
410 persistent. This mode provides the developer with a means of balancing
411 persistence needs against performance.</li>
412
413
414 </ol>
415
416
417 <p>The actual model used is determined by the value of the
418 configuration variable <code>storageModel</code>. The
419 standard configuration file contains example settings for all three
420 modes which should provide reasonable starting points for more precise
421 tuning. For more details on the exact settings for each model see the
422 Javadoc for <code>org.dancres.blitz.config.Persistent</code>,
423 <code>org.dancres.blitz.config.Transient</code> and <code>org.dancres.blitz.config.TimeBarrierPersistent</code>.</p>
424
425
426 <hr align="center" size="3" width="70%">
427 <a name="appb"></a>
428 <h2>Appendix B - Configuration Variables</h2>
429
430
431 <h3>Basic Setup</h3>
432
433
434 <ul>
435
436
437 <li><i>persistDir</i>=&lt;string&gt; - the
438 directory in which blitz will keep checkpointed state.</li>
439
440
441 <li><i>logDir</i>=&lt;string&gt; - the
442 directory in which blitz will keep it's log files. If all log files are
443 present, Blitz can reconstitute the checkpointed state.</li>
444
445
446 <li><i>storageModel</i>=&lt;type&gt; - see
447 Appendix A.</li>
448
449
450 </ul>
451
452
453 <h3>JINI-related options</h3>
454
455
456 <ul>
457
458
459 <li><i>name</i>=&lt;string&gt; - configures
460 the name of the Blitz Instance. This value is made available on the
461 proxy as a Name attribute</li>
462
463
464 <li><i>loginContext</i>=&lt;LoginContext&gt;
465 - sets the identity the Blitz instance will take on when it starts up.
466 Many security configurations will require this to be set.</li>
467
468
469 <li><i>compliantDestroy</i>=&lt;Boolean&gt;
470 - see Administration section above.</li>
471
472
473 <li><i>initialGroups</i>=&lt;String[]&gt; -
474 defines the collection of LUS groups under which a Blitz instance will
475 register on initial startup (after initial startup, groups are held in
476 an internal database which can be reconfigured via JoinAdmin.</li>
477
478
479 <li><i>initialLocators</i>=&lt;LookupLocator[]&gt;
480 - set this to configure registration with specific LUS. This value is
481 only used for initial startup as initialGroups.</li>
482
483
484 <li><i>initialAttrs</i>=&lt;Entry[]&gt; -
485 the Entry attributes to make available on the proxy as part of initial
486 startup. Behaviour is the same as for initialGroups and initialLocators.</li>
487
488
489 <li><i>serverExporter</i>=&lt;Exporter&gt;
490 -
491 configures the JERI endpoint to be used by the Blitz instance. Allows
492 for configuration of tcp, ssl, https etc as the transport.</li>
493
494
495 <li><i>*preparer</i>=&lt;ProxyPreparer&gt;
496 - defines the proxy preparer to be used to verify various remote
497 references which may be passed to a Blitz instance.</li>
498
499
500 <li><i>*recoveredPreparer</i>=&lt;ProxyPreparer&gt;
501 - defines the proxy preparer to be used to verify a remote instance
502 recovered from the log/checkpoint storage during a restart.</li>
503
504
505 <li><span style="font-style: italic;">loopbackTxnExporter</span>=&lt;Exporter&gt;
506 - configures and enables the loopback transaction manager which can be
507 used to accelerate transactions against this Blitz instance.
508 &nbsp;Note
509 it cannot be used to co-ordinate transactions amongst multiple
510 participants nor does it yet support security options. <span style="font-weight: bold;">[BETA]</span></li>
511
512
513 </ul>
514
515
516 <h3>Notify Subsystem</h3>
517
518
519 <ul>
520
521 <li><i>syncNotifyOnWrite</i>=&lt;boolean&gt; - when enabled forces writes to wait
522 until all associated events have been processed. *IfExists is a significant performance drain and by default Blitz aggressively optimizes event delivery for those calls such that events from writes close to the resolution point may be ignored. If you are using *IfExists and require completely deterministic behaviour, enable this option. For those not using *IfExists leave this option disabled for better performance.</li>
523
524 <li><i>maxEventProcessors</i>=&lt;int&gt; -
525 defines the maximum number of threads to be used to empty the notify
526 event queue and perform matching against notify templates. Defaults to
527 1.</li>
528
529
530 <li><i>eventgenSaveInterval</i>=&lt;int&gt;
531 - the number of events to be generated against an event registration
532 before logging to disk.</li>
533
534
535 <li><i>eventgenRestartJump</i>=&lt;int&gt;
536 - the number by which to advance the sequence number of an event
537 registration at recovery time. This "jump" is designed to allow an
538 end-user application to detect the fact that recovery has been
539 performed and that events may have been lost/never generated.</li>
540
541
542 </ul>
543
544
545 <h3>Lease Subsystem</h3>
546
547
548 <p>Allows control of leasing operation such as assigning a
549 maximum allowable lease time.</p>
550
551
552 <ul>
553
554
555 <li><i>entryLeaseBound</i>=&lt;long&gt; -
556 sets the maximum lease permissible for an Entry. Set this to zero to
557 allow Lease.FOREVER</li>
558
559
560 <li><i>notifyLeaseBound</i>=&lt;long&gt; -
561 sets the maximum lease permissible for a notify registration. Set this
562 to zero to allow Lease.FOREVER</li>
563
564
565 <li><i>leaseReapInterval</i>=&lt;long&gt; -
566 the time between active scans for lease expired resources. Value should
567 be ms (0 disables active cleanup). Normally, Blitz uses read/take
568 activity to do cleanup (passive). If memory or disk resource is scarce,
569 configure this to non-zero to activate more aggressive cleaning (which,
570 in turn, is more CPU aggressive). Alternatively, you can enable manual
571 lease cleanup (via execution of <code>org.dancres.blitz.tools.RequestReap</code>
572 by setting this to <code>org.dancres.blitz.lease.LeaseReaper.MANUAL_REAP</code></li>
573
574
575 </ul>
576
577
578 <h3>Advanced Setup</h3>
579
580
581 <ul>
582
583
584 <li><i>loadBackoff</i>=&lt;int[]&gt; -
585 configures the deadlock avoidance timings for loading entry's. Requires
586 a two int array consisting of base_backoff and the random jitter to
587 apply to that backoff.</li>
588
589
590 <li><i>maxOidAllocators</i>=&lt;int&gt; -
591 the maximum number of allocators to use per Entry type for id
592 generation. Ids are never reused thus a small number of allocators may
593 run out of ids in highly concurrent take/write scenarios. More
594 allocators also improves concurrency.</li>
595
596
597 <li><i>maxWriteThreads</i>=&lt;int&gt; -
598 should not be changed from the default value of 1.</li>
599
600
601 <li><i>threadKeepAlive</i>=&lt;long&gt; -
602 ms before a write thread will be killed rather than pooled.</li>
603
604
605 <li><i>maxTaskThreads</i>=&lt;int&gt; - the
606 maximum number of threads allowed for a task pool.</li>
607
608
609 <li><i>entryReposReadahead</i>=&lt;int&gt;
610 - the maximum number of Entry's to fault in should the cache provide no
611 matches. Zero means readahead should be disabled. This is a global
612 setting which can be overidden with individual Entry constraints - see
613 the Javadoc for <code>org.dancres.blitz.config.EntryConstraint</code>.</li>
614
615 <li><i>agents</i>=&lt;ColocatedAgent[]&gt;
616 - is an array of initializers to be run against the Blitz proxy before it
617 is published via a join manager to lookup services. See the javadoc for
618 <code>org.dancres.blitz.remote.user.ColocatedAgent</code>.</li>
619
620 <li><i>updateContents</i>=&lt;boolean&gt; - Determines whether the contents methods on <code>JavaSpaceAdmin</code> and <code>JavaSpace05</code> update their working match sets with entry's written after the set was created. Note enabling this can mean that one never reaches the end of the match set or that the match set overflows memory if it fills faster than a client empties it.</li>
621
622 </ul>
623
624
625 <h3>Memory Management</h3>
626
627
628 <ul>
629
630
631 <li><i>desiredPendingWrites</i>=&lt;int&gt;
632 - the number of writes to batch for disk update.</li>
633
634
635 <li><i>throttlePendingWrites</i>=&lt;int&gt;
636 - the maximum number of writes to batch for disk update. If the queue
637 fills beyond this threshold (perhaps due to slow disks) throttling is
638 applied to foreground operations whilst disk catches up.</li>
639
640
641 <li><i>dbCache</i>=&lt;int&gt; - the max
642 size of cache Db is allowed (bigger being better).</li>
643
644
645 <li><i>maxDbTxns</i>=&lt;int&gt; - the
646 maximum number of transactions Db should support concurrently. Under
647 highly concurrent loads, increase this number.</li>
648
649
650 <li><i>entryReposCacheSize</i>=&lt;int&gt;
651 - the maximum number of Entry's (per type) to cache. This is a global
652 setting which can be overidden with individual Entry constraints - see
653 the Javadoc for <code>org.dancres.blitz.config.EntryConstraint</code>.</li>
654
655
656 <li><i>eventQueueBound</i>=&lt;int&gt; -
657 limits the maximum size of the notify event queue - once full, writing
658 threads will be throttled down to prevent overflow. Defaults to
659 0(disabled)</li>
660
661
662 <li><i>taskQueueBound</i>=&lt;int&gt; -
663 limits the maximum size of the task queue (used for processing new
664 writes against blocked takes or reads) - once full, writing threads
665 will be throttled down to prevent overflow. Defaults to 0(disabled)</li>
666
667
668 </ul>
669
670
671 <h3>Debug Options</h3>
672
673
674 <ul>
675
676
677 <li><i>ignoreLogConfig</i>=&lt;Boolean&gt;
678 - when true, causes Blitz to ignore any logger <code>Level</code>
679 entrys in it's configuration file. This allows a developer to use the
680 standard logger configuration approach when appropriate.</li>
681
682
683 <li><i>logCkpts</i>=&lt;Boolean&gt; - if
684 true, causes Blitz to generate a log message at each checkpoint</li>
685
686
687 <li><i>statsDump</i>=&lt;long&gt; - pause in milliseconds which determines how often the stats are dumped to console. Setting this to zero disables stats dumping.</li>
688
689
690 <li><i>stats</i>=&lt;Switch[]&gt; - Defines
691 the default
692 settings for stats gathering. See the Javadoc for <code>org.dancres.blitz.stats</code>.
693 This information is processed by Dashboard.</li>
694
695
696 </ul>
697
698
699 <p></p>
700
701
702 <div align="center"><a href="../index.html">Back
703 to Documentation</a></div>
704
705
706 </body>
707 </html>