Mercurial > hg > blitz_condensed
comparison docs/install_guide.html @ 0:3dc0c5604566
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>. 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>=<string> - the | |
438 directory in which blitz will keep checkpointed state.</li> | |
439 | |
440 | |
441 <li><i>logDir</i>=<string> - 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>=<type> - 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>=<string> - 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>=<LoginContext> | |
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>=<Boolean> | |
470 - see Administration section above.</li> | |
471 | |
472 | |
473 <li><i>initialGroups</i>=<String[]> - | |
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>=<LookupLocator[]> | |
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>=<Entry[]> - | |
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>=<Exporter> | |
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>=<ProxyPreparer> | |
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>=<ProxyPreparer> | |
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>=<Exporter> | |
506 - configures and enables the loopback transaction manager which can be | |
507 used to accelerate transactions against this Blitz instance. | |
508 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>=<boolean> - 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>=<int> - | |
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>=<int> | |
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>=<int> | |
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>=<long> - | |
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>=<long> - | |
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>=<long> - | |
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>=<int[]> - | |
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>=<int> - | |
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>=<int> - | |
598 should not be changed from the default value of 1.</li> | |
599 | |
600 | |
601 <li><i>threadKeepAlive</i>=<long> - | |
602 ms before a write thread will be killed rather than pooled.</li> | |
603 | |
604 | |
605 <li><i>maxTaskThreads</i>=<int> - the | |
606 maximum number of threads allowed for a task pool.</li> | |
607 | |
608 | |
609 <li><i>entryReposReadahead</i>=<int> | |
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>=<ColocatedAgent[]> | |
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>=<boolean> - 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>=<int> | |
632 - the number of writes to batch for disk update.</li> | |
633 | |
634 | |
635 <li><i>throttlePendingWrites</i>=<int> | |
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>=<int> - the max | |
642 size of cache Db is allowed (bigger being better).</li> | |
643 | |
644 | |
645 <li><i>maxDbTxns</i>=<int> - 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>=<int> | |
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>=<int> - | |
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>=<int> - | |
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>=<Boolean> | |
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>=<Boolean> - if | |
684 true, causes Blitz to generate a log message at each checkpoint</li> | |
685 | |
686 | |
687 <li><i>statsDump</i>=<long> - 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>=<Switch[]> - 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> |