| Field |
Value |
| Bugzilla ID |
565 |
| Reporter |
Carlos O'Ryan |
| Assigned to |
DOC Center Support List (internal) |
| Product |
TAO |
| Component |
Real-Time Event Service |
| Version |
1.1.2 |
| Platform / OS |
All / All |
| Priority |
P2 |
| Severity |
normal |
| Status |
ASSIGNED |
| Resolution |
|
| Created |
2000-05-11 17:25:13 -0500 |
Originally posted by Carlos O'Ryan on 2000-05-11 17:25:14 -0500
In some dispatching strategies the event service uses one or more queues
serviced by dispatching
threads. The maximum size of said queues is currently hard-coded. It should be
selectable with
at least the following options:
- No limit
- Max number of messages
- Max total size (can we measure that?)
once the maximum is reached the queue simply flows controls the suppliers. In
some applications
we may wish to drop events, for example:
- The oldest events are dropped to make room for the new one.
- or the the events with lowest priority
this last aspect should probably be controlled using some application specific
strategy,
because there may be multiple different criteria to drop the events.
Originally posted by Carlos O'Ryan on 2000-05-11 17:25:14 -0500
In some dispatching strategies the event service uses one or more queues
serviced by dispatching
threads. The maximum size of said queues is currently hard-coded. It should be
selectable with
at least the following options:
once the maximum is reached the queue simply flows controls the suppliers. In
some applications
we may wish to drop events, for example:
this last aspect should probably be controlled using some application specific
strategy,
because there may be multiple different criteria to drop the events.