[omniORB] omniNotify bug #2 -- subscription_change bug

Robert E. Gruber gruber@research.att.com
Fri, 13 Oct 2000 17:00:24 -0400


Bug #2 is a bit more serious than bug #1.  The fix requires a change to the
subscription_change/offer_change mechanisms; details are below.

I am glad the problem was spotted so quickly after the release.  I will make
the changes and then release version 1.1 of omniNotify, since these changes
will be non-trivial.  I will try to do this by Wednesday of next week.

In the meantime, you can at least fix the problem test example by commenting
out the subscription_change call from struct_pull_consumer.cc (line 155) as
this call really has nothing to do with the test (it is a 'no op' as far as
what events the consumer receives).

Details, for the curious:

Consumers can change what event types they are interested in using a
subscription_change call (or by changing their registered filters).  The
channel tracks the global set of subscribed events across all consumers, and
whenever this global set changes, it informs all connected suppliers about
the change, also using subscription_change calls.   The reverse process
occurs for suppliers that inform the channel about events types they are
willing to supply : when the global set of offered types changes,
offer_change messages are sent to connected consumers.

Since any call to a client can take an arbitrary amount of time, 2 of our
design goals were: (1) use background threads for calling clients; (2) never
hold a critical lock while calling a client.  Thus, the channel should
propagate subscription change or offer change info to connected suppliers or
consumers using background thread(s) rather than using a thread of control
from some client call.  It also should not hold any critical locks while it
is calling subscription_change or offer_change on a client.  It appears that
we violated both of these design goals in the current implementation of the
subscription_change / offer_change mechanisms.

This is more than a bit embarrassing (!), but at least it was discovered
quickly.  I hope I can fix it equally quickly.

-- Bob

-----Original Message-----
From: owner-omninotify-list@uk.research.att.com
[mailto:owner-omninotify-list@uk.research.att.com] On Behalf Of
jon@totient.demon.co.uk
Sent: Thursday, October 12, 2000 4:54 PM
To: omninotify-list@uk.research.att.com
Cc: Robert E. Gruber
Subject: [omniNotify] maybe omniNotify bug #2


The structured_push supplier/consumer example seems to hang

I start notifd
notifd  -i -c /etc/omniNotify.cfg

and then the consumer
struct_pull_consumer -v -d5000

and then the suplier
struct_push_supplier -v -d5000

the log for the supplier is thus
Resolving reference to: 'NameService'
Resolving reference to: 'EventChannel'
Releasing reference to: 'NameService'
Creating new SupplierAdmin object
Created SupplierAdmin with ID 2
Creating proxy for StructuredConsumer
Created proxy with ID 1
Register with BOA to receive requests
Connecting consumer object to proxy
Informing channel about supplied event types
Pushed structured event: 0
Pushed structured event: 1
Pushed structured event: 2
Pushed structured event: 3
Pushed structured event: 4
Pushed structured event: 5
Pushed structured event: 6
Pushed structured event: 7
Pushed structured event: 8
Pushed structured event: 9


and for the consumer

# events to be consumed = 5000
Resolving reference to: 'NameService'
Resolving reference to: 'EventChannel'
Creating new ConsumerAdmin object
Created ConsumerAdmin with ID 1
Creating proxy for StructuredSupplier
Created proxy with ID 1
Connecting consumer object to proxy
   0 : Stock::Ticker
   1 : Stock::Ticker
   2 : Stock::Ticker
   3 : Stock::Ticker
   4 : Stock::Ticker
   5 : Stock::Ticker
   6 : Stock::Ticker
   7 : Stock::Ticker
   8 : Stock::Ticker
   9 : Stock::Ticker

 and if i type debug in the notifd interactive prompt it just hangs
like :-

notifd: stats

Channel: 0 queue sizes: global -1 proxy -1 notif -1
	DELTA: #announ 10 #notifs 0 #rdi_match 0 #rvm_evals 0
	       time 77051 msecs : 0.129784 a/sec 0 n/sec 0.129784 a+n/sec
	CUM:   #announ 10 #notifs 0 #rdi_match 0 #rvm_evals 0
	       time 77051 msecs : 0.129784 a/sec 0 n/sec  0.129784 a+n/sec

notifd: debug

Seems to always hang after 10 events....

Jon

------------------------------------------------------------------------
To unsubscribe, send a message to majordomo@uk.research.att.com
with the line (in the message body): unsubscribe omninotify-list
See: http://www.research.att.com/~ready/omniNotify/nfy_keep_in_touch.html
------------------------------------------------------------------------