1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
|
$Id$
This directory contains files that implement a server for the TAO
Notification Service. In addition, it contains files that run the TAO
Notification Service as a Windows NT Service. Both of these services
are described below.
How to Run the TAO Notification Service
=======================================
The Notify_Service executable starts up a Notification Service factory
and registers it with the Naming Service under the name
"NotifyEventChannelFactory"
Command line arguments:
----------------------
"-?" : shows the options.
"-Factory factory_name" : Uses the <factory_name> as the default name for the
Channel Factory
The default is "NotifyEventChannelFactory".
"-Boot" : Flag asking that the <factory_name> be registered
in the IOR table.
The option is disabled by default.
See the "Using the Boot option" section below.
"-NameSvc" : Registers the Factory and if specified, an Event
Channel with the Naming Service.
if this option is used, a Naming Service must
be accessible.
This option is enabled by default.
"-NoNameSvc" : Asks to skip any registration with the
Naming Service.
This option is disabled by default.
"-IORoutput file_name" : The IOR is output to the file <file_name>.
By default, the IOR is printed out.
"-Channel" : If this option is specified, a EventChannel is
created and registered with the Naming Service.
This option is disabled by default. This option can
be specified multiple times, each option will result
in a created and registered EventChannel
"-ChannelName channel_name" : Specifies the <channel_name> to register with the
Naming Service.
The default is "NotifyEventChannel".
"-RunThreads nthreads" : Number of threads to run the
ORB::run method.
"-UseSeparateDispatchingORB 1|0"
: Indicates whether the service should create and
and use a separate ORB dedicated to dispatching of
events.
"-ShutdownORB 1|0" : Indicates that we have to shutdown the default ORB,
1 by default
"-ShutdownDispatchingORB 1|0" : Indicates that we have to shutdown the
dispatching ORB, 1 by default
"-Timeout msec" : Applies a relative round-trip timeout of msec microseconds
to the main ORB and, if -UseSeparateDispatchingORB 1 is
specified, to the dispatching ORB. This requires the
'corba_messaging' MPC feature during building of the
Notify_Service, which is on by default.
"-LoggingInterval seconds" : Sets up a logging interval timer for the ORB's
reactor. This is required to use the ACE
Logging Service features such as file sizing
and rotation. See the example below.
!! The -Notify_TPReactor option is deprecated!! use the -ORBRunThreads
option instead.
"-Notify_TPReactor [threads]": Tells the Notify Service that the ORB
will use a TP reactor and specifies the
number of worker threads to utilize.
Note that the svc.conf file must instruct the ORB to use a TP reactor
e.g. static Resource_Factory "-ORBReactorType tp -ORBReactorMaskSignals 0"
Please look up the ORB configuration options to get more information
on this.
Running the Service:
-------------------
1. Start the Naming Service from
$TAO_ROOT/orbsvcs/Naming_Service/Naming_Service -m 1
if you are using the "-NameSvc" options.
2.Start the Notify_Service from this directory. You should see a message saying
that the service has been started.
Note:
====
By default, the Naming Service disables multicast discovery.
The "-m 1" option enables the Naming Service to be resolved via
multicast.
If you do not wish to do this, then use the
-ORBInitRef option in which case the Naming Service should be started
as:
$TAO_ROOT/orbsvcs/Naming_Service/Naming_Service -o naming.ior
and the Notify_Service as
$ Notify_Service -ORBInitRef NameService=file://naming.ior
Using the Boot option:
----------------------
an example on how to locate the Notify Factory without the Naming Service -
./Notify_Service -Boot -NoNameSvc -d -ORBobjrefstyle url -ORBEndPoint "iiop://flamenco.cs:9999"
The Factory object reference is not registered with the Naming Service.
"-Boot" binds the Factory object reference with "NotifyEventChannelFactory" in
the IOR table.
See the $TAO_ROOT/docs/Options.html for details on "-ORBEndPoint"
A client program can obtain the factory object reference in the following
manner:
./client -ORBInitRef "NotifyEventChannelFactory=corbaloc:iiop:flamenco.cs:9999/NotifyEventChannelFactory"
Note that the client uses:
resolve_initial_references ("NotifyEventChannelFactory");
to obtain the object reference.
Using the ACE Logging Service:
------------------------------
Start the Notify_Service executable with the debug options desired and
the -LoggingInterval option:
./Notify_Service -ORBDebugLevel 10 -ORBVerboseLogging 1 -ORBSvcConf ns.conf -LoggingInterval 5
Configure the logging service in the ns.conf file:
dynamic Logging_Strategy Service_Object * ACE:_make_ACE_Logging_Strategy() "-s NS -f OSTREAM -t 0 "
The svc.conf options:
----------------------
The "TAO_CosNotify_Service" service object accepts the following options:
"-AllocateTaskperProxy" : Allocate worker tasks per proxy
*see footnote below for explanation*
"-AllowReconnect" : Allows consumers and suppliers to
reconnect to existing proxies.
"-AsynchUpdates" : Send subscription and publication
updates asynchronously.
"-DefaultConsumerAdminFilterOp [op]" : Sets the default consumer admin filter
operator. op can be either "OR" or
"AND". The default is "OR" to be
consistent with older releases of TAO.
"-DefaultSupplierAdminFilterOp [op]" : Sets the default supplier admin filter
operator. op can be either "OR" or
"AND". The default is "OR" to be
consistent with older releases of TAO.
"-DispatchingThreads [thread_count]" : Enables MT dispatching with the
specified number of threads. This
option supercedes the deprecated
ListenerThreads, MTListenerEval and
MTDispatching options. Note that
"AllocateTaskperProxy" affects how this
value is applied.
"-NoUpdates" : Globally disables subscription and
publication updates.
"-ValidateClient" : Creates a thread that periodically
walks the topology tree visiting each
proxy and checking the liviness of
the peer. A peer which had ordinary
activity within the validation time
period is considered alive. Otherwise
the peer's _non_existent() operation
is invoked. If this fails the proxy's
disconnect operation is invoked.
"-ValidateClientDelay [sec]" : Specifies the initial delay from the
start of the validator task until the
first pass through the topology. If
left at the default value of 0, the
validator taks will start immediately.
A long delay is useful when the Notify
service restarts after a shutdown and
has to repopulate its topology from a
persistent store, which takes time.
"-ValidateClientInterval [sec]" : Specifies how frequently after the
first pass to revisit the topology
to further validate clients. The
default value of 0 means validation
will only happen once.
"-SourceThreads [thread_count]" : Specifies the number of threads for each
supplier admin or proxy consumer. See
the note below for details about thread
assignments. This option supercedes the
deprecated LookupThreads, MTSourceEval,
and MTLookup options.
All other options are deprecated and should not be used.
e.g. svc.conf
static TAO_CosNotify_Service "-DispatchingThreads 2"
This means that we want to enable event dispatching with 2 threads.
----------------------------------------------------------------
What does the "-AllocateTaskperProxy" option do?
A Task here implies a thread pool that performs a fixed work in the
Notify Service. e.g. When you specify "-DispatchingThreads 1" this
means there is 1 thread to perform the event dispatching to consumers
IRRESPECTIVE OF THE NUMBER OF PROXY SUPPLIERS. It also means that
events destined for each consumer will be queued to a buffer for that
consumer. Therefore, you can also think of this option as Enable
Consumer-side Buffering of Events.
This is the default case.
When you specify "-AllocateTaskperProxy" it asks notify to create a
dispatching task with the specified thread pool size PER PROXY
SUPPLIER. So if you use this option and connect 50 consumers with 1
thread for the dispatching task you will have created 50 dispatching
threads! so use this option with care and you might not need it in
most cases.
Why have this feature in the first place? The intent is to allow the
software architect of a Notify based system, fine control over where
and how much thread resources are deployed. e.g. a channel could have
2 proxy suppliers - the first one delivers an important event in huge
quantities. A dedicated thread pool to this proxy will ensure better
throughput to it's consumers. (Eventually I want to be able to set the
thread pool size via a QoS property)
Similarly "-SourceThreads 2" specifies a thread pool for use by the
supplier-side processing. This enables Buffering on the Supplier-side,
with the thread pool being used to process supplier side filters and
push the events to the Consumer side.
How to use the NT_Notify_Service
================================
To set the options for the TAO Notification Service, go to the Services
icon in the Settings group under the start menu (start menu ->
settings -> services). There, highlight the NT_Notify_Service, which
is the name used by the Notification Service when it is registered.
After it's highlighted, you should see at the bottom of the dialog box
an area to specify options. Just enter the options you wish in that
edit box and everything should just work. However, some options, such
as -ORBDebugLevel, won't work since an NT service can't write output
to standard out.
1. Syntax
% NT_Notify_Server [-i value]
[-r]
[-s]
[-k]
[-t n]
[-d]
2. Optional Command-line Arguments
-i value
Install this program as an NT service, with specified startup
-r
Remove this program from the Service Manager
-s
Start the service
-k
Kill the service
-t value
Set startup for an existing service
-d
Debug; run as a regular application
3. Usage
To see different stages of an NT service application, you have
to run the program several times, with different options.
Please note: run with only one option at a time.
a. First, you must initialize the service in the NT SCM
database. Run NT_Notify_Service with -in, where n is one of
the following startup options:
// Start Type (from WinNT.h)
//
#define SERVICE_SYSTEM_START 0x00000001
#define SERVICE_AUTO_START 0x00000002
#define SERVICE_DEMAND_START 0x00000003
#define SERVICE_DISABLED 0x00000004
If only -i is specified, SERVICE_AUTO_START is default option.
b. Now you are ready to run the actual service. Run
NT_Notify_Service again, this time with -s option. If the
service starts successfully, it will ring the system
bell every second or so until the service is stopped.
c. To stop service execution, run NT_Notify_Service with the
-k option.
d. To remove the service from the Service Control Manager
database, run NT_Notify_Service with -r.
In addition, once you have initialized this service (by using
the -i option) you can change its startup type to one of the
other values above. To do this, run NT_Notify_Service with
-tn option. n is as explained above for -i.
In order to debug the service's execution itself, use the -d
option.
|
