From dpg1@grisby.org Mon May 27 10:35:57 2002 Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id g4R9Zvu00825 for ; Mon, 27 May 2002 10:35:57 +0100 Received: from pc1-camc4-0-cust148.cam.cable.ntl.com ([80.2.246.148]) by mta03-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020527093559.GFKL295.mta03-svc.ntlworld.com@pc1-camc4-0-cust148.cam.cable.ntl.com> for ; Mon, 27 May 2002 10:35:59 +0100 Received: from grisby.org (dpg1@localhost) by pc1-camc4-0-cust148.cam.cable.ntl.com (8.11.2/8.11.2) with ESMTP id g4R9Zwi23825 for ; Mon, 27 May 2002 10:35:58 +0100 Message-Id: <200205270935.g4R9Zwi23825@pc1-camc4-0-cust148.cam.cable.ntl.com> X-Authentication-Warning: pc1-camc4-0-cust148.cam.cable.ntl.com: dpg1 owned process doing -bs To: omninotify-list@realvnc.com From: Duncan Grisby Subject: [omniNotify] omniNotify mailing list's new home Sender: omninotify-list-admin@realvnc.com Errors-To: omninotify-list-admin@realvnc.com X-BeenThere: omninotify-list@realvnc.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: Date: Mon May 27 10:38:01 2002 X-Original-Date: Mon, 27 May 2002 10:35:58 +0100 Hi, As some of you have already noticed, the omniNotify mailing list has a new home, courtesy of realvnc.com. The plan to host it at the Cambridge University Engineering department didn't work out, so our VNC friends are helping out. With any luck, we'll manage to get back control of the omniorb.org domain, at which point the list address can revert to @omniorb.org. The list is now run with Mailman rather than Majordomo, so the subscription interface is different. You can control your membership through this web page: http://www.realvnc.com/mailman/listinfo/omninotify-list To modify your settings, you need to know your password, which of course you won't. To find out what it is, go to that page and type your email address in to the box at the bottom. Click on "Edit Option", and you'll get to a page that includes an option to have your password emailed to you. If you have any problems let me know. Unfortunately, due to a slight mishap, we lost the mailing list archives. If anyone happens to have a reasonably complete copy of the mailing list archive, please let me know. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From tvedt@noao.edu Mon Jul 15 20:54:11 2002 Received: from noao.edu (email.tuc.noao.edu [140.252.1.54]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id g6FJs8T09522 for ; Mon, 15 Jul 2002 20:54:09 +0100 Received: from pertelote.tuc.noao.edu ([140.252.38.2] verified) by noao.edu (CommuniGate Pro SMTP 3.5.9) with ESMTP id 4719931 for omninotify-list@realvnc.com; Mon, 15 Jul 2002 12:54:05 -0700 Received: from pertelote.tuc.noao.edu (pertelote.tuc.noao.edu [140.252.38.2]) by pertelote.tuc.noao.edu (8.9.1/8.9.1/SAG-04Feb01) with SMTP id MAA26785 for ; Mon, 15 Jul 2002 12:54:05 -0700 (MST) Message-Id: <200207151954.MAA26785@pertelote.tuc.noao.edu> From: Janet Tvedt Reply-To: Janet Tvedt To: omninotify-list@realvnc.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: wQwiBA06DfrZkBheHE4Xtw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Subject: [omniNotify] performance questions Sender: omninotify-list-admin@realvnc.com Errors-To: omninotify-list-admin@realvnc.com X-BeenThere: omninotify-list@realvnc.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: Date: Mon Jul 15 22:14:24 2002 X-Original-Date: Mon, 15 Jul 2002 12:54:05 -0700 (MST) From the documentation it appears that omniNotify does honor priority and timeout values for events that it receives. Is this true? Also, is there an easy way to support a "pull event period" of "on demand"? I have not tried using pull functionality with omniNotify because it was distastrous with the event service implementations I tried. In some cases (well, in my world anyway) a pull consumer may require an update once or twice in its lifetime, so continuous polling is overkill. Any ideas? Thanks! Janet -------------------------------------------------------------------------- Janet Tvedt, National Solar Observatory/SOLIS Email: tvedt@noao.edu P.O. Box 26732, Tucson, AZ 85732-6732 Phone: (520) 318-8388 950 N. Cherry Ave., Tucson, AZ 85719 FAX: (520) 318-8278 From gruber@research.att.com Mon Jul 15 23:23:53 2002 Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id g6FMNqT16708 for ; Mon, 15 Jul 2002 23:23:52 +0100 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 8A6CF4CE78; Mon, 15 Jul 2002 18:23:51 -0400 (EDT) Received: from pcgruber (pc-gruber.research.att.com [135.207.23.156]) by bigmail.research.att.com (8.8.8/8.8.8) with SMTP id SAA26071; Mon, 15 Jul 2002 18:23:51 -0400 (EDT) From: "Robert E. Gruber" To: "Janet Tvedt" , Cc: "Robert E. Gruber" Subject: RE: [omniNotify] performance questions Message-ID: <007201c22c4e$34639d50$9c17cf87@pcgruber> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <200207151954.MAA26785@pertelote.tuc.noao.edu> Sender: omninotify-list-admin@realvnc.com Errors-To: omninotify-list-admin@realvnc.com X-BeenThere: omninotify-list@realvnc.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: Date: Mon Jul 15 23:24:01 2002 X-Original-Date: Mon, 15 Jul 2002 18:23:11 -0400 > From the documentation it appears that omniNotify does honor priority and > timeout values for events that it receives. Is this true? Yes, omniNotify supports OrderPolicy and DiscardPolicy, and the settings of PriorityOrder and DeadlineOrder are used to indicate control based on Priority or Timeout values, respectively. omniNotify applies these policies at the level of individual consumer queues; it does not support a DiscardPolicy based on Priority or Timeout at the global incoming event queue. OrderPolicy is only relevant if the channel has more than one event queued up for a given consumer. This happens for both push and pull batch consumers, and also for single-event pull consumers. For single-event push consumers, the queue size is normally 1 or 0 because events are pushed out of the queue immediately after they are added, so OrderPolicy does not have any effect. DiscardPolicy is only relevant if MaxEventsPerConsumer is set to positive value K, and K+1 events have been queued up for a given consumer. In this case, DiscardPolicy controls which of the K+1 events is discarded to return the queue size to K. > Also, is there an easy way to support a "pull event period" of "on demand"? > I have not tried using pull functionality with omniNotify because it was > distastrous with the event service implementations I tried. In some cases > (well, in my world anyway) a pull consumer may require an update once or > twice in its lifetime, so continuous polling is overkill. Any ideas? I'm not sure what you are asking for. PullEventPeriod applies to pull suppliers, and it is a millisecond-based control. Are you saying that instead of, say, pulling every 100 milliseconds, an "on-demand" pull supplier would only be polled by the channel if a pull-style consumer did a pull or try_pull call? One way to implement something like this without changing omniNotify is to use push suppliers/consumers and to have an extra event type that is used to request an event push. E.g., have event type SomeDomain::Foo for foo events, and use SomeDomain::NeedFoo to signal that a Foo event is needed. A push consumer could register for Foo events, and could push a NeedFoo event to the channel when it needs a Foo event. A push supplier could register as a consumer of NeedFoo events, and for each one it receives, it would push a Foo event to the channel. If I did not understand what you need, please send more details. -- Bob -----Original Message----- From: omninotify-list-admin@realvnc.com [mailto:omninotify-list-admin@realvnc.com]On Behalf Of Janet Tvedt Sent: Monday, July 15, 2002 3:54 PM To: omninotify-list@realvnc.com Subject: [omniNotify] performance questions From the documentation it appears that omniNotify does honor priority and timeout values for events that it receives. Is this true? Also, is there an easy way to support a "pull event period" of "on demand"? I have not tried using pull functionality with omniNotify because it was distastrous with the event service implementations I tried. In some cases (well, in my world anyway) a pull consumer may require an update once or twice in its lifetime, so continuous polling is overkill. Any ideas? Thanks! Janet -------------------------------------------------------------------------- Janet Tvedt, National Solar Observatory/SOLIS Email: tvedt@noao.edu P.O. Box 26732, Tucson, AZ 85732-6732 Phone: (520) 318-8388 950 N. Cherry Ave., Tucson, AZ 85719 FAX: (520) 318-8278 _______________________________________________ omninotify-list mailing list omninotify-list@realvnc.com http://www.realvnc.com/mailman/listinfo/omninotify-list From tvedt@noao.edu Thu Sep 5 00:12:23 2002 Received: from realvnc.com ([213.239.45.162]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id g84NCN816325 for ; Thu, 5 Sep 2002 00:12:23 +0100 Received: from noao.edu (noao.edu [140.252.1.54]) by realvnc.com (8.11.6/8.11.6) with ESMTP id g84NDKx04700 for ; Thu, 5 Sep 2002 00:13:20 +0100 Received: from pertelote.tuc.noao.edu ([140.252.38.2] verified) by noao.edu (CommuniGate Pro SMTP 4.0b7) with ESMTP id 5154382 for omninotify-list@realvnc.com; Wed, 04 Sep 2002 16:12:25 -0700 Received: from pertelote.tuc.noao.edu (pertelote.tuc.noao.edu [140.252.38.2]) by pertelote.tuc.noao.edu (8.9.1/8.9.1/SAG-04Feb01) with SMTP id QAA05887 for ; Wed, 4 Sep 2002 16:12:25 -0700 (MST) Message-Id: <200209042312.QAA05887@pertelote.tuc.noao.edu> From: Janet Tvedt Reply-To: Janet Tvedt To: omninotify-list@realvnc.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ULSya4AYSZCXOpF3ThEyZw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Subject: [omniNotify] obtain_offered_types Sender: omninotify-list-admin@omniorb-support.com Errors-To: omninotify-list-admin@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: Date: Thu Sep 5 00:13:00 2002 X-Original-Date: Wed, 4 Sep 2002 16:12:24 -0700 (MST) Is obtain_offered_types() in the following interface supported by omniNotify? It doesn't appear to return anything, although obtain_subscription_types() does. interface EventChannel : CosNotifyChannelAdmin::EventChannel { CosNotification::EventTypeSeq obtain_subscription_types(); CosNotification::EventTypeSeq obtain_offered_types(); ... } -------------------------------------------------------------------------- Janet Tvedt, National Solar Observatory/SOLIS Email: tvedt@noao.edu P.O. Box 26732, Tucson, AZ 85732-6732 Phone: (520) 318-8388 950 N. Cherry Ave., Tucson, AZ 85719 FAX: (520) 318-8278 From gruber@research.att.com Thu Sep 5 14:50:35 2002 Received: from realvnc.com ([213.239.45.162]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id g85DoZ821076 for ; Thu, 5 Sep 2002 14:50:35 +0100 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by realvnc.com (8.11.6/8.11.6) with ESMTP id g85DpWx09737 for ; Thu, 5 Sep 2002 14:51:32 +0100 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id DC1F74CE29; Thu, 5 Sep 2002 09:50:31 -0400 (EDT) Received: from pcgruber (pc-gruber.research.att.com [135.207.23.156]) by bigmail.research.att.com (8.8.8/8.8.8) with SMTP id JAA09629; Thu, 5 Sep 2002 09:50:30 -0400 (EDT) From: "Robert E. Gruber" To: "Janet Tvedt" , Cc: "Robert E. Gruber" Subject: RE: [omniNotify] obtain_offered_types Message-ID: <000001c254e2$fc1ac4b0$9c17cf87@pcgruber> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-reply-to: <200209042312.QAA05887@pertelote.tuc.noao.edu> Sender: omninotify-list-admin@omniorb-support.com Errors-To: omninotify-list-admin@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: Date: Thu Sep 5 14:51:02 2002 X-Original-Date: Thu, 5 Sep 2002 09:48:58 -0400 obtain_offered_types returns the types that have been 'offered' by one or more suppliers using the offer_change method. If no suppliers have invoked offer_change with a list of types that they supply, then obtain_offered_types will not return anything. Suppliers can supply events of arbitrary type without 'offering' them first, so many users of the notification service do not bother to use the offer_change mechanism. In fact, I'm curious: is anybody using it? The AttN::EventChannel interface has the function you mentioned for admin/monitoring purposes, as a a one-time get of the current offered types set. A consumer that wants to know about offered types should use the proxy-level obtain_offered_types call, which has this signature: CosN::EventTypeSeq* obtain_offered_types(CosNA::ObtainInfoMode mode) The mode indicates 2 things: whether this is actually a request for the offered types, and whether the consumer wishes to be informed of future changes to the set of offered types. Thus the four modes are: CosNA::NONE_NOW_UPDATES_OFF : do not return current offered types, and do not send future offer_change updates CosNA::NONE_NOW_UPDATES_ON : do not return current offered types, but send future offer_change updates CosNA::ALL_NOW_UPDATES_OFF : send current offered types, but do not send future offer_change updates CosNA::ALL_NOW_UPDATES_ON : send current offered types, and send future offer_change updates A bit of a warning: due to the asynchronous nature of the service, using offer_change messages to control consumer interest can be a bit tricky. For example, if a supplier announces a new event type T using offer_change, and then immediately starts supplying T events, by the time a consumer learns of the type T offer and adds a subscription for it, some of the newly announced T events may already have been processed by the channel. If the intent was that the consumer should get all T events, then either the consumer should always be registered for T events, or the supplier needs to wait for a 'reasonable' amount of time before it starts to supply T events. -- Bob -----Original Message----- From: omninotify-list-admin@omniorb-support.com [mailto:omninotify-list-admin@omniorb-support.com]On Behalf Of Janet Tvedt Sent: Wednesday, September 04, 2002 7:12 PM To: omninotify-list@realvnc.com Subject: [omniNotify] obtain_offered_types Is obtain_offered_types() in the following interface supported by omniNotify? It doesn't appear to return anything, although obtain_subscription_types() does. interface EventChannel : CosNotifyChannelAdmin::EventChannel { CosNotification::EventTypeSeq obtain_subscription_types(); CosNotification::EventTypeSeq obtain_offered_types(); ... } -------------------------------------------------------------------------- Janet Tvedt, National Solar Observatory/SOLIS Email: tvedt@noao.edu P.O. Box 26732, Tucson, AZ 85732-6732 Phone: (520) 318-8388 950 N. Cherry Ave., Tucson, AZ 85719 FAX: (520) 318-8278 _______________________________________________ omninotify-list mailing list omninotify-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omninotify-list From tvedt@noao.edu Sat Oct 5 01:36:26 2002 Received: from realvnc.com ([213.239.45.162]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id g950aQ805263 for ; Sat, 5 Oct 2002 01:36:26 +0100 Received: from noao.edu (email.tuc.noao.edu [140.252.1.54]) by realvnc.com (8.11.6/8.11.6) with ESMTP id g950cA510831 for ; Sat, 5 Oct 2002 01:38:10 +0100 Received: from pertelote.tuc.noao.edu ([140.252.38.2] verified) by noao.edu (CommuniGate Pro SMTP 4.0b8) with ESMTP id 5438306 for omninotify-list@realvnc.com; Fri, 04 Oct 2002 17:36:18 -0700 Received: from pertelote.tuc.noao.edu (pertelote.tuc.noao.edu [140.252.38.2]) by pertelote.tuc.noao.edu (8.9.1/8.9.1/SAG-04Feb01) with SMTP id RAA12117 for ; Fri, 4 Oct 2002 17:36:08 -0700 (MST) Message-Id: <200210050036.RAA12117@pertelote.tuc.noao.edu> From: Janet Tvedt Reply-To: Janet Tvedt To: omninotify-list@realvnc.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 9U95RKWGGuwtQRiC7dxZBg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Subject: [omniNotify] org.omg.CosNotifyComm.InvalidEventType Sender: omninotify-list-admin@omniorb-support.com Errors-To: omninotify-list-admin@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: Date: Sat Oct 5 01:37:00 2002 X-Original-Date: Fri, 4 Oct 2002 17:36:08 -0700 (MST) I am getting an org.omg.CosNotifyComm.InvalidEventType exception when a StructuredPushSupplier calls offer_change with an EventType("foo.bar", "baz"). However, EventType("foo", "baz") works fine. This dotted naming scheme is working fine for sending/receiving structured events, even with filters. So I am puzzled as to why it doesn't work in this context. Any ideas? -------------------------------------------------------------------------- Janet Tvedt, National Solar Observatory/SOLIS Email: tvedt@noao.edu P.O. Box 26732, Tucson, AZ 85732-6732 Phone: (520) 318-8388 950 N. Cherry Ave., Tucson, AZ 85719 FAX: (520) 318-8278 From gruber@research.att.com Mon Oct 7 18:03:26 2002 Received: from realvnc.com ([213.239.45.162]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id g97H3P808401 for ; Mon, 7 Oct 2002 18:03:26 +0100 Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by realvnc.com (8.11.6/8.11.6) with ESMTP id g97H5N507490 for ; Mon, 7 Oct 2002 18:05:23 +0100 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id AEC194CE6F; Mon, 7 Oct 2002 13:03:20 -0400 (EDT) Received: from pcgruber (pc-gruber.research.att.com [135.207.23.156]) by bigmail.research.att.com (8.8.8/8.8.8) with SMTP id NAA23116; Mon, 7 Oct 2002 13:03:18 -0400 (EDT) From: "Robert E. Gruber" To: "Janet Tvedt" , Cc: "Robert E. Gruber" Subject: RE: [omniNotify] org.omg.CosNotifyComm.InvalidEventType Message-ID: <000801c26e23$25281610$9c17cf87@pcgruber> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <200210050036.RAA12117@pertelote.tuc.noao.edu> Sender: omninotify-list-admin@omniorb-support.com Errors-To: omninotify-list-admin@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: Date: Mon Oct 7 18:04:00 2002 X-Original-Date: Mon, 7 Oct 2002 13:01:14 -0400 Janet, thanks for pointing this out, I think you found something that is not implemented correctly. offer_change/subscription_change both check that the lists of added/deleted event types are 'valid'. Currently this check is probably too restrictive: other than special forms (such as '*', '%ALL', '%TYPED') only names that consist of alphanumerics and underscore are accepted. I believe the main issue is that wildcards together with other chars (such as "foo*" or "*foo" or "foo*bar") should be rejected because the only wildcard support at the moment is when just '*' by itself is used. I think dot notation *should* be allowed, and probably any string that does not include a wildcard (plus other chars) should be allowed. (I could not find any restrictions on the strings used as domain/type name in the spec, but I only scanned it for about 10 minutes before giving up. If someone knows of any restrictions, please let me know.) So, I will make an update and post something when it is available. -- Bob P.S. Not tested yet, but I am 99% sure the fix is to remove these 30 lines from RDIEvent.h: if ( RDI_STR_NEQ(tseq[ix].type_name, "*") && RDI_STR_NEQ(tseq[ix].type_name, "%ANY") && RDI_STR_NEQ(tseq[ix].type_name, "%TYPED") ) { // first char must be alpha or underscore if (!RDI_IS_ALPHA_OR_UNDERSCORE(tseq[ix].type_name[(CORBA::ULong)0])) { invalid_index = ix; return 0; } // remaining chars must be alphanum or underscore for (i = 1; i < RDI_STRLEN(tseq[ix].type_name); i++) { if ( !RDI_IS_ALPHANUM_OR_UNDERSCORE(tseq[ix].type_name[i]) ) { invalid_index = ix; return 0; } } } if ( RDI_STR_NEQ(tseq[ix].domain_name, "*") ) { // first char must be alpha or underscore if (!RDI_IS_ALPHA_OR_UNDERSCORE(tseq[ix].domain_name[(CORBA::ULong)0])) { invalid_index = ix; return 0; } // remaining chars must be alphanum or underscore for (i = 1; i < RDI_STRLEN(tseq[ix].domain_name); i++) { if ( !RDI_IS_ALPHANUM_OR_UNDERSCORE(tseq[ix].domain_name[i]) ) { invalid_index = ix; return 0; } } } -----Original Message----- From: omninotify-list-admin@omniorb-support.com [mailto:omninotify-list-admin@omniorb-support.com]On Behalf Of Janet Tvedt Sent: Friday, October 04, 2002 8:36 PM To: omninotify-list@realvnc.com Subject: [omniNotify] org.omg.CosNotifyComm.InvalidEventType I am getting an org.omg.CosNotifyComm.InvalidEventType exception when a StructuredPushSupplier calls offer_change with an EventType("foo.bar", "baz"). However, EventType("foo", "baz") works fine. This dotted naming scheme is working fine for sending/receiving structured events, even with filters. So I am puzzled as to why it doesn't work in this context. Any ideas? -------------------------------------------------------------------------- Janet Tvedt, National Solar Observatory/SOLIS Email: tvedt@noao.edu P.O. Box 26732, Tucson, AZ 85732-6732 Phone: (520) 318-8388 950 N. Cherry Ave., Tucson, AZ 85719 FAX: (520) 318-8278 _______________________________________________ omninotify-list mailing list omninotify-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omninotify-list From Matthew.Berry@aspentech.com Tue Oct 8 15:23:17 2002 Received: from ukcmailgwi1.atuk.aspentech.com (nat20895-108.aspentech.com [208.201.95.108]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id g98ENH829734 for ; Tue, 8 Oct 2002 15:23:17 +0100 Received: by UKCMAILGWI1 with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Oct 2002 15:23:16 +0100 Message-ID: <4E6024B5C5C7D51185650002B330B4B85AF67D@londonmail.lon.aspentech.com> From: Matthew Berry To: omninotify-list@omniorb-support.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [omniNotify] Development Status Sender: omninotify-list-admin@omniorb-support.com Errors-To: omninotify-list-admin@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: Date: Tue Oct 8 15:24:00 2002 X-Original-Date: Tue, 8 Oct 2002 15:23:14 +0100 Bob, Can you please give us an update on the development currently underway for omniNotify. When is the next release and what is it likely to contain? Thanks Matthew From gruber@research.att.com Thu Oct 10 15:19:40 2002 Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id g9AEJd821396 for ; Thu, 10 Oct 2002 15:19:40 +0100 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id C94554CE29; Thu, 10 Oct 2002 10:19:36 -0400 (EDT) Received: from pcgruber (pc-gruber.research.att.com [135.207.23.156]) by bigmail.research.att.com (8.8.8/8.8.8) with SMTP id KAA24609; Thu, 10 Oct 2002 10:19:36 -0400 (EDT) From: "Robert E. Gruber" To: "Matthew Berry" , Cc: "Robert E. Gruber" Subject: RE: [omniNotify] Development Status Message-ID: <000d01c27067$c4551d50$9c17cf87@pcgruber> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4E6024B5C5C7D51185650002B330B4B85AF67D@londonmail.lon.aspentech.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Sender: omninotify-list-admin@omniorb-support.com Errors-To: omninotify-list-admin@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: Date: Thu Oct 10 15:20:00 2002 X-Original-Date: Thu, 10 Oct 2002 10:17:29 -0400 Unfortunately, I have a lot less time for omniNotify development than I used to. Perhaps I've been somewhat in denial about this which is why I haven't mentioned it earlier. This means any major new features will not happen without outside help. Below are the things I still plan to do this year myself (although I do ask for autoconf help :->)... The official omniNotify 2.0 release will be just like the current 2.0.ALPHA release (plus the small fix recently requested by Janet), except I think it would be good to get autoconf support working. Right now you need to use the older omniORB build scheme. Is there anyone out there with autoconf expertise willing to do this part of the project for me? I am really pressed for time at the moment. The next step, for omniNotify 2.1, is to do a Windows NT/2000 port. As others have pointed out recently, you can run the notification daemon, notifd, on a linux/other box and run all of the suppliers and consumers that you like on Windows boxen, so it is not a total loss for Windows folks that there is no Windows port yet for the notification daemon. Of course some people want to run everything on one machine, so a port would be nice. I cannot give a time frame for this port as my other work keeps piling up, and I have to take care of that first. It looks like I will have time to work on this in December. If I start working on it sooner than that I will send out another note indicating when I expect to get something out. -- Bob -----Original Message----- From: omninotify-list-admin@omniorb-support.com [mailto:omninotify-list-admin@omniorb-support.com]On Behalf Of Matthew Berry Sent: Tuesday, October 08, 2002 10:23 AM To: omninotify-list@omniorb-support.com Subject: [omniNotify] Development Status Bob, Can you please give us an update on the development currently underway for omniNotify. When is the next release and what is it likely to contain? Thanks Matthew _______________________________________________ omninotify-list mailing list omninotify-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omninotify-list From Matthew.Berry@aspentech.com Thu Oct 10 15:27:58 2002 Received: from ukcmailgwi1.atuk.aspentech.com (nat20895-219.aspentech.com [208.201.95.219]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id g9AERw821782 for ; Thu, 10 Oct 2002 15:27:58 +0100 Received: by ukcmailgwi1.atuk.aspentec.com with Internet Mail Service (5.5.2653.19) id <4S3AJH1X>; Thu, 10 Oct 2002 15:27:45 +0100 Message-ID: <4E6024B5C5C7D51185650002B330B4B85AF787@londonmail.lon.aspentech.com> From: Matthew Berry To: "Robert E. Gruber" , omninotify-list@omniorb-support.com Subject: RE: [omniNotify] Development Status MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: omninotify-list-admin@omniorb-support.com Errors-To: omninotify-list-admin@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: Date: Thu Oct 10 15:28:00 2002 X-Original-Date: Thu, 10 Oct 2002 15:27:43 +0100 Bob, Thanks for your reply - glad to hear omniNotify is still being worked on, albeit slowly. Correct me if I am wrong, by I don't think omniNotify supports persistent events at the moment. Have you considered this for future development? Thanks again Matthew > -----Original Message----- > From: Robert E. Gruber [mailto:gruber@research.att.com] > Sent: 10 October 2002 15:17 > To: Matthew Berry; omninotify-list@omniorb-support.com > Cc: Robert E. Gruber > Subject: RE: [omniNotify] Development Status > > > Unfortunately, I have a lot less time for omniNotify development > than I used to. Perhaps I've been somewhat in denial about this > which is why I haven't mentioned it earlier. > > This means any major new features will not > happen without outside help. Below are the things I still plan > to do this year myself (although I do ask for autoconf help :->)... > > The official omniNotify 2.0 release will be just like the > current 2.0.ALPHA release (plus the small > fix recently requested by Janet), except I think it would be > good to get autoconf support working. Right now you need > to use the older omniORB build scheme. > > Is there anyone out there with autoconf expertise willing > to do this part of the project for me? I am really pressed > for time at the moment. > > The next step, for omniNotify 2.1, is to do a > Windows NT/2000 port. > > As others have pointed out recently, > you can run the notification daemon, notifd, > on a linux/other box and run all of the suppliers > and consumers that you like on Windows boxen, so it is > not a total loss for Windows folks that there is no Windows > port yet for the notification daemon. Of course > some people want to run everything on one machine, so > a port would be nice. > > I cannot give a time frame for this port > as my other work keeps piling up, > and I have to take care of that first. > It looks like I will have time to work > on this in December. If I start working on it sooner > than that I will send out another > note indicating when I expect to get something out. > > -- Bob > > -----Original Message----- > From: omninotify-list-admin@omniorb-support.com > [mailto:omninotify-list-admin@omniorb-support.com]On Behalf Of Matthew > Berry > Sent: Tuesday, October 08, 2002 10:23 AM > To: omninotify-list@omniorb-support.com > Subject: [omniNotify] Development Status > > Bob, > > Can you please give us an update on the development currently > underway for > omniNotify. When is the next release and what is it likely to contain? > > Thanks > Matthew > _______________________________________________ > omninotify-list mailing list > omninotify-list@omniorb-support.com > http://www.omniorb-support.com/mailman/listinfo/omninotify-list > From gruber@research.att.com Thu Oct 10 15:48:44 2002 Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id g9AEmh822701 for ; Thu, 10 Oct 2002 15:48:43 +0100 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id EA44D4CE5D; Thu, 10 Oct 2002 10:48:40 -0400 (EDT) Received: from pcgruber (pc-gruber.research.att.com [135.207.23.156]) by bigmail.research.att.com (8.8.8/8.8.8) with SMTP id KAA28895; Thu, 10 Oct 2002 10:48:40 -0400 (EDT) From: "Robert E. Gruber" To: "Matthew Berry" Cc: "Robert E. Gruber" , Subject: RE: [omniNotify] Development Status Message-ID: <000e01c2706b$d3e00240$9c17cf87@pcgruber> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4E6024B5C5C7D51185650002B330B4B85AF787@londonmail.lon.aspentech.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Sender: omninotify-list-admin@omniorb-support.com Errors-To: omninotify-list-admin@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: Date: Thu Oct 10 15:49:00 2002 X-Original-Date: Thu, 10 Oct 2002 10:46:33 -0400 Yes, reliability and persistence are two things that I would love to work on. I almost put them down except I wanted to stick to things I know I can get done in 2002. The other thing I did not put down is performance improvements. With omniORB4 there are some very interesting things one could do. (I think omniNotify is already fast compared to some other notification services, but making it even faster would be fun.) Some obvious approaches to event persistence are: 1. use the file system 2. use an open source DB directly 3. drive any DB using an open source ODBC driver I suspect these options are ordered from fastest to slowest (but least to most flexible), but I would have to do experiments to find out. Work on this is not happening soon, I'm afraid, unless someone else does it. -- Bob -----Original Message----- From: Matthew Berry [mailto:Matthew.Berry@aspentech.com] Sent: Thursday, October 10, 2002 10:28 AM To: Robert E. Gruber; omninotify-list@omniorb-support.com Subject: RE: [omniNotify] Development Status Bob, Thanks for your reply - glad to hear omniNotify is still being worked on, albeit slowly. Correct me if I am wrong, by I don't think omniNotify supports persistent events at the moment. Have you considered this for future development? Thanks again Matthew From goetz@esrf.fr Thu Jan 30 08:48:47 2003 Received: from out.esrf.fr (firewall.esrf.fr [193.49.43.1]) by raq2100.uk2net.com (8.10.2/8.10.2) with SMTP id h0U8ml831380 for ; Thu, 30 Jan 2003 08:48:47 GMT Received: (from uucp@localhost) by out.esrf.fr (8.6.10/8.6.10) id JAA23429 for ; Thu, 30 Jan 2003 09:46:03 +0100 Received: from esrf.esrf.fr(160.103.2.9) by firewall via smap (V1.3) id tmp023341; Thu Jan 30 09:45:36 2003 Received: from maya.esrf.fr (localhost [127.0.0.1]) by esrf.esrf.fr (8.9.0/8.9.0) with ESMTP id JAA24808 for ; Thu, 30 Jan 2003 09:48:12 +0100 (MET) Received: from localhost (goetz@localhost) by maya.esrf.fr (8.9.3+Sun/8.9.1) with ESMTP id JAA10686 for ; Thu, 30 Jan 2003 09:48:11 +0100 (MET) X-Authentication-Warning: maya.esrf.fr: goetz owned process doing -bs From: Andy Goetz X-Sender: goetz@maya To: omninotify-list@omniorb-support.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [omniNotify] resolving Notification Service Sender: omninotify-list-admin@omniorb-support.com Errors-To: omninotify-list-admin@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: Date: Thu Jan 30 08:49:02 2003 X-Original-Date: Thu, 30 Jan 2003 09:48:11 +0100 (MET) Hi, I am new to omniNotify so please be patient if my question has an obvious answer. I am trying to get a VERY simple example working with a server and client for omniNotify building them from scratch. I have hacked the examples code to send my own events but I do not find it very clear. I would like to write a server and client from scratch using the COS Notification API directly. My first example fails just trying to get the EventChannelFactory. My code to get a handle on the EventChannelFactory looks like this : CosNotifyChannelAdmin::EventChannel_var eventChannelFactory; try { CORBA::Object_var obj = orb -> resolve_initial_references("NotificationService"); // // Narrow the CORBA_Object reference to an EventChannelFactory // reference so we can invoke its methods // eventChannelFactory = CosNotifyChannelAdmin::EventChannelFactory::_narrow(obj); } catch(...) { cerr << "Cannot resolve `NotificationService'" << endl; exit(1); } // // Make sure the CORBA object was really an EventChannelFactory // if(CORBA::is_nil(eventChannelFactory)) { cerr << "`NotificationService' initial reference is not " << "a CosNotifyChannelAdmin::EventChannelFactory" << endl; exit(1); } But it never resolves the EventChannelFactory. I have tried resolving the IOR in the /tmp/rdifact.ior file as well but when I do the narrow it says this is not an EventChannelFactory. My questions are : (1) is the bootstrap method via "NotificationService" supported ? (2) why can I not narrow /tmp/rdifact.ior to CosNotifyChannelAdmin::EventChannelFactory ? Thanks for any help you can give on this. Andy Gotz -- European Synchrotron Radiation Facility 6, rue Jules Horowitz, Grenoble, 38043 FRANCE tel: (+33)-476882646 email: goetz@esrf.fr andy_gotz@yahoo.fr From goetz@esrf.fr Thu Jan 30 10:26:30 2003 Received: from out.esrf.fr (firewall.sfn.asso.fr [193.49.43.1]) by raq2100.uk2net.com (8.10.2/8.10.2) with SMTP id h0UAQU803654 for ; Thu, 30 Jan 2003 10:26:30 GMT Received: (from uucp@localhost) by out.esrf.fr (8.6.10/8.6.10) id LAA22897 for ; Thu, 30 Jan 2003 11:23:48 +0100 Received: from esrf.esrf.fr(160.103.2.9) by firewall via smap (V1.3) id tmp022798; Thu Jan 30 11:23:29 2003 Subject: Re: [omniNotify] resolving Notification Service Received: from maya.esrf.fr (localhost [127.0.0.1]) by esrf.esrf.fr (8.9.0/8.9.0) with ESMTP id LAA26659 for ; Thu, 30 Jan 2003 11:26:06 +0100 (MET) Received: from localhost (goetz@localhost) by maya.esrf.fr (8.9.3+Sun/8.9.1) with ESMTP id LAA11549 for ; Thu, 30 Jan 2003 11:26:06 +0100 (MET) X-Authentication-Warning: maya.esrf.fr: goetz owned process doing -bs From: Andy Goetz X-Sender: goetz@maya To: omninotify-list@omniorb-support.com In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: omninotify-list-admin@omniorb-support.com Errors-To: omninotify-list-admin@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: Date: Thu Jan 30 10:27:01 2003 X-Original-Date: Thu, 30 Jan 2003 11:26:05 +0100 (MET) Hi, I have partly resolved my problem of bootstrapping. In my program which was converting the ior to an EventChannel I had mistyped /tmp/rdfact.ior and /tmp/rdchan.ior ! Once I had corrected this stupid mistake I could correctly resolve these two references to their correct types. I still cannot get the resolve_initial_references on "NotificationService" to work however. Is this supposed to work ? I do not see it being used in any of the examples. Now I get a CORBA::SystemException when I try to : structuredProxyPushConsumer -> connect_structured_push_supplier( CosNotifyComm::StructuredPushSupplier::_nil()); Up to then everything seems to work fine. Any ideas about what the beginner is doing wrong again ? Thanks Andy On Thu, 30 Jan 2003, Andy Goetz wrote: > Hi, > > I am new to omniNotify so please be patient if my question has an obvious > answer. > > I am trying to get a VERY simple example working with a server and client > for omniNotify building them from scratch. I have hacked the examples code > to send my own events but I do not find it very clear. I would like to > write a server and client from scratch using the COS Notification API > directly. My first example fails just trying to get the > EventChannelFactory. > > My code to get a handle on the EventChannelFactory looks like this : > > CosNotifyChannelAdmin::EventChannel_var eventChannelFactory; > try > { > CORBA::Object_var obj = > orb -> resolve_initial_references("NotificationService"); > > // > // Narrow the CORBA_Object reference to an EventChannelFactory > // reference so we can invoke its methods > // > eventChannelFactory = > CosNotifyChannelAdmin::EventChannelFactory::_narrow(obj); > > } > catch(...) > { > cerr << "Cannot resolve `NotificationService'" << endl; > exit(1); > } > > // > // Make sure the CORBA object was really an EventChannelFactory > // > if(CORBA::is_nil(eventChannelFactory)) > { > cerr << "`NotificationService' initial reference is not " > << "a CosNotifyChannelAdmin::EventChannelFactory" > << endl; > exit(1); > } > > But it never resolves the EventChannelFactory. I have tried resolving the > IOR in the /tmp/rdifact.ior file as well but when I do the narrow it says > this is not an EventChannelFactory. > > My questions are : > > (1) is the bootstrap method via "NotificationService" supported ? > > (2) why can I not narrow /tmp/rdifact.ior to > > CosNotifyChannelAdmin::EventChannelFactory ? > > Thanks for any help you can give on this. > > Andy Gotz > > -- > European Synchrotron Radiation Facility > 6, rue Jules Horowitz, > Grenoble, 38043 > FRANCE > > tel: (+33)-476882646 > > email: goetz@esrf.fr > andy_gotz@yahoo.fr > > _______________________________________________ > omninotify-list mailing list > omninotify-list@omniorb-support.com > http://www.omniorb-support.com/mailman/listinfo/omninotify-list > -- European Synchrotron Radiation Facility 6, rue Jules Horowitz, Grenoble, 38043 FRANCE tel: (+33)-476882646 email: goetz@esrf.fr andy_gotz@yahoo.fr From tvedt@noao.edu Thu Jan 30 16:23:49 2003 Received: from noao.edu (email.noao.edu [140.252.1.54]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0UGNm821167 for ; Thu, 30 Jan 2003 16:23:49 GMT Received: from dorado.tuc.noao.edu ([140.252.38.7] verified) by noao.edu (CommuniGate Pro SMTP 4.0.3) with ESMTP-TLS id 6381865; Thu, 30 Jan 2003 09:23:50 -0700 Received: from dorado.tuc.noao.edu (localhost [127.0.0.1]) by dorado.tuc.noao.edu (8.12.5/8.12.5) with ESMTP id h0UGL4Ob003372; Thu, 30 Jan 2003 09:21:04 -0700 Received: (from tvedt@localhost) by dorado.tuc.noao.edu (8.12.5/8.12.5/Submit) id h0UGL4uY003370; Thu, 30 Jan 2003 09:21:04 -0700 X-Authentication-Warning: dorado.tuc.noao.edu: tvedt set sender to tvedt@noao.edu using -f Subject: Re: [omniNotify] resolving Notification Service From: Janet Tvedt To: Andy Goetz Cc: omninotify-list@omniorb-support.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Message-Id: <1043943664.2801.1187.camel@dorado.tuc.noao.edu> Mime-Version: 1.0 Sender: omninotify-list-admin@omniorb-support.com Errors-To: omninotify-list-admin@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: Date: Thu Jan 30 16:24:02 2003 X-Original-Date: 30 Jan 2003 09:21:04 -0700 Andy, I don't know the answer to your question about whether or not you should/can use resolve_initial_references to find the notification service. However, you can use this call to find the naming service: CORBA::Object_var name_service; CosNaming::NamingContext_var name_context; name_service = orb->resolve_initial_references("NameService"); name_context = CosNaming::NamingContext::_narrow(name_service); Then use the name service to locate the channel factory and/or default event channel: CosNaming::Name name; name.length(1); name[0].id = CORBA::string_dup((const char*)"EventChannel"); name[0].kind = CORBA::string_dup((const char*)"EventChannel"); CORBA::Object_var channel_ref = name_context->resolve(name); Have a look at at omniNotify/examples/get_channel.h for details. Janet Tvedt On Thu, 2003-01-30 at 03:26, Andy Goetz wrote: > Hi, > > I have partly resolved my problem of bootstrapping. In my program which > was converting the ior to an EventChannel I had mistyped /tmp/rdfact.ior > and /tmp/rdchan.ior ! Once I had corrected this stupid mistake I could > correctly resolve these two references to their correct types. I still > cannot get the resolve_initial_references on "NotificationService" to > work however. Is this supposed to work ? I do not see it being used in > any of the examples. > > Now I get a CORBA::SystemException when I try to : > > structuredProxyPushConsumer -> connect_structured_push_supplier( > CosNotifyComm::StructuredPushSupplier::_nil()); > > Up to then everything seems to work fine. Any ideas about what the > beginner is doing wrong again ? > > Thanks > > Andy > > On Thu, 30 Jan 2003, Andy Goetz wrote: > > > Hi, > > > > I am new to omniNotify so please be patient if my question has an obvious > > answer. > > > > I am trying to get a VERY simple example working with a server and client > > for omniNotify building them from scratch. I have hacked the examples code > > to send my own events but I do not find it very clear. I would like to > > write a server and client from scratch using the COS Notification API > > directly. My first example fails just trying to get the > > EventChannelFactory. > > > > My code to get a handle on the EventChannelFactory looks like this : > > > > CosNotifyChannelAdmin::EventChannel_var eventChannelFactory; > > try > > { > > CORBA::Object_var obj = > > orb -> resolve_initial_references("NotificationService"); > > > > // > > // Narrow the CORBA_Object reference to an EventChannelFactory > > // reference so we can invoke its methods > > // > > eventChannelFactory = > > CosNotifyChannelAdmin::EventChannelFactory::_narrow(obj); > > > > } > > catch(...) > > { > > cerr << "Cannot resolve `NotificationService'" << endl; > > exit(1); > > } > > > > // > > // Make sure the CORBA object was really an EventChannelFactory > > // > > if(CORBA::is_nil(eventChannelFactory)) > > { > > cerr << "`NotificationService' initial reference is not " > > << "a CosNotifyChannelAdmin::EventChannelFactory" > > << endl; > > exit(1); > > } > > > > But it never resolves the EventChannelFactory. I have tried resolving the > > IOR in the /tmp/rdifact.ior file as well but when I do the narrow it says > > this is not an EventChannelFactory. > > > > My questions are : > > > > (1) is the bootstrap method via "NotificationService" supported ? > > > > (2) why can I not narrow /tmp/rdifact.ior to > > > > CosNotifyChannelAdmin::EventChannelFactory ? > > > > Thanks for any help you can give on this. > > > > Andy Gotz > > > > -- > > European Synchrotron Radiation Facility > > 6, rue Jules Horowitz, > > Grenoble, 38043 > > FRANCE > > > > tel: (+33)-476882646 > > > > email: goetz@esrf.fr > > andy_gotz@yahoo.fr > > > > _______________________________________________ > > omninotify-list mailing list > > omninotify-list@omniorb-support.com > > http://www.omniorb-support.com/mailman/listinfo/omninotify-list > > > > -- > European Synchrotron Radiation Facility > 6, rue Jules Horowitz, > Grenoble, 38043 > FRANCE > > tel: (+33)-476882646 > > email: goetz@esrf.fr > andy_gotz@yahoo.fr > > _______________________________________________ > omninotify-list mailing list > omninotify-list@omniorb-support.com > http://www.omniorb-support.com/mailman/listinfo/omninotify-list From goetz@esrf.fr Thu Jan 30 21:53:03 2003 Received: from out.esrf.fr (firewall.ill.fr [193.49.43.1]) by raq2100.uk2net.com (8.10.2/8.10.2) with SMTP id h0ULr3804560 for ; Thu, 30 Jan 2003 21:53:03 GMT Received: (from uucp@localhost) by out.esrf.fr (8.6.10/8.6.10) id WAA27820; Thu, 30 Jan 2003 22:50:20 +0100 Received: from esrf.esrf.fr(160.103.2.9) by firewall via smap (V1.3) id tmp027620; Thu Jan 30 22:50:06 2003 Subject: Re: [omniNotify] resolving Notification Service Received: from maya.esrf.fr (localhost [127.0.0.1]) by esrf.esrf.fr (8.9.0/8.9.0) with ESMTP id WAA29598; Thu, 30 Jan 2003 22:52:44 +0100 (MET) Received: from localhost (goetz@localhost) by maya.esrf.fr (8.9.3+Sun/8.9.1) with ESMTP id WAA15753; Thu, 30 Jan 2003 22:52:43 +0100 (MET) X-Authentication-Warning: maya.esrf.fr: goetz owned process doing -bs From: Andy Goetz X-Sender: goetz@maya To: Janet Tvedt cc: omninotify-list@omniorb-support.com In-Reply-To: <1043943664.2801.1187.camel@dorado.tuc.noao.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: omninotify-list-admin@omniorb-support.com Errors-To: omninotify-list-admin@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: Date: Thu Jan 30 21:54:01 2003 X-Original-Date: Thu, 30 Jan 2003 22:52:43 +0100 (MET) Hi, thanks a lot for the answer. I think my problem now is with the connect_structured_push_supplier(). All examples I have seen show you can use CosNotifyComm::StructuredSupplier::_nil() as argument but it fails with a CORBA:SystemException under omniNotify 1.2. I do not fully understand the example which is delivered with omniNotify. Things like _this() are a mystery to me. That is why I tried to write a simple example from scratch. I guess I will have to hack the omniNotify example to get something working even if I don't understand all the code. Andy On 30 Jan 2003, Janet Tvedt wrote: > Andy, > > I don't know the answer to your question about whether or not you > should/can use resolve_initial_references to find the notification > service. However, you can use this call to find the naming service: > > CORBA::Object_var name_service; > CosNaming::NamingContext_var name_context; > name_service = orb->resolve_initial_references("NameService"); > name_context = CosNaming::NamingContext::_narrow(name_service); > > Then use the name service to locate the channel factory and/or default > event channel: > > CosNaming::Name name; > name.length(1); > name[0].id = CORBA::string_dup((const char*)"EventChannel"); > name[0].kind = CORBA::string_dup((const char*)"EventChannel"); > CORBA::Object_var channel_ref = name_context->resolve(name); > > Have a look at at omniNotify/examples/get_channel.h for details. > > Janet Tvedt > -- European Synchrotron Radiation Facility 6, rue Jules Horowitz, Grenoble, 38043 FRANCE tel: (+33)-476882646 email: goetz@esrf.fr andy_gotz@yahoo.fr From Cameron.Rochester@Ripple-Systems.com Thu Feb 13 03:05:52 2003 Received: from webmailme.motherwell.com.au ([203.17.161.11]) by raq2100.uk2net.com (8.10.2/8.10.2) with SMTP id h1D35o821400 for ; Thu, 13 Feb 2003 03:05:50 GMT Received: (qmail 12144 invoked by uid 1007); 13 Feb 2003 03:05:08 -0000 Received: from Cameron.Rochester@Ripple-Systems.com by webmailme by uid 1004 with qmail-scanner-1.15 (uvscan: v4.1.60/v4247. Clear:. Processed in 2.324492 secs); 13 Feb 2003 03:05:08 -0000 Received: from unknown (HELO envelope.pth.motherwell.com.au) (192.168.70.14) by webmailme.motherwell.com.au with SMTP; 13 Feb 2003 03:05:04 -0000 Received: by envelope.pth.motherwell.com.au with Internet Mail Service (5.5.2653.19) id <1DXZX51B>; Thu, 13 Feb 2003 11:05:04 +0800 Message-ID: From: Cameron Rochester To: "'omninotify-list@omniorb-support.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [omniNotify] Mapping Filters and Persistence Sender: omninotify-list-admin@omniorb-support.com Errors-To: omninotify-list-admin@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: Date: Thu Feb 13 03:06:01 2003 X-Original-Date: Thu, 13 Feb 2003 11:04:55 +0800 Hi, I am currently investigating Notification Services and have a few questions about omniNotify. 1) I realise that persistence (EventReliability or ConnectionReliability) is not supported currently. Is there any work being done in this area at the moment? Do you have any idea how much effort would be involved in implementing this? 2) Are mapping filters supported? My question about mapping filters arises from our need to federate Notificatio Services. The main problem we foresee is Event 'feedback' where you have a Notification Service both supplying and consuming events from another Nofitication service. One option would be to use a 'hop count', or 'supplied from' field in the filterable data that can be used to prevent 'feedback'. I think this may be achievable using mapping filters but I am not entirely sure. Does anyone have any suggested solutions to the problem - or point me in the direction of some info that could help. Regards Cameron Rochester Software Engineer Ripple Systems Pty Ltd Ph: +61 893688616 Fax: +61 893688699 From gruber@research.att.com Thu Feb 13 14:15:18 2003 Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h1DEFI821539 for ; Thu, 13 Feb 2003 14:15:18 GMT Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-green.research.att.com (Postfix) with ESMTP id 6FD981E00A; Thu, 13 Feb 2003 09:15:14 -0500 (EST) Received: from raptor.research.att.com (raptor.research.att.com [135.207.23.32]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id h1DEFEO03864; Thu, 13 Feb 2003 09:15:14 -0500 (EST) From: "Robert E. Gruber" To: Cameron Rochester Cc: Subject: Re: [omniNotify] Mapping Filters and Persistence In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: omninotify-list-admin@omniorb-support.com Errors-To: omninotify-list-admin@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: Date: Thu Feb 13 14:16:01 2003 X-Original-Date: Thu, 13 Feb 2003 09:15:13 -0500 I do not plan to implement persistence any time soon, but perhaps someone else might be interested. This would not be a trivial project. If someone wanted to work on it, I would be willing to support that effort by answering questions and helping to resolve issues as they come up. Mapping filters: I believe they only map certain values, timeout and priority, neither of which would work as a 'supplied from' field. I think there is an OMG spec on managing networks of event channels. omniNotify does not support it, but you might at least look at it and check which notification services do support it. -- Bob On Thu, 13 Feb 2003, Cameron Rochester wrote: > Hi, > > I am currently investigating Notification Services and have a few questions > about omniNotify. > > 1) I realise that persistence (EventReliability or ConnectionReliability) is > not supported currently. Is there any work being done in this area at the > moment? Do you have any idea how much effort would be involved in > implementing this? > > 2) Are mapping filters supported? > > My question about mapping filters arises from our need to federate > Notificatio Services. The main problem we foresee is Event 'feedback' where > you have a Notification Service both supplying and consuming events from > another Nofitication service. One option would be to use a 'hop count', or > 'supplied from' field in the filterable data that can be used to prevent > 'feedback'. I think this may be achievable using mapping filters but I am > not entirely sure. Does anyone have any suggested solutions to the problem - > or point me in the direction of some info that could help. > > Regards > Cameron Rochester > > Software Engineer > Ripple Systems Pty Ltd > Ph: +61 893688616 > Fax: +61 893688699 > _______________________________________________ > omninotify-list mailing list > omninotify-list@omniorb-support.com > http://www.omniorb-support.com/mailman/listinfo/omninotify-list > From goetz@esrf.fr Mon Feb 24 09:24:39 2003 Received: from out.esrf.fr (firewall.ill.fr [193.49.43.1]) by raq2100.uk2net.com (8.10.2/8.10.2) with SMTP id h1O9Od829045 for ; Mon, 24 Feb 2003 09:24:39 GMT Received: (from uucp@localhost) by out.esrf.fr (8.6.10/8.6.10) id KAA10275 for ; Mon, 24 Feb 2003 10:21:26 +0100 Received: from esrf.esrf.fr(160.103.2.9) by firewall via smap (V1.3) id tmp010171; Mon Feb 24 10:21:11 2003 Received: from maya.esrf.fr (localhost [127.0.0.1]) by esrf.esrf.fr (8.9.0/8.9.0) with ESMTP id KAA18095 for ; Mon, 24 Feb 2003 10:24:11 +0100 (MET) Received: from localhost (goetz@localhost) by maya.esrf.fr (8.9.3+Sun/8.9.1) with ESMTP id KAA05382 for ; Mon, 24 Feb 2003 10:24:10 +0100 (MET) X-Authentication-Warning: maya.esrf.fr: goetz owned process doing -bs From: Andy Goetz X-Sender: goetz@maya cc: omninotify-list@omniorb-support.com In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [omniNotify] omniNotify for Windows platforms Sender: omninotify-list-admin@omniorb-support.com Errors-To: omninotify-list-admin@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: Date: Mon Feb 24 09:25:03 2003 X-Original-Date: Mon, 24 Feb 2003 10:24:10 +0100 (MET) Hi, I would like to use omniNotify (as client and notify daemon) on Windows. Has anyone tried this ? What would it entail to port omniNotify to Windows if it hasn't been done so already ? Thanks, Andy -- European Synchrotron Radiation Facility 6, rue Jules Horowitz, Grenoble, 38043 FRANCE tel: (+33)-476882646 email: goetz@esrf.fr andy_gotz@yahoo.fr From gruber@research.att.com Mon Feb 24 18:54:24 2003 Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h1OIsO824374 for ; Mon, 24 Feb 2003 18:54:24 GMT Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 9B8D64CF9A; Mon, 24 Feb 2003 13:54:21 -0500 (EST) Received: from raptor.research.att.com (raptor.research.att.com [135.207.23.32]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id h1OIsJB00171; Mon, 24 Feb 2003 13:54:19 -0500 (EST) From: "Robert E. Gruber" To: Andy Goetz Cc: Subject: Re: [omniNotify] omniNotify for Windows platforms In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: omninotify-list-admin@omniorb-support.com Errors-To: omninotify-list-admin@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: Date: Mon Feb 24 18:55:02 2003 X-Original-Date: Mon, 24 Feb 2003 13:54:19 -0500 You can of course write clients that run on Windows, it is only the daemon (notifd) that requires some porting effort. I would love to do the port but I do not have time. My standard suggestion is to run notifd on a linux box and your clients on Windows. I suspect the hard part about porting would be changing the make files to get all the debug/nondebug DLL stuff working correctly. (I have not had time to convert omniNotify to use the newer autoconf approach introduced for omniORB 4, and really it makes the most sense to do a Windows port after doing that conversion, to take advantage of what autoconf gives you.) In terms of actual code changes, I doubt there would be too many. There would some include fixes, and maybe a couple cases where a unix-only system call is used. -- Bob On Mon, 24 Feb 2003, Andy Goetz wrote: > Hi, > > I would like to use omniNotify (as client and notify daemon) on Windows. > Has anyone tried this ? What would it entail to port omniNotify to Windows > if it hasn't been done so already ? > > Thanks, > > Andy > > -- > European Synchrotron Radiation Facility > 6, rue Jules Horowitz, > Grenoble, 38043 > FRANCE > > tel: (+33)-476882646 > > email: goetz@esrf.fr > andy_gotz@yahoo.fr > > _______________________________________________ > omninotify-list mailing list > omninotify-list@omniorb-support.com > http://www.omniorb-support.com/mailman/listinfo/omninotify-list > From duncan@grisby.org Tue Feb 25 12:39:12 2003 Received: from grisby.dyndns.org (pc2-cmbg4-5-cust210.cmbg.cable.ntl.com [81.96.73.210]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h1PCdB811461 for ; Tue, 25 Feb 2003 12:39:11 GMT Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h1PCcYD13240 for ; Tue, 25 Feb 2003 12:38:34 GMT Message-Id: <200302251238.h1PCcYD13240@grisby.dyndns.org> X-Authentication-Warning: pc2-cmbg4-5-cust210.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: omninotify-list@omniorb-support.com Subject: Re: [omniNotify] omniNotify for Windows platforms In-Reply-To: Message from "Robert E. Gruber" of "Mon, 24 Feb 2003 13:54:19 EST." From: Duncan Grisby Sender: omninotify-list-admin@omniorb-support.com Errors-To: omninotify-list-admin@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: Date: Tue Feb 25 12:40:02 2003 X-Original-Date: Tue, 25 Feb 2003 12:38:34 +0000 On Monday 24 February, "Robert E. Gruber" wrote: > I suspect the hard part about porting would be changing the > make files to get all the debug/nondebug DLL stuff working > correctly. (I have not had time to convert omniNotify > to use the newer autoconf approach introduced for omniORB 4, > and really it makes the most sense to do a Windows port > after doing that conversion, to take advantage of what > autoconf gives you.) Autoconf isn't used on Windows. The Windows build still uses the old scheme with platform makefiles. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From goetz@esrf.fr Mon Mar 3 21:35:38 2003 Received: from out.esrf.fr (firewall.sfn.asso.fr [193.49.43.1]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h23LZc806061 for ; Mon, 3 Mar 2003 21:35:38 GMT Received: (from uucp@localhost) by out.esrf.fr (1.0.0) id h23LZZ217582; Mon, 3 Mar 2003 22:35:35 +0100 (MET) Received: from esrf.esrf.fr(160.103.2.9) by out.esrf.fr via smap (V1.3) id tmp017500; Mon Mar 3 22:35:11 2003 Subject: Re: [omniNotify] omniNotify for Windows platforms Received: from maya.esrf.fr (localhost [127.0.0.1]) by esrf.esrf.fr (8.9.0/8.9.0) with ESMTP id WAA08749; Mon, 3 Mar 2003 22:35:09 +0100 (MET) Received: from localhost (goetz@localhost) by maya.esrf.fr (8.9.3+Sun/8.9.1) with ESMTP id WAA08926; Mon, 3 Mar 2003 22:35:08 +0100 (MET) X-Authentication-Warning: maya.esrf.fr: goetz owned process doing -bs From: Andy Goetz X-Sender: goetz@maya To: "Robert E. Gruber" cc: omninotify-list@omniorb-support.com In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: omninotify-list-admin@omniorb-support.com Errors-To: omninotify-list-admin@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: Date: Mon Mar 3 21:36:00 2003 X-Original-Date: Mon, 3 Mar 2003 22:35:08 +0100 (MET) Hi, when you say clients can run on Windows I presume you mean that clients only need the idl interface compiled for Windows. Is this true ? If so which files are these. I can only find AttNotification.idl. Is this all Notification clients need ? Does the same hold true for java clients ? What do java clients need to link with in order to use the Notification service as clients ? Thanks for your help, Andy Gotz (ESRF) On Mon, 24 Feb 2003, Robert E. Gruber wrote: > > You can of course write clients that run on Windows, it is > only the daemon (notifd) that requires some porting effort. > I would love to do the port but I do not have time. > My standard suggestion is to run notifd on a linux box > and your clients on Windows. > > I suspect the hard part about porting would be changing the > make files to get all the debug/nondebug DLL stuff working > correctly. (I have not had time to convert omniNotify > to use the newer autoconf approach introduced for omniORB 4, > and really it makes the most sense to do a Windows port > after doing that conversion, to take advantage of what > autoconf gives you.) > > In terms of actual code changes, I doubt there > would be too many. There would some include > fixes, and maybe a couple cases where a unix-only > system call is used. > > -- Bob > > On Mon, 24 Feb 2003, Andy Goetz wrote: > > > Hi, > > > > I would like to use omniNotify (as client and notify daemon) on Windows. > > Has anyone tried this ? What would it entail to port omniNotify to Windows > > if it hasn't been done so already ? > > > > Thanks, > > > > Andy > > > > -- > > European Synchrotron Radiation Facility > > 6, rue Jules Horowitz, > > Grenoble, 38043 > > FRANCE > > > > tel: (+33)-476882646 > > > > email: goetz@esrf.fr > > andy_gotz@yahoo.fr > > > > _______________________________________________ > > omninotify-list mailing list > > omninotify-list@omniorb-support.com > > http://www.omniorb-support.com/mailman/listinfo/omninotify-list > > > > _______________________________________________ > omninotify-list mailing list > omninotify-list@omniorb-support.com > http://www.omniorb-support.com/mailman/listinfo/omninotify-list > -- European Synchrotron Radiation Facility 6, rue Jules Horowitz, Grenoble, 38043 FRANCE tel: (+33)-476882646 email: goetz@esrf.fr andy_gotz@yahoo.fr From markzimm@io.frii.com Thu Mar 13 21:15:51 2003 Received: from io.frii.com (io.frii.com [216.17.222.1]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h2DLFoV22240 for ; Thu, 13 Mar 2003 21:15:50 GMT Received: from io.frii.com (localhost.frii.com [127.0.0.1]) by io.frii.com (8.12.8/8.12.8) with ESMTP id h2DLFo6f065573 for ; Thu, 13 Mar 2003 14:15:50 -0700 (MST) Received: (from markzimm@localhost) by io.frii.com (8.12.8/8.12.8/Submit) id h2DLForv065572 for omninotify-list@omniorb-support.com; Thu, 13 Mar 2003 14:15:50 -0700 (MST) From: Mark Zimmerman To: omninotify-list@omniorb-support.com Message-ID: <20030313211550.GB63162@io.frii.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Subject: [omniNotify] omniORB 4.0.1, omniNotify 2.0 alpha, and AIX Sender: omninotify-list-admin@omniorb-support.com Errors-To: omninotify-list-admin@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: Date: Thu Mar 13 21:16:01 2003 X-Original-Date: Thu, 13 Mar 2003 14:15:50 -0700 Greetings: I am trying to compile omniNotify 2.0 alpha with omniORB 4.0.1 on an AIX machine. There are some problems with library dependencies that the attached patch seems to work around. I am sure that this is not the correct answer to the problem but it may be of informational value. The problems occur when linking libAttNotificationDynamic4.a.0 and libCOSDynamic4.a.0. Both have a multitude of unresolved externals that are resolved by adding a library to the link. This is not necessary under Solaris or Linux. Also, in both cases the following linker warnings are reported: ld: 0711-415 WARNING: Symbol __cdtors is already exported. ld: 0711-415 WARNING: Symbol __priority0x80000028 is already exported. -- Mark From markzimm@io.frii.com Thu Mar 13 21:31:11 2003 Received: from io.frii.com (io.frii.com [216.17.222.1]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h2DLVAV22998 for ; Thu, 13 Mar 2003 21:31:10 GMT Received: from io.frii.com (localhost.frii.com [127.0.0.1]) by io.frii.com (8.12.8/8.12.8) with ESMTP id h2DLVD6f066254 for ; Thu, 13 Mar 2003 14:31:13 -0700 (MST) Received: (from markzimm@localhost) by io.frii.com (8.12.8/8.12.8/Submit) id h2DLVD8t066253 for omninotify-list@omniorb-support.com; Thu, 13 Mar 2003 14:31:13 -0700 (MST) From: Mark Zimmerman To: omninotify-list@omniorb-support.com Message-ID: <20030313213112.GA66180@io.frii.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline User-Agent: Mutt/1.4i Subject: [omniNotify] omniORB 4.0.1, omniNotify 2.0 alpha, and AIX Sender: omninotify-list-admin@omniorb-support.com Errors-To: omninotify-list-admin@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: Date: Thu Mar 13 21:32:01 2003 X-Original-Date: Thu, 13 Mar 2003 14:31:13 -0700 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Greetings: OK, let's try this again _with_ the attachment... I am trying to compile omniNotify 2.0 alpha with omniORB 4.0.1 on an AIX machine. There are some problems with library dependencies that the attached patch seems to work around. I am sure that this is not the correct answer to the problem but it may be of informational value. The problems occur when linking libAttNotificationDynamic4.a.0 and libCOSDynamic4.a.0. Both have a multitude of unresolved externals that are resolved by adding a library to the link. This is not necessary under Solaris or Linux. Also, in both cases the following linker warnings are reported: ld: 0711-415 WARNING: Symbol __cdtors is already exported. ld: 0711-415 WARNING: Symbol __priority0x80000028 is already exported. -- Mark --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="omniNotify-aix.patch" Index: lib/dir.mk =================================================================== RCS file: /home/cvsroot/omniNotify/lib/dir.mk,v retrieving revision 1.32.4.1 diff -u -r1.32.4.1 dir.mk --- lib/dir.mk 21 May 2002 13:27:00 -0000 1.32.4.1 +++ lib/dir.mk 13 Mar 2003 19:42:20 -0000 @@ -93,7 +93,7 @@ mkshared:: $(skshared) $(skshared): $(patsubst %, shared/%, $(NFYLIB_OBJS)) - @(namespec="$(sknamespec)" extralibs="$(OMNIORB_LIB) $(COS_LIB)"; \ + @(namespec="$(sknamespec)" extralibs="$(OMNIORB_LIB) $(COS_LIB) -lAttNotification40"; \ $(MakeCXXSharedLibrary)) export:: $(skshared) Index: mkattlib/dir.mk =================================================================== RCS file: /home/cvsroot/omniNotify/mkattlib/dir.mk,v retrieving revision 1.1.10.2 diff -u -r1.1.10.2 dir.mk --- mkattlib/dir.mk 21 May 2002 20:40:25 -0000 1.1.10.2 +++ mkattlib/dir.mk 13 Mar 2003 19:42:20 -0000 @@ -89,7 +89,7 @@ imps := $(patsubst $(DLLDebugSearchPattern),$(DLLNoDebugSearchPattern), \ $(OMNIORB_LIB)) else -imps := $(OMNIORB_LIB) +imps := $(OMNIORB_LIB) -lCOSDynamic40 endif --Q68bSM7Ycu6FN28Q-- From plvaugh@sandia.gov Wed Mar 26 17:01:41 2003 Received: from mm02snlnto.son.sandia.gov (mm02snlnto.sandia.gov [132.175.109.21]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h2QH1e108833 for ; Wed, 26 Mar 2003 17:01:40 GMT Received: from 132.175.109.1 by MM01SNLNTO.sandia.gov with ESMTP ( Tumbleweed MMS SMTP Relay 01 (MMS v5.5.0)); Wed, 26 Mar 2003 10:01:35 -0600 Received: from sandia.gov (samt5475.sandia.gov [134.253.236.172]) by sass165.sandia.gov (8.12.8/8.12.8) with ESMTP id h2QH1WQ2016551 for ; Wed, 26 Mar 2003 10:01:32 -0700 (MST) MIME-Version: 1.0 From: "Patrick Vaughan" To: omninotify-list@omniorb-support.com Message-ID: <9996CFA6-5FAC-11D7-BF5E-003065F93D8E@sandia.gov> X-Mailer: Apple Mail (2.551) X-WSS-ID: 129F0365699804-01-01 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [omniNotify] Problem trying to _narrow an omniNotify Channel Sender: omninotify-list-admin@omniorb-support.com Errors-To: omninotify-list-admin@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: Date: Wed Mar 26 17:02:01 2003 X-Original-Date: Wed, 26 Mar 2003 10:01:34 -0700 Hi, I'm trying to use omniNotify from Python. When I try to _narrow a channel object, the program just hangs. I don't get any error messages and no exceptions are thrown. Any suggestions on what might be wrong would be greatly appreciated. I'm using omniORB 4.0.0 omniORBpy 2.0 and omniNotify 2.0 alpha. Thanks, Pat try: channelName = "ChannelFactory" name = [CosNaming.NameComponent(channelName, channelName)] channelObj = nameContext.resolve(name) channel = channelObj._narrow(CosNotifyChannelAdmin.EventChannelFactory) # <- hangs here except: print "Error" From Cameron.Rochester@Ripple-Systems.com Wed May 28 10:24:36 2003 Received: from [203.17.161.11] (helo=webmailme.motherwell.com.au) by omniorb-support.com with smtp (Exim 4.14) id 19KxAh-00069O-MR for omninotify-list@omniorb-support.com; Wed, 28 May 2003 10:24:36 +0100 Received: (qmail 8457 invoked by uid 1007); 28 May 2003 09:13:00 -0000 Received: from Cameron.Rochester@Ripple-Systems.com by webmailme by uid 1004 with qmail-scanner-1.15 (uvscan: v4.1.60/v4266. Clear:. Processed in 2.540557 secs); 28 May 2003 09:13:00 -0000 Received: from unknown (HELO envelope.pth.motherwell.com.au) (192.168.70.14) by webmailme.motherwell.com.au with SMTP; 28 May 2003 09:12:56 -0000 Received: by envelope.pth.motherwell.com.au with Internet Mail Service (5.5.2653.19) id ; Wed, 28 May 2003 17:12:56 +0800 Message-ID: From: Cameron Rochester To: omninotify-list@omniorb-support.com Subject: [omniNotify] Filter Evaluation Problems Date: Wed, 28 May 2003 17:12:52 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2003 09:24:36 -0000 Hi all, I am having some problems with omniNotify 2.0. It does not seem to evaluate my filters correctly - either that or I don't know how to use it... --- I am sending events of the following --- // // Fixed Header // event->header.fixed_header.event_type.domain_name = CORBA::string_dup( "Foo" ); event->header.fixed_header.event_type.type_name = CORBA::string_dup( "Bar" ); // // Filterable Data // event->filterable_data.length( 1 ); event->filterable_data[0].name = CORBA::string_dup( "Name" ); event->filterable_data[0].value <<= "Value"; --- I create a subscriber with the following Filter attached to the proxy --- CosNotification::EventTypeSeq seq; seq.length(1); seq[0].domain_name = "Foo"; seq[0].type_name = "Bar"; CosNotifyFilter::ConstraintExpSeq expression; expression.length(1); expression[0].event_types = seq; expression[0].constraint_expr = "( $.header.filterable_data(Name) == 'Value' )"; --- I have also tried to no avail --- // this expression[0].constraint_expr = "$.header.filterable_data(Name) == 'Value' "; // or expression[0].constraint_expr = "( $.Name) == 'Value' )"; //or expression[0].constraint_expr = "$.Name == 'Value' "; --- Now, I have been using the TAO Notification Service up to now without any problems with these constraints. (Took me a while to figure out a number of the differences between omniNotify & TAO - such as filters correctly implementing attach_callback for subscription_change notifications in omniNotify) If I *don't* specify the constraint (ie: set it to 'true') and still specify the domain_name and type_name, I receive the events just fine.... I have tried turning on the debug options in the omniNotify configuration file but I don't seem to get any output to either stderr or to a log file (the log file is created, it just isn't populated) Any ideas - should the above constraint work? Cheers Cameron From gruber@research.att.com Wed May 28 14:16:39 2003 Received: from h-135-207-24-32.research.att.com ([135.207.24.32] helo=mailman.research.att.com) by omniorb-support.com with esmtp (Exim 4.14) id 19L0nH-0006eA-DA for omninotify-list@omniorb-support.com; Wed, 28 May 2003 14:16:39 +0100 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mailman.research.att.com (8.12.8/8.12.8) with ESMTP id h4SD0B3j004250; Wed, 28 May 2003 09:00:11 -0400 Received: from pcgruberhome (brow2116.research.att.com [135.207.58.116]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with SMTP id h4SD4WV02340; Wed, 28 May 2003 09:04:32 -0400 (EDT) Message-ID: <001301c32519$ae57b6e0$743acf87@research.att.com> From: "Robert E. Gruber" To: "Cameron Rochester" , References: Subject: Re: [omniNotify] Filter Evaluation Problems Date: Wed, 28 May 2003 09:04:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: "Robert E. Gruber" X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2003 13:16:39 -0000 If you send me your supplier/consumer code I will try it out and see what is happening. BTW you could also write $Name == 'Value' for the constraint expression. -- Bob ----- Original Message ----- From: "Cameron Rochester" To: Sent: Wednesday, May 28, 2003 5:12 AM Subject: [omniNotify] Filter Evaluation Problems > Hi all, > > I am having some problems with omniNotify 2.0. It does not seem to evaluate > my filters correctly - either that or I don't know how to use it... > > --- I am sending events of the following --- > > // > // Fixed Header > // > event->header.fixed_header.event_type.domain_name = CORBA::string_dup( "Foo" > ); > event->header.fixed_header.event_type.type_name = CORBA::string_dup( "Bar" > ); > > // > // Filterable Data > // > event->filterable_data.length( 1 ); > event->filterable_data[0].name = CORBA::string_dup( "Name" ); > event->filterable_data[0].value <<= "Value"; > > > --- I create a subscriber with the following Filter attached to the proxy > --- > > CosNotification::EventTypeSeq seq; > seq.length(1); > seq[0].domain_name = "Foo"; > seq[0].type_name = "Bar"; > > CosNotifyFilter::ConstraintExpSeq expression; > expression.length(1); > expression[0].event_types = seq; > expression[0].constraint_expr = "( $.header.filterable_data(Name) == 'Value' > )"; > > --- I have also tried to no avail --- > // this > expression[0].constraint_expr = "$.header.filterable_data(Name) == 'Value' > "; > // or > expression[0].constraint_expr = "( $.Name) == 'Value' )"; > //or > expression[0].constraint_expr = "$.Name == 'Value' "; > > --- > > Now, I have been using the TAO Notification Service up to now without any > problems with these constraints. (Took me a while to figure out a number of > the differences between omniNotify & TAO - such as filters correctly > implementing attach_callback for subscription_change notifications in > omniNotify) > > If I *don't* specify the constraint (ie: set it to 'true') and still specify > the domain_name and type_name, I receive the events just fine.... > > I have tried turning on the debug options in the omniNotify configuration > file but I don't seem to get any output to either stderr or to a log file > (the log file is created, it just isn't populated) > > Any ideas - should the above constraint work? > > Cheers > Cameron > > > > > _______________________________________________ > omninotify-list mailing list > omninotify-list@omniorb-support.com > http://www.omniorb-support.com/mailman/listinfo/omninotify-list > From Cameron.Rochester@Ripple-Systems.com Thu May 29 01:41:26 2003 Received: from [203.17.161.11] (helo=webmailme.motherwell.com.au) by omniorb-support.com with smtp (Exim 4.14) id 19LBTy-0007Hq-02 for omninotify-list@omniorb-support.com; Thu, 29 May 2003 01:41:26 +0100 Received: (qmail 17207 invoked by uid 1007); 29 May 2003 00:29:23 -0000 Received: from Cameron.Rochester@Ripple-Systems.com by webmailme by uid 1004 with qmail-scanner-1.15 (uvscan: v4.1.60/v4267. Clear:. Processed in 2.578357 secs); 29 May 2003 00:29:23 -0000 Received: from unknown (HELO envelope.pth.motherwell.com.au) (192.168.70.14) by webmailme.motherwell.com.au with SMTP; 29 May 2003 00:29:19 -0000 Received: by envelope.pth.motherwell.com.au with Internet Mail Service (5.5.2653.19) id ; Thu, 29 May 2003 08:29:18 +0800 Message-ID: From: Cameron Rochester To: omninotify-list@omniorb-support.com Subject: RE: [omniNotify] Filter Evaluation Problems Date: Thu, 29 May 2003 08:29:16 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2003 00:41:26 -0000 No need to send you the code :) $Name == 'Value' worked. It is a bit concerning that $.Name == 'Value' does not work as this is an acceptable constraint as defined by the OMG spec. I hope that the $Name == 'Value' syntax works with the TAO Notification service :) Cheers! Cameron -----Original Message----- From: Robert E. Gruber [mailto:gruber@research.att.com] Sent: Wednesday, May 28, 2003 9:05 PM To: Cameron Rochester; omninotify-list@omniorb-support.com Cc: Robert E. Gruber Subject: Re: [omniNotify] Filter Evaluation Problems If you send me your supplier/consumer code I will try it out and see what is happening. BTW you could also write $Name == 'Value' for the constraint expression. -- Bob ----- Original Message ----- From: "Cameron Rochester" To: Sent: Wednesday, May 28, 2003 5:12 AM Subject: [omniNotify] Filter Evaluation Problems > Hi all, > > I am having some problems with omniNotify 2.0. It does not seem to evaluate > my filters correctly - either that or I don't know how to use it... > > --- I am sending events of the following --- > > // > // Fixed Header > // > event->header.fixed_header.event_type.domain_name = CORBA::string_dup( "Foo" > ); > event->header.fixed_header.event_type.type_name = CORBA::string_dup( "Bar" > ); > > // > // Filterable Data > // > event->filterable_data.length( 1 ); > event->filterable_data[0].name = CORBA::string_dup( "Name" ); > event->filterable_data[0].value <<= "Value"; > > > --- I create a subscriber with the following Filter attached to the proxy > --- > > CosNotification::EventTypeSeq seq; > seq.length(1); > seq[0].domain_name = "Foo"; > seq[0].type_name = "Bar"; > > CosNotifyFilter::ConstraintExpSeq expression; > expression.length(1); > expression[0].event_types = seq; > expression[0].constraint_expr = "( $.header.filterable_data(Name) == 'Value' > )"; > > --- I have also tried to no avail --- > // this > expression[0].constraint_expr = "$.header.filterable_data(Name) == 'Value' > "; > // or > expression[0].constraint_expr = "( $.Name) == 'Value' )"; > //or > expression[0].constraint_expr = "$.Name == 'Value' "; > > --- > > Now, I have been using the TAO Notification Service up to now without any > problems with these constraints. (Took me a while to figure out a number of > the differences between omniNotify & TAO - such as filters correctly > implementing attach_callback for subscription_change notifications in > omniNotify) > > If I *don't* specify the constraint (ie: set it to 'true') and still specify > the domain_name and type_name, I receive the events just fine.... > > I have tried turning on the debug options in the omniNotify configuration > file but I don't seem to get any output to either stderr or to a log file > (the log file is created, it just isn't populated) > > Any ideas - should the above constraint work? > > Cheers > Cameron > > > > > _______________________________________________ > omninotify-list mailing list > omninotify-list@omniorb-support.com > http://www.omniorb-support.com/mailman/listinfo/omninotify-list > From jon@totient.demon.co.uk Sun Jun 08 22:05:35 2003 Received: from anchor-post-39.mail.demon.net ([194.217.242.80]) by omniorb-support.com with esmtp (Exim 4.14) id 19P7M7-0005mf-9H for omninotify-list@omniorb-support.com; Sun, 08 Jun 2003 22:05:35 +0100 Received: from totient.demon.co.uk ([80.177.108.44]) by anchor-post-39.mail.demon.net with esmtp (Exim 3.36 #2) id 19P75L-0004xg-0U for omninotify-list@omniorb-support.com; Sun, 08 Jun 2003 21:48:15 +0100 Content-Type: text/plain; charset="us-ascii" From: Jon Dyte To: omninotify-list@omniorb-support.com Date: Sun, 8 Jun 2003 21:51:02 +0100 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200306082151.02263.jon@totient.demon.co.uk> Subject: [omniNotify] python versions of the omniNotify example programs X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2003 21:05:35 -0000 Hi The title says it all really. Do these exist? I'm sure I have seen refere= nce=20 mad to python version of any_push_supplier etc, using omniORBpy, however, these dont seem to be in CVS. I've written a version of any_push_supplier in python , which needs some refactoring to become a module for all the other examples, but before I g= o ahead and do this, I dont want to reinvent the wheel if these exist alrea= dy. do the python versions already exist? regards, jon =20 From markzimm@io.frii.com Wed Jun 18 17:47:46 2003 Received: from io.frii.com ([216.17.222.1]) by omniorb-support.com with esmtp (Exim 4.14) id 19Sg66-0003ks-EN for omninotify-list@omniorb-support.com; Wed, 18 Jun 2003 17:47:46 +0100 Received: from io.frii.com (localhost.frii.com [127.0.0.1]) by io.frii.com (8.12.9/8.12.9) with ESMTP id h5IGPYur069560 for ; Wed, 18 Jun 2003 10:25:37 -0600 (MDT) Received: (from markzimm@localhost) by io.frii.com (8.12.9/8.12.9/Submit) id h5IGPW1a069559 for omninotify-list@omniorb-support.com; Wed, 18 Jun 2003 10:25:32 -0600 (MDT) Date: Wed, 18 Jun 2003 10:25:32 -0600 From: Mark Zimmerman To: omninotify-list@omniorb-support.com Message-ID: <20030618162532.GA69351@io.frii.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [omniNotify] omniNotify 2.0 X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2003 16:47:46 -0000 Greetings: omniNotify 2.0 has been working well for me for quite a long time now. Are there any plans to declare success and remove the alpha designation? -- Mark From gruber@research.att.com Wed Jun 18 18:34:56 2003 Received: from h-135-207-24-16.research.att.com ([135.207.24.16] helo=linux.research.att.com) by omniorb-support.com with esmtp (Exim 4.14) id 19Sgpk-0003nm-LD for omninotify-list@omniorb-support.com; Wed, 18 Jun 2003 18:34:56 +0100 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by linux.research.att.com (8.12.8/8.12.8) with ESMTP id h5IHJjEI016017; Wed, 18 Jun 2003 13:19:45 -0400 Received: from pcgruber (pc-gruber.research.att.com [135.207.23.156]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id h5IHCFV02340; Wed, 18 Jun 2003 13:12:15 -0400 (EDT) From: "Robert E. Gruber" To: "'Mark Zimmerman'" , Subject: RE: [omniNotify] omniNotify 2.0 Date: Wed, 18 Jun 2003 13:10:03 -0400 Message-ID: <01a501c335bc$7595a110$9c17cf87@pcgruber> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 In-Reply-To: <20030618162532.GA69351@io.frii.com> Importance: Normal Cc: "Robert E. Gruber" X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2003 17:34:56 -0000 Yes, it will happen! But a couple things have been holding me back. Duncan has set up a sourceforge CVS repository, and this will become the official omniNotify CVS repository as soon as I get the time to update a few things. (Thanks Duncan!) I believe Duncan also has autoconf working for omniNotify, and I'd like to include that support in the 2.0 release. And there are a few fixes that should also go in, including fixing a case where a lock is held across a push call, something the channel should never do. So yes it will happen, and I hope it will be soon. But probably not this week :-> Thanks for you patience, -- Bob -----Original Message----- From: omninotify-list-bounces@omniorb-support.com [mailto:omninotify-list-bounces@omniorb-support.com] On Behalf Of Mark Zimmerman Sent: Wednesday, June 18, 2003 12:26 PM To: omninotify-list@omniorb-support.com Subject: [omniNotify] omniNotify 2.0 Greetings: omniNotify 2.0 has been working well for me for quite a long time now. Are there any plans to declare success and remove the alpha designation? -- Mark _______________________________________________ omninotify-list mailing list omninotify-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omninotify-list From duncan@grisby.org Thu Jun 19 18:03:48 2003 Received: from pc2-cmbg4-5-cust210.cmbg.cable.ntl.com ([81.96.73.210] helo=grisby.dyndns.org) by omniorb-support.com with esmtp (Exim 4.14) id 19T2p9-0005Y2-Sb for omninotify-list@omniorb-support.com; Thu, 19 Jun 2003 18:03:47 +0100 Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h5JGf8X25880 for ; Thu, 19 Jun 2003 17:41:08 +0100 Message-Id: <200306191641.h5JGf8X25880@grisby.dyndns.org> X-Authentication-Warning: pc2-cmbg4-5-cust210.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: omninotify-list@omniorb-support.com Subject: Re: [omniNotify] omniNotify 2.0 In-Reply-To: Message from "Robert E. Gruber" of "Wed, 18 Jun 2003 13:10:03 EDT." <01a501c335bc$7595a110$9c17cf87@pcgruber> From: Duncan Grisby Date: Thu, 19 Jun 2003 17:41:08 +0100 X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2003 17:03:48 -0000 On Wednesday 18 June, "Robert E. Gruber" wrote: > I believe Duncan also has autoconf working for omniNotify, and I'd > like to include that support in the 2.0 release. Yes, autoconf is working, in the SourceForge CVS. I have also just checked in the changes to support omniNotify on Windows. Aside from the usual platform differences, I encountered some problems with the omniORB DLL handling, and a compiler bug in Visual C++. The result of that is that I've had to change some things about the IDL compiler output. To get omniNotify to work, you need to get the current CVS contents of omniORB, and do a clean build of that, before building omniNotify. I haven't completely tested the Windows port yet, so there may still be problems with it. The examples all seem to work ok. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From Cameron.Rochester@Ripple-Systems.com Tue Jun 24 07:54:12 2003 Received: from [203.17.161.11] (helo=webmailme.motherwell.com.au) by omniorb-support.com with smtp (Exim 4.14) id 19Uhgx-0003t0-Le for omninotify-list@omniorb-support.com; Tue, 24 Jun 2003 07:54:12 +0100 Received: (qmail 16763 invoked by uid 1007); 24 Jun 2003 06:29:10 -0000 Received: from Cameron.Rochester@Ripple-Systems.com by webmailme by uid 1004 with qmail-scanner-1.15 (uvscan: v4.1.60/v4272. Clear:. Processed in 2.549699 secs); 24 Jun 2003 06:29:10 -0000 Received: from unknown (HELO envelope.pth.motherwell.com.au) (192.168.70.14) by webmailme.motherwell.com.au with SMTP; 24 Jun 2003 06:29:06 -0000 Received: by envelope.pth.motherwell.com.au with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 14:29:06 +0800 Message-ID: From: Cameron Rochester To: "'omninotify-list@omniorb-support.com'" Subject: [omniNotify] Win32 dll's Date: Tue, 24 Jun 2003 14:29:05 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2003 06:54:12 -0000 Hi all, Given that there is nothing new under the sun - I was wondering if anyone has compiled some release libraries and DLLs for omniNotify 2.0 Alpha (with omniORB 4.0.1) under win32 (NT/2k)? I would need the AttNotification, and libCOSNotify4 dlls (and placeholder libs of course ;). If so, could you please post a link to a zip, or similar, that I could download? I will be eternally grateful! :) Regards Cameron Rochester From goetz@esrf.fr Tue Jun 24 08:05:26 2003 Received: from firewall.sfn.asso.fr ([193.49.43.1] helo=out.esrf.fr) by omniorb-support.com with esmtp (Exim 4.14) id 19Uhrq-0003vH-6v for omninotify-list@omniorb-support.com; Tue, 24 Jun 2003 08:05:26 +0100 Received: (from uucp@localhost) by out.esrf.fr (1.0.0) id h5O6dm816953; Tue, 24 Jun 2003 08:39:48 +0200 (MEST) Received: from esrf.esrf.fr(160.103.2.9) by firewall via smap (V1.3) id tmp016770; Tue Jun 24 08:39:28 2003 Subject: Re: [omniNotify] Win32 dll's Received: from starwars.esrf.fr (localhost [127.0.0.1]) by esrf.esrf.fr (8.9.0/8.9.0) with ESMTP id IAA19224; Tue, 24 Jun 2003 08:39:27 +0200 (MET DST) Received: from localhost (goetz@localhost) by starwars.esrf.fr (8.11.6+Sun/8.11.6) with ESMTP id h5O6dQe05667; Tue, 24 Jun 2003 08:39:26 +0200 (MEST) X-Authentication-Warning: starwars.esrf.fr: goetz owned process doing -bs Date: Tue, 24 Jun 2003 08:39:26 +0200 (MEST) From: Andy Goetz To: Cameron Rochester In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "'omninotify-list@omniorb-support.com'" X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2003 07:05:26 -0000 Hi, I am busy going thru this exercise but fighting with my Visual C++ installation under Win 98. Maybe Duncan can provide us with a ready compiled version ;-) Otherwise I hope to do this under Win2k. I will send you my result as soon as I have something. Andy On Tue, 24 Jun 2003, Cameron Rochester wrote: > Hi all, > > Given that there is nothing new under the sun - I was wondering if anyone > has compiled some release libraries and DLLs for omniNotify 2.0 Alpha (with > omniORB 4.0.1) under win32 (NT/2k)? I would need the AttNotification, and > libCOSNotify4 dlls (and placeholder libs of course ;). > > If so, could you please post a link to a zip, or similar, that I could > download? I will be eternally grateful! :) > > Regards > Cameron Rochester > > _______________________________________________ > omninotify-list mailing list > omninotify-list@omniorb-support.com > http://www.omniorb-support.com/mailman/listinfo/omninotify-list > -- European Synchrotron Radiation Facility 6, rue Jules Horowitz, Grenoble, 38043 FRANCE tel: (+33)-476882646 email: goetz@esrf.fr andy_gotz@yahoo.fr From gruber@research.att.com Thu Jul 03 15:36:01 2003 Received: from h-135-207-24-16.research.att.com ([135.207.24.16] helo=linux.research.att.com) by omniorb-support.com with esmtp (Exim 4.14) id 19Y5Bp-00021J-61 for omninotify-list@omniorb-support.com; Thu, 03 Jul 2003 15:36:01 +0100 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by linux.research.att.com (8.12.8/8.12.8) with ESMTP id h63EHWJh027769 for ; Thu, 3 Jul 2003 10:17:32 -0400 Received: from pcgruberhome (brow2116.research.att.com [135.207.58.116]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with SMTP id h63E5tV13486; Thu, 3 Jul 2003 10:05:55 -0400 (EDT) Message-ID: <009a01c3416c$38787e40$743acf87@research.att.com> From: "Robert E. Gruber" To: Date: Thu, 3 Jul 2003 10:05:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: "Robert E. Gruber" Subject: [omniNotify] latest omniNotify2_alpha is in sourceforge X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2003 14:36:01 -0000 The omniNotify CVS repository has moved to sourceforge. You can get the lates omniNotify2_alpha there. anonymous access has been a problem lately... Duncan, would you mind making sure the latest snapshot is up to date and telling people how to get things that way? I just checked in changes that include some bug fixes. I would appreciate it if a few people would try things out. Unfortunately I will be away today through July 13, so I will not be able to help or work on fixes until then but I would appreciate it if some people had tried things by the time I return. Many thanks!! -- Bob Gruber From duncan@grisby.org Thu Jul 03 16:45:26 2003 Received: from pc2-cmbg4-5-cust210.cmbg.cable.ntl.com ([81.96.73.210] helo=grisby.dyndns.org) by omniorb-support.com with esmtp (Exim 4.14) id 19Y6H0-0002Yc-31 for omninotify-list@omniorb-support.com; Thu, 03 Jul 2003 16:45:26 +0100 Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h63FFnc32052 for ; Thu, 3 Jul 2003 16:15:49 +0100 Message-Id: <200307031515.h63FFnc32052@grisby.dyndns.org> X-Authentication-Warning: pc2-cmbg4-5-cust210.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: omninotify-list@omniorb-support.com Subject: Re: [omniNotify] latest omniNotify2_alpha is in sourceforge In-Reply-To: Message from "Robert E. Gruber" of "Thu, 03 Jul 2003 10:05:47 EDT." <009a01c3416c$38787e40$743acf87@research.att.com> From: Duncan Grisby Date: Thu, 03 Jul 2003 16:15:49 +0100 X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2003 15:45:26 -0000 On Thursday 3 July, "Robert E. Gruber" wrote: > The omniNotify CVS repository has moved to sourceforge. > You can get the lates omniNotify2_alpha there. anonymous > access has been a problem lately... Duncan, would you mind > making sure the latest snapshot is up to date and telling people > how to get things that way? The CVS page with instructions about getting it from anonymous CVS is here: http://sourceforge.net/cvs/?group_id=77499 As Bob says, anonymous access has been flaky recently. Instead, you can get a snapshot of a checkout from http://omniorb.sourceforge.net/snapshots/ Note that for omniNotify to work on Windows, you must use the CVS version of omniORB, since there are some changes in that to support it. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From markzimm@io.frii.com Wed Jul 16 15:50:38 2003 Received: from io.frii.com ([216.17.222.1]) by omniorb-support.com with esmtp (Exim 4.14) id 19cnc6-0006xT-I2 for omninotify-list@omniorb-support.com; Wed, 16 Jul 2003 15:50:38 +0100 Received: from io.frii.com (localhost.frii.com [127.0.0.1]) by io.frii.com (8.12.9/8.12.9) with ESMTP id h6GEEWIg061113; Wed, 16 Jul 2003 08:14:33 -0600 (MDT) Received: (from markzimm@localhost) by io.frii.com (8.12.9/8.12.9/Submit) id h6GEEUs3061112; Wed, 16 Jul 2003 08:14:30 -0600 (MDT) Date: Wed, 16 Jul 2003 08:14:30 -0600 From: Mark Zimmerman To: "Robert E. Gruber" , omninotify-list@omniorb-support.com Subject: Re: [omniNotify] latest omniNotify2_alpha is in sourceforge Message-ID: <20030716141430.GA60674@io.frii.com> References: <009a01c3416c$38787e40$743acf87@research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <009a01c3416c$38787e40$743acf87@research.att.com> User-Agent: Mutt/1.4.1i Cc: X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2003 14:50:38 -0000 On Thu, Jul 03, 2003 at 10:05:47AM -0400, Robert E. Gruber wrote: > The omniNotify CVS repository has moved to sourceforge. > You can get the lates omniNotify2_alpha there. anonymous > access has been a problem lately... Duncan, would you mind > making sure the latest snapshot is up to date and telling people > how to get things that way? > > I just checked in changes that include some bug fixes. > I would appreciate it if a few people would try things out. > Unfortunately I will be away today through July 13, so I > will not be able to help or work on fixes until then but I > would appreciate it if some people had tried things by the > time I return. > FYI, I downloaded the 03 July snapshots and successfully built with autoconf on Solaris 7 and 8 and on AIX 4.3 (xlC). The AIX build required some patching but it has been working fine. Solaris works as-is. -- Mark From gruber@research.att.com Wed Jul 16 16:19:45 2003 Received: from h-135-207-24-32.research.att.com ([135.207.24.32] helo=mailman.research.att.com) by omniorb-support.com with esmtp (Exim 4.14) id 19co4G-00070x-VQ for omninotify-list@omniorb-support.com; Wed, 16 Jul 2003 16:19:45 +0100 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mailman.research.att.com (8.12.8/8.12.8) with ESMTP id h6GEZf3j027831; Wed, 16 Jul 2003 10:35:41 -0400 Received: from pcgruberhome (brow2116.research.att.com [135.207.58.116]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with SMTP id h6GEh8V17037; Wed, 16 Jul 2003 10:43:08 -0400 (EDT) Message-ID: <003301c34ba8$9309fc80$743acf87@research.att.com> From: "Robert E. Gruber" To: "Mark Zimmerman" , References: <009a01c3416c$38787e40$743acf87@research.att.com> <20030716141430.GA60674@io.frii.com> Subject: Re: [omniNotify] latest omniNotify2_alpha is in sourceforge Date: Wed, 16 Jul 2003 10:43:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: "Robert E. Gruber" X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2003 15:19:45 -0000 Mark, thanks for checking things out. Please send me the AIX changes so I can add them in. -- Bob ----- Original Message ----- From: "Mark Zimmerman" To: "Robert E. Gruber" ; Sent: Wednesday, July 16, 2003 10:14 AM Subject: Re: [omniNotify] latest omniNotify2_alpha is in sourceforge > On Thu, Jul 03, 2003 at 10:05:47AM -0400, Robert E. Gruber wrote: > > The omniNotify CVS repository has moved to sourceforge. > > You can get the lates omniNotify2_alpha there. anonymous > > access has been a problem lately... Duncan, would you mind > > making sure the latest snapshot is up to date and telling people > > how to get things that way? > > > > I just checked in changes that include some bug fixes. > > I would appreciate it if a few people would try things out. > > Unfortunately I will be away today through July 13, so I > > will not be able to help or work on fixes until then but I > > would appreciate it if some people had tried things by the > > time I return. > > > > FYI, I downloaded the 03 July snapshots and successfully built with > autoconf on Solaris 7 and 8 and on AIX 4.3 (xlC). The AIX build > required some patching but it has been working fine. Solaris works > as-is. > > -- Mark > > _______________________________________________ > omninotify-list mailing list > omninotify-list@omniorb-support.com > http://www.omniorb-support.com/mailman/listinfo/omninotify-list > From markzimm@io.frii.com Thu Jul 24 15:55:27 2003 Received: from io.frii.com ([216.17.222.1]) by omniorb-support.com with esmtp (Exim 4.14) id 19fhV9-0001G5-3E for omninotify-list@omniorb-support.com; Thu, 24 Jul 2003 15:55:27 +0100 Received: from io.frii.com (localhost.frii.com [127.0.0.1]) by io.frii.com (8.12.9/8.12.9) with ESMTP id h6OEFLIg032023; Thu, 24 Jul 2003 08:15:21 -0600 (MDT) Received: (from markzimm@localhost) by io.frii.com (8.12.9/8.12.9/Submit) id h6OEFL44032022; Thu, 24 Jul 2003 08:15:21 -0600 (MDT) Date: Thu, 24 Jul 2003 08:15:21 -0600 From: Mark Zimmerman To: "Robert E. Gruber" , omninotify-list@omniorb-support.com Subject: Re: [omniNotify] latest omniNotify2_alpha is in sourceforge Message-ID: <20030724141521.GA31745@io.frii.com> References: <009a01c3416c$38787e40$743acf87@research.att.com> <20030716141430.GA60674@io.frii.com> <003301c34ba8$9309fc80$743acf87@research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003301c34ba8$9309fc80$743acf87@research.att.com> User-Agent: Mutt/1.4.1i Cc: X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2003 14:55:27 -0000 On Wed, Jul 16, 2003 at 10:43:08AM -0400, Robert E. Gruber wrote: > Mark, thanks for checking things out. Please send me the AIX changes so I > can add them in. > I know that this is not the right way to do it (I modified the generated beforeauto.mk file directly) but I won't have time to work on doing it properly for a week or so. Also, I'm sure that this is specific to my machine / AIX version / compiler. Anyhow, for what it's worth, here is all I had to do: chickenhawk$ ls omniNotify*/build/mk/beforeauto.mk omniNotify/build/mk/beforeauto.mk omniNotifyOK/build/mk/beforeauto.mk chickenhawk$ diff omniNotify*/build/mk/beforeauto.mk 665c665 < CXX = cl --- > CXX = xlC_r 931c931,946 < error Not supported yet. Too nasty. --- > #error Not supported yet. Too nasty. > CXXOPTIONS = -qstaticinline -qmaxmem=8192 -qlonglong -qlongdouble > COPTIONS = -qlonglong -qlongdouble > MAKECPPSHAREDLIB=makeC++SharedLib_r > define MakeCXXSharedLibrary > $(ParseNameSpec); \ > soname=$(SharedLibrarySoNameTemplate); \ > set -x; \ > $(RM) $@; \ > $(MAKECPPSHAREDLIB) \ > -o $$soname $(IMPORT_LIBRARY_FLAGS) \ > $(filter-out $(LibSuffixPattern),$^) $$extralibs \ > -p 40; \ > ar cq $@ $$soname; \ > $(RM) $$soname; > endef -- Mark From markzimm@io.frii.com Thu Jul 24 16:18:30 2003 Received: from io.frii.com ([216.17.222.1]) by omniorb-support.com with esmtp (Exim 4.14) id 19fhrS-0001IF-Ds for omninotify-list@omniorb-support.com; Thu, 24 Jul 2003 16:18:30 +0100 Received: from io.frii.com (localhost.frii.com [127.0.0.1]) by io.frii.com (8.12.9/8.12.9) with ESMTP id h6OEcPIg033648; Thu, 24 Jul 2003 08:38:25 -0600 (MDT) Received: (from markzimm@localhost) by io.frii.com (8.12.9/8.12.9/Submit) id h6OEcPV3033646; Thu, 24 Jul 2003 08:38:25 -0600 (MDT) Date: Thu, 24 Jul 2003 08:38:25 -0600 From: Mark Zimmerman To: omninotify-list@omniorb-support.com, gruber@research.att.com Subject: Re: [omniNotify] latest omniNotify2_alpha is in sourceforge Message-ID: <20030724143825.GA33462@io.frii.com> References: <009a01c3416c$38787e40$743acf87@research.att.com> <20030716141430.GA60674@io.frii.com> <003301c34ba8$9309fc80$743acf87@research.att.com> <20030724141521.GA31745@io.frii.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030724141521.GA31745@io.frii.com> User-Agent: Mutt/1.4.1i Cc: X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2003 15:18:30 -0000 Oops, there was one other file that changed. Here it is: chickenhawk$ ls omniNotify*/mkattlib/dir.mk omniNotify/mkattlib/dir.mk omniNotifyOK/mkattlib/dir.mk chickenhawk$ diff omniNotify*/mkattlib/dir.mk 119a120,122 > ifdef AIX > imps += -lCOS4 -lCOSDynamic4 > endif On Thu, Jul 24, 2003 at 08:15:21AM -0600, Mark Zimmerman wrote: > On Wed, Jul 16, 2003 at 10:43:08AM -0400, Robert E. Gruber wrote: > > Mark, thanks for checking things out. Please send me the AIX changes so I > > can add them in. > > > > I know that this is not the right way to do it (I modified the > generated beforeauto.mk file directly) but I won't have time to work > on doing it properly for a week or so. Also, I'm sure that this is > specific to my machine / AIX version / compiler. Anyhow, for what > it's worth, here is all I had to do: > > chickenhawk$ ls omniNotify*/build/mk/beforeauto.mk > omniNotify/build/mk/beforeauto.mk omniNotifyOK/build/mk/beforeauto.mk > > chickenhawk$ diff omniNotify*/build/mk/beforeauto.mk > 665c665 > < CXX = cl > --- > > CXX = xlC_r > 931c931,946 > < error Not supported yet. Too nasty. > --- > > #error Not supported yet. Too nasty. > > CXXOPTIONS = -qstaticinline -qmaxmem=8192 -qlonglong -qlongdouble > > COPTIONS = -qlonglong -qlongdouble > > MAKECPPSHAREDLIB=makeC++SharedLib_r > > define MakeCXXSharedLibrary > > $(ParseNameSpec); \ > > soname=$(SharedLibrarySoNameTemplate); \ > > set -x; \ > > $(RM) $@; \ > > $(MAKECPPSHAREDLIB) \ > > -o $$soname $(IMPORT_LIBRARY_FLAGS) \ > > $(filter-out $(LibSuffixPattern),$^) $$extralibs \ > > -p 40; \ > > ar cq $@ $$soname; \ > > $(RM) $$soname; > > endef > > -- Mark > > _______________________________________________ > omninotify-list mailing list > omninotify-list@omniorb-support.com > http://www.omniorb-support.com/mailman/listinfo/omninotify-list From plvaugh@sandia.gov Tue Aug 05 23:58:56 2003 Received: from mm02snlnto.sandia.gov ([132.175.109.21] helo=mm02snlnto.son.sandia.gov) by omniorb-support.com with esmtp (Exim 4.14) id 19kAlb-0002R4-V8; Tue, 05 Aug 2003 23:58:56 +0100 Received: from 132.175.109.1 by MM01SNLNTO.son.sandia.gov with ESMTP ( Tumbleweed MMS SMTP Relay 01 (MMS v5.5.0)); Tue, 05 Aug 2003 16:55:17 -0600 Received: from sandia.gov (samt5475.sandia.gov [134.253.236.172]) by sass165.sandia.gov (8.12.9/8.12.9) with ESMTP id h75MtD35009029; Tue, 5 Aug 2003 16:55:13 -0600 (MDT) Date: Tue, 5 Aug 2003 16:55:13 -0600 MIME-Version: 1.0 To: omninotify-list@omniorb-support.com From: "Patrick Vaughan" Message-ID: X-Mailer: Apple Mail (2.552) X-PMX-Version: 4.0.2.71298 X-WSS-ID: 132EEA5F1470-01-01 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: omniorb-list@omniorb-support.com Subject: [omniNotify] omniNotify Performance Tuning Question X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2003 22:58:56 -0000 Greetings, I've been running an application which uses omniORB/omniORBpy with omniNotify. Everything works, but the performance in respect to event passing seems quite slow. The load on the system is about 15-20 events per minute. I'm seeing delays of around a full minute from the time an event is sent to the time the event arrives. I've run the application on both a Mac OS X 10.2.6 system and a Red Hat Linux 7.3.2 system. The delay is about the same regardless of the system I run the application on. Any suggestions on how to decrease the delay in event delivery would be appreciated. Thanks. From Cameron.Rochester@Ripple-Systems.com Wed Aug 06 01:30:57 2003 Received: from [203.17.161.11] (helo=webmailme.motherwell.com.au) by omniorb-support.com with smtp (Exim 4.14) id 19kCCf-0002bN-7u for omninotify-list@omniorb-support.com; Wed, 06 Aug 2003 01:30:57 +0100 Received: (qmail 5835 invoked by uid 1007); 6 Aug 2003 00:27:25 -0000 Received: from Cameron.Rochester@Ripple-Systems.com by webmailme by uid 1004 with qmail-scanner-1.15 (uvscan: v4.1.60/v4282. Clear:. Processed in 2.693898 secs); 06 Aug 2003 00:27:25 -0000 Received: from unknown (HELO envelope.pth.motherwell.com.au) (192.168.70.14) by webmailme.motherwell.com.au with SMTP; 6 Aug 2003 00:27:21 -0000 Received: by envelope.pth.motherwell.com.au with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Aug 2003 08:27:21 +0800 Message-ID: From: Cameron Rochester To: omninotify-list@omniorb-support.com Subject: RE: [omniNotify] omniNotify Performance Tuning Question Date: Wed, 6 Aug 2003 08:27:20 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2003 00:30:58 -0000 Patrick, How many consumers are connected to the notification service? What is the complexity of the filters that you have in place? I have found with testing that performance drops off considerably as consumers increase (it is much worse than a linear degradation). However, evaluating more complex filters and having less consumers is actually a lot faster. Our system used to have multiple connections to the notification service from the same client. I changed the approach and reduced the number of connections while increasing the filter complexity and found performance to be much better while reducing load on the service. Having said that, I never saw the kind of lag that you are experiencing. Running the service on a (relatively) slow dual processor solaris box (2 x 400MHz, 512Mb RAM) and sending/receiving events from a seperate windows client (P4 2.4G, 512Mb RAM) the notification service would still manage approx 10 events/sec with 1700 unique subscribers. The faster approach was to create a filter with a constraint expression seq with 1700 individual constraints (but only one connection) and then perform simple filtering on the client side to ensure the correct subscriber receives the correct event. With this approach the notification service sustains ~500 events/sec with 1700 subscribed types. With 1-2 subscribed types it would manage upwards of 600 events/sec. So, the service should be able to handle significantly more than 15-20 events minute, but we probably need a bit more information regarding the way in which you are consuming events. Cheers Cameron Rochester -----Original Message----- From: Patrick Vaughan [mailto:plvaugh@sandia.gov] Sent: Wednesday, August 06, 2003 6:55 AM To: omninotify-list@omniorb-support.com Cc: omniorb-list@omniorb-support.com Subject: [omniNotify] omniNotify Performance Tuning Question Greetings, I've been running an application which uses omniORB/omniORBpy with omniNotify. Everything works, but the performance in respect to event passing seems quite slow. The load on the system is about 15-20 events per minute. I'm seeing delays of around a full minute from the time an event is sent to the time the event arrives. I've run the application on both a Mac OS X 10.2.6 system and a Red Hat Linux 7.3.2 system. The delay is about the same regardless of the system I run the application on. Any suggestions on how to decrease the delay in event delivery would be appreciated. Thanks. _______________________________________________ omninotify-list mailing list omninotify-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omninotify-list From gruber@research.att.com Wed Aug 06 16:41:23 2003 Received: from h-135-207-24-32.research.att.com ([135.207.24.32] helo=mailman.research.att.com) by omniorb-support.com with esmtp (Exim 4.14) id 19kQPj-0003Aa-AH for omninotify-list@omniorb-support.com; Wed, 06 Aug 2003 16:41:23 +0100 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mailman.research.att.com (8.12.8/8.12.8) with ESMTP id h76Fb2eo029150; Wed, 6 Aug 2003 11:37:02 -0400 Received: from pcgruber (pc-gruber.research.att.com [135.207.23.156]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id h76Fb7B18096; Wed, 6 Aug 2003 11:37:08 -0400 (EDT) From: "Robert E. Gruber" To: "'Cameron Rochester'" , Subject: RE: [omniNotify] omniNotify Performance Tuning Question Date: Wed, 6 Aug 2003 11:33:56 -0400 Message-ID: <004301c35c30$26fe6e20$9c17cf87@pcgruber> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Cc: "Robert E. Gruber" X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2003 15:41:23 -0000 omniNotify is supposed to scale with clients much better than Cameron = describes. The poor scaling he reports may be due to a bug that was recently fixed = (a lock was held across push calls where it should not be). =20 Perhaps Cameron would you be willing to get the latest omniORB and = omniNotify from sourceforge and try benchmarking again? =20 For those interesting in getting stuff from sourceforge, I will send = another email describing how to do this. A new omniORB 4 release will happen soon, and this will be followed by = the long-awaited (!) omniNotify 2.0 official release (which depends on the upcoming = omniORB 4, at least for the Windows port). =20 Next email: getting sources. -- Bob -----Original Message----- From: omninotify-list-bounces@omniorb-support.com [mailto:omninotify-list-bounces@omniorb-support.com] On Behalf Of = Cameron Rochester Sent: Tuesday, August 05, 2003 8:27 PM To: omninotify-list@omniorb-support.com Subject: RE: [omniNotify] omniNotify Performance Tuning Question Patrick, How many consumers are connected to the notification service? What is = the complexity of the filters that you have in place? I have found with testing that performance drops off considerably as consumers increase (it is much worse than a linear degradation). = However, evaluating more complex filters and having less consumers is actually a = lot faster. Our system used to have multiple connections to the notification service from the same client. I changed the approach and reduced the = number of connections while increasing the filter complexity and found = performance to be much better while reducing load on the service. Having said that, I never saw the kind of lag that you are experiencing. Running the service on a (relatively) slow dual processor solaris box (2 = x 400MHz, 512Mb RAM) and sending/receiving events from a seperate windows client (P4 2.4G, 512Mb RAM) the notification service would still manage approx 10 events/sec with 1700 unique subscribers. The faster approach = was to create a filter with a constraint expression seq with 1700 individual constraints (but only one connection) and then perform simple filtering = on the client side to ensure the correct subscriber receives the correct = event. With this approach the notification service sustains ~500 events/sec = with 1700 subscribed types. With 1-2 subscribed types it would manage upwards = of 600 events/sec. So, the service should be able to handle significantly more than 15-20 events minute, but we probably need a bit more information regarding the = way in which you are consuming events. Cheers Cameron Rochester -----Original Message----- From: Patrick Vaughan [mailto:plvaugh@sandia.gov] Sent: Wednesday, August 06, 2003 6:55 AM To: omninotify-list@omniorb-support.com Cc: omniorb-list@omniorb-support.com Subject: [omniNotify] omniNotify Performance Tuning Question Greetings, I've been running an application which uses omniORB/omniORBpy with=20 omniNotify. Everything works, but the performance in respect to event=20 passing seems quite slow. The load on the system is about 15-20 events=20 per minute. I'm seeing delays of around a full minute from the time an=20 event is sent to the time the event arrives. I've run the application=20 on both a Mac OS X 10.2.6 system and a Red Hat Linux 7.3.2 system. The=20 delay is about the same regardless of the system I run the application=20 on. Any suggestions on how to decrease the delay in event delivery would be=20 appreciated. Thanks. _______________________________________________ omninotify-list mailing list omninotify-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omninotify-list _______________________________________________ omninotify-list mailing list omninotify-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omninotify-list From gruber@research.att.com Wed Aug 06 16:44:15 2003 Received: from h-135-207-24-16.research.att.com ([135.207.24.16] helo=linux.research.att.com) by omniorb-support.com with esmtp (Exim 4.14) id 19kQSU-0003Bo-Qc for omninotify-list@omniorb-support.com; Wed, 06 Aug 2003 16:44:14 +0100 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by linux.research.att.com (8.12.8/8.12.8) with ESMTP id h76FeWPj007852 for ; Wed, 6 Aug 2003 11:40:32 -0400 Received: from pcgruber (pc-gruber.research.att.com [135.207.23.156]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id h76FdxB21049; Wed, 6 Aug 2003 11:39:59 -0400 (EDT) From: "Robert E. Gruber" To: Date: Wed, 6 Aug 2003 11:36:48 -0400 Message-ID: <004901c35c30$8c86dca0$9c17cf87@pcgruber> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Cc: "Robert E. Gruber" Subject: [omniNotify] Getting the latest omniNotify and omniORB source X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2003 15:44:15 -0000 This email describes how to get the latest omniORB and omniNotify = sources from sourceforge. The latest omniNotify source is effectively the release = candidate of the upcoming omniNotify 2.0 release. A new omniORB 4 release will happen soon, and this will be followed by = the long-awaited omniNotify 2.0 official release (it depends on the upcoming omniORB = release, at least for the Windows port). Those of you not wanting to use anonymous cvs = checkout from sourceforge will need to wait for these releases. Snapshots http://omniorb.sourceforge.net/snapshots/omniORB-4.0-latest.tar.gz http://omniorb.sourceforge.net/snapshots/omniNotify-2-latest.tar.gz Anonymous CVS Access (1) Do a cvs login to omniorb cvsroot: > cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/omniorb login=20 When prompted for a password for anonymous, simply press the Enter = key. (2) Get the latest omniORB source: =A0 > cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/omniorb co = -r omni4_0_develop omni=20 (3) Change into /src/services directory > cd omni/src/services (4) Do a cvs login to omniNotify cvsroot: > cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/omninotify = login=20 When prompted for a password for anonymous, simply press the Enter = key. (5) Get the latest omniNotify source: > cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/omninotify = co -r omniNotify2_alpha omniNotify Now you have the sources. See the appropriate README files for build = instructions. -- Bob From Cameron.Rochester@Ripple-Systems.com Thu Aug 07 03:02:18 2003 Received: from [203.17.161.11] (helo=webmailme.motherwell.com.au) by omniorb-support.com with smtp (Exim 4.14) id 19ka6b-0003Rc-CG for omninotify-list@omniorb-support.com; Thu, 07 Aug 2003 03:02:17 +0100 Received: (qmail 1389 invoked by uid 1007); 7 Aug 2003 01:58:19 -0000 Received: from Cameron.Rochester@Ripple-Systems.com by webmailme by uid 1004 with qmail-scanner-1.15 (uvscan: v4.1.60/v4283. Clear:. Processed in 4.662565 secs); 07 Aug 2003 01:58:19 -0000 Received: from unknown (HELO envelope.pth.motherwell.com.au) (192.168.70.14) by webmailme.motherwell.com.au with SMTP; 7 Aug 2003 01:58:13 -0000 Received: by envelope.pth.motherwell.com.au with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Aug 2003 09:58:13 +0800 Message-ID: From: Cameron Rochester To: "'omninotify-list@omniorb-support.com'" Subject: [omniNotify] omniNotify subscription bug Date: Thu, 7 Aug 2003 09:58:06 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2003 02:02:18 -0000 Robert, I have discovered quite a nasty bug that causes the Notification Service to stop pushing events to consumers and stop accepting new consumers/suppliers. The service still receives events from connected suppliers. This leads to huge memory leaks as events back up in the notification service and all communications in the system stop as no new consumers or suppliers can connect. I will explain the scenario under which this occurs - please let me know what other information you may require. Environment: - omniNotify latest CVS snapshot (4 aug 03), omniORB latest CVS snapshot (4 aug 03). - omniNotify 2.0 alpha, omniORB 4.0.1 - Solaris 2.8 (gcc 3.2.1) and Win2k (VS 6.0). Another VERY interesting phenomenon is that this does not occur with the Win32 build of the NS, only the Solaris build. Unfortunately, all our server systems run on Solaris. As I stated in my last email regarding performance I have started using a single consumer connection (per channel) with a more complex filter. Basically, our applications dynamically add and remove subscriptions on the fly resulting in the need to update the constraints in place on the filter. My test rigs have picked up the problem mentioned above when subscriptions are added to a filter while the notification service is under load. The test rig uses the following format for each constraint. A filter is created on the notification service and subscribers are added in a loop, from 1 to 512 using filter->add_constraints(). (NOTE: If this same test is done with 512 unique subscribers, each with their own filter, the problem does not appear. It only occurs when constraints are added to an existing filter). Each constraint expression is very simple and can be represented below: { [ context, 1_type ], "true" } { [ context, 2_type ], "true" } ... { [ context, 512_type ], "true" } Once all the constraints have been added the test app will then send X number of events (say 10,000), as fast as it can, that will match only one of the constraints ( say { [ context, 256_type ], "true" } ). With a single test application the behaviour is as expected, the subscriber for [context, 256_type] receives the expected number of events. Now - I will outline where the problem occurs. 1) Launch the test app mentioned above 2) Once messages start arriving launch a second copy of the test app with the same number of subscribers (1 ... 512) but only sending 1000 events (the number of events does not really matter) 3) Once a few subscriptions have been added to the new consumer filter, the Notification Service will stop responding. The NS will still receive events from suppliers already connected (ie, the first test app), but it will no longer push any more events to consumers. 4) The second test app will start throwing exceptions on the call to filter->add_constraints( ), after the corba timeout period, as the NS has stopped responding. 5) Once the first test app finishes sending 10,000 events it will attempt to remove the constraints it has put in place, this will also fail on the call to filter->modify_constraints( ) after the corba timeout period (currently 30 seconds) 6) Even after the test apps have been killed the NS will never recover from this state. As you can imagine, this is a bit of a showstopper problem. Our applications perform operations similar to this quite often. The system usually stops responding after about 20 mins. Robert - please let me know if you need anymore information. It is not simple for me to send you the code as it is heavily tailored to our own applications and libraries. However, if you have problems replicating the issue I should be able to modify one of the example applications to emulate the above scenario. Thanks for your help Cameron Rochester From Cameron.Rochester@Ripple-Systems.com Thu Aug 07 07:17:03 2003 Received: from [203.17.161.11] (helo=webmailme.motherwell.com.au) by omniorb-support.com with smtp (Exim 4.14) id 19ke57-0003b8-3K for omninotify-list@omniorb-support.com; Thu, 07 Aug 2003 07:17:01 +0100 Received: (qmail 7168 invoked by uid 1007); 7 Aug 2003 06:12:57 -0000 Received: from Cameron.Rochester@Ripple-Systems.com by webmailme by uid 1004 with qmail-scanner-1.15 (uvscan: v4.1.60/v4283. Clear:. Processed in 6.126877 secs); 07 Aug 2003 06:12:57 -0000 Received: from unknown (HELO envelope.pth.motherwell.com.au) (192.168.70.14) by webmailme.motherwell.com.au with SMTP; 7 Aug 2003 06:12:48 -0000 Received: by envelope.pth.motherwell.com.au with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Aug 2003 14:12:48 +0800 Message-ID: From: Cameron Rochester To: "'Robert E. Gruber'" , omninotify-list@omniorb-support.com Subject: RE: [omniNotify] omniNotify Performance Tuning Question Date: Thu, 7 Aug 2003 14:12:46 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C35CAA.EB6EF8E0" X-Mailman-Approved-At: Thu, 07 Aug 2003 10:33:08 +0100 Cc: X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2003 06:17:03 -0000 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C35CAA.EB6EF8E0 Content-Type: text/plain; charset="iso-8859-1" Robert, I grabbed the latest omniNotify snapshot (and the latest omniORB snapshot) and checked the update.log, it contained the following entry: "Changed things so event lock is not held across push (required different approach for omniORB3 vs. omniORB4). Also remove all events from outgoing queue of a proxy that gets _pxstatus set to RDI_Exception." I assume this is the fix you have mentioned? After a few hours of building I was ready to go again. One other thing - does omniNotify clean up invalid suppliers/consumers/filters if a client application crashes? On to the testing.... environment: - Solaris 2.8 (Sunfire V480 - 2 x 1.1G with 4,096MB RAM. GCC 3.2.1) running omniNotify - Win2k (P4 2.4G with 512MB RAM. VS 6.0) running test client I performed the test again and found performance to be a little better. For the implementation of the client please refer to the "omniNotify subscription bug" email I also sent today, I use the same application for gathering performance data. Performance for unique subscriptions had improved but still exhibited very poor perfomance with > 32 unique subscribers. Performance for unique subscriptions was generally double the last build with > 16 unique subscribers. Shared subscriptions again show what approaches a flat performance rate. For a graph of this data please see http://ii.net/~rochest/graph.gif. The graph shows performance with up to 1024 subscribed types. Our system can easily require in excess of 1000 subscribed event types. Regards Cameron Rochester -----Original Message----- From: Robert E. Gruber [mailto:gruber@research.att.com] Sent: Wednesday, August 06, 2003 11:34 PM To: 'Cameron Rochester'; omninotify-list@omniorb-support.com Cc: Robert E. Gruber Subject: RE: [omniNotify] omniNotify Performance Tuning Question omniNotify is supposed to scale with clients much better than Cameron describes. The poor scaling he reports may be due to a bug that was recently fixed (a lock was held across push calls where it should not be). Perhaps Cameron would you be willing to get the latest omniORB and omniNotify from sourceforge and try benchmarking again? For those interesting in getting stuff from sourceforge, I will send another email describing how to do this. A new omniORB 4 release will happen soon, and this will be followed by the long-awaited (!) omniNotify 2.0 official release (which depends on the upcoming omniORB 4, at least for the Windows port). Next email: getting sources. -- Bob -----Original Message----- From: omninotify-list-bounces@omniorb-support.com [mailto:omninotify-list-bounces@omniorb-support.com] On Behalf Of Cameron Rochester Sent: Tuesday, August 05, 2003 8:27 PM To: omninotify-list@omniorb-support.com Subject: RE: [omniNotify] omniNotify Performance Tuning Question Patrick, How many consumers are connected to the notification service? What is the complexity of the filters that you have in place? I have found with testing that performance drops off considerably as consumers increase (it is much worse than a linear degradation). However, evaluating more complex filters and having less consumers is actually a lot faster. Our system used to have multiple connections to the notification service from the same client. I changed the approach and reduced the number of connections while increasing the filter complexity and found performance to be much better while reducing load on the service. Having said that, I never saw the kind of lag that you are experiencing. Running the service on a (relatively) slow dual processor solaris box (2 x 400MHz, 512Mb RAM) and sending/receiving events from a seperate windows client (P4 2.4G, 512Mb RAM) the notification service would still manage approx 10 events/sec with 1700 unique subscribers. The faster approach was to create a filter with a constraint expression seq with 1700 individual constraints (but only one connection) and then perform simple filtering on the client side to ensure the correct subscriber receives the correct event. With this approach the notification service sustains ~500 events/sec with 1700 subscribed types. With 1-2 subscribed types it would manage upwards of 600 events/sec. So, the service should be able to handle significantly more than 15-20 events minute, but we probably need a bit more information regarding the way in which you are consuming events. Cheers Cameron Rochester -----Original Message----- From: Patrick Vaughan [mailto:plvaugh@sandia.gov] Sent: Wednesday, August 06, 2003 6:55 AM To: omninotify-list@omniorb-support.com Cc: omniorb-list@omniorb-support.com Subject: [omniNotify] omniNotify Performance Tuning Question Greetings, I've been running an application which uses omniORB/omniORBpy with omniNotify. Everything works, but the performance in respect to event passing seems quite slow. The load on the system is about 15-20 events per minute. I'm seeing delays of around a full minute from the time an event is sent to the time the event arrives. I've run the application on both a Mac OS X 10.2.6 system and a Red Hat Linux 7.3.2 system. The delay is about the same regardless of the system I run the application on. Any suggestions on how to decrease the delay in event delivery would be appreciated. Thanks. _______________________________________________ omninotify-list mailing list omninotify-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omninotify-list _______________________________________________ omninotify-list mailing list omninotify-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omninotify-list ------_=_NextPart_000_01C35CAA.EB6EF8E0 Content-Type: image/gif; name="graph.gif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="graph.gif" R0lGODlhMQNvAfcAAAAAAAAAhEpKSmtjY3t7c4SEhIyMhJyclKWlnLW1rb29tcbGvcbGxtbOxt7W zufe1u/n3vfv5/8A////9/////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////ywAAAAAMQNvAQAI/gApCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN mzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izVgXAtavXr2DDih1LtqzZs2jT ql3Ltq3bt3Djyp1Lt67du3jz6t3Lt6/fv4AD010IYEKECYYRH07MeLFjxZAbR34suTLly5MzW9aM ebPnzqA5i/48OjTp06ZTl16NmrXq1rBfy3ZNO3bt2bZz4959u7du37x/Cw9OHLjx4cYBED5eHLnz 5tCZS38+PTr169azV9+Onbv27tQF/osf/xf898XKFRY+7729effs38uPTx++/fn36+Pfb3p9/v/8 AXhZYQEil15CBOqnoIAMFriggw0+KGGEFEJo4WwJVjjhhdP5t+FuByLkoYYkcmjihyWieGKKLK7o IogvtqhiahnOyFqIB9Uo444x9mijjzz+KGSQRHqWIZBIquhfkY/haNCSSTIpZZRUDlnllFZm2duI V3bJno5aNuZkQWBiaaaXZ4apZppsoomdjt2NyCV63H312ZK8rTcnc1AetuYEYxLUp5t/FtqmoYQe qmiilQ36ZmRw+pkYdEfiCel0gEJmHZxRBjoQp4iGuqiojJJq6qhSlnmdnIxVNulx/nge2eSrv0Xg aHGDSuqjpwLlWiqqvwZ7qrDADkucr5sFgOGlmXKV2JLO6vmsYl1lJqth/iVYmLPocYuts9g2i9i2 cnq77bfXhksrrVbySgGoxMZrbLH0ylvvsPBWFsC+ssX6rbra/ptpuLZSa6234xp8GLfSAmwwoNLa 2nCmC4/bcMGNtqorkO4ia+/H84J878gic+jrZfvuC1ulCVdccMUtZ9syxZaZOy3BA1uq880yw/xy z6LBq6uQHWuK2KshJ02y0iUz7TSTQkOWcsqtsYoxxgHDnLWd7B6NtcIDvwxxwGIqTLbE1YY9Nmce D11i0Yut63bTS9dN991P433p/mJT9+333347xjLNEYddOIGRqkun2Fmr7bCuMhN+s6SWOk6n3Bqz WDTmceftud2f6y166KGVKamfgSMt2eWMP7w14mZPGzfNWoO9tey3E3x25Lt33XbXF8LtdeZzkw76 8aMjb3ypjmZuWMqdbVbt4hRDe+7CaaO9+tjeoq3t9BZbT6Dk3LcKvvjOX0388D9uvvH7yUPYVQOJ NZA9kWJB3CDCxD1gAPCmQYAAACCABJyGf9IBFwKrVqmwxG95rFPd6RSjrM0ULzOUkR4Gh8caz9gG fpi5oGZURzOjmXBFwjsh/B6Yn64cYDEHAJ+a8te9/4CrOTeMDQK+YsDSpSs6/jmMTQ3zx0K6Na9z rQIgBynlKhGGcIOqyeAKpbhBD/psfUabkfuwSEII7g8ABshWGBPUgAEAYAAOSMwDCMAVAzxAMRBg IxjfOAH/cYUAEFjMAgQwgAd4q4xnpB8Vu8eVB5jRjRaDAB8N4wAzorFbz8rQHgcAAQUCwJBz/NYe BdAAP5lLT17xmgMA8ELDxDCNjOEKBCZgPwFYLJLUAkADBCCABfgpjm2kYwRmCQAERFKRA3ilxGZZ S0kBEo2T2qT90tU9M66yksHkijIdc0wHLGaNbcyj8oJkOs6xb3ubquIHR1icCW6viaKhngqxuKEU etOEXgwQV+xHP3pya5Re/nljBMzYFQIkhp93NIwcuRLMCOCTgOBaZlf0aUJwWWyAbUQXKVn5lTRK LJb16wpEvwVRMIavK6i8oSXBhxgzHo2AkhmgLTUl0mx9hX4TACgA/GlQryhAoqUc6fwQo9BC8hQs vhvfBHZYz15yjysWPahP9+kVmm6zR0f8JvDQiRxzTvA16RROZCwIxaxGbZ3yW847MVfE80TrhTHU 3wTY+MZR5hQAqxQTXLd6GD8SiI0G3OF62DoBtxaPkEZdpsV8uUo2+nKH/tQf9hSD16Fa0peCldhh Z/qvxVpWUwkAgC0XAIAEDE2vXOmhYtUqMc9mlqaqjAxb/RhMiBG2sqGN/sBpBXrJvpLyMI3NLDM9 ZD+0ylKyjk0sX/0KsbjGc03dnCI4s4ipjaUvq1bszWPmNhoP4mydSHQifNwJwm8eF0DOiqGtXsiw r7hyArolwE0Xk971GuYBCZDjt56pU66ct1EZ+uR8YWnZlv5yApUEJSyLC2BLYlRgj6mkP9kY11Yl AKA99C/26Eug9g6YcnMdcGoD/FH77pfD0yVtgV05wEQWGJReOa+Fv7sr561vdlR8bq2kalXoPpE3 MdbuBSOYXakqUT5b7DF2n1ofZ3E2jPSrr7cSYIBDTkoBTfboLjtrVxOD2IGYQZh/RQwuDo+2pREI s4FhC4AwX/TMX94T/pIpe1XDQICziHPpgUGM3ij/D80YFZyATyzRtHHrovhtDBvth9oyiznOdjoM k53M4nYx15xdZG6kZxxieJLzx7mR4Dmj98TfCTms6uFid4ncQhRXlq+dCeJiJzDAB+CTtnkFF6ot jeA0VxYxhg3ut9Ko18Q0ttdotuQB0EtZiPF6y0NTKEw7N8A0Vllix3apAmTLZsjIGgAO8ON5g2jJ ac92rbV9TK6BLZkgZtaMnoXYsGcbgVkHuqwkiuqQqYpErXZNuedUonbz/ekaT3pyon6xgILs4+42 2j3giuGw1dpTKQ8UjIt5uAEOA9ASE5ug9/zK/zSj5e+9MqP5xC1Q/g2jgK7w8+NnBos1wZ1oVnNl 4a0aoCtDXHKv+JLloewztnHtlYlTtCu+RHN/K3qYht9ZqTnU86sUalGVHwbpd5b4wV+U3IAvd9Kz gfHRNM3Veud4NW2e99fVOdZR64e7ARfy1IG4HnpedgFmFEDQARxDMK7yMBCouwHuDoFDVhIBh1EA H6tsGLgTcO5uy6F+8WxQRy4blwOILGISwMcryxlixHw8GyN/QwcM0Oen2+HNLyP4w6tx85KXJi07 aZgI6P3urBzg3LkdZ2VCxvByZwwx4ew8VacN86u/fdznnvdswttE8vYmp+lqHLdpvbpcDzFWBQ5W 6Rvtq2W3oVhH/p39428oPHNt5WnGSVXUpFb8z62haVxc6dAEZ9OWfiL8qW/9rrGxlEKPrvc19+js 31jSuNF1AHhCMuZ1NkZ9WMdBYDNvytdCy9Fvabd/EGIdYwR0YAcbB3gaFcgVc1czQuV+XFWAWzVj MpaBX7cu1dV+gzZgpCYsycd9yyeCpEFdMVh//naDVQRpOiiAPFZwEQhk2/eD77R2FBIdrmdfHbh+ UWSC6VR3uSdC6peCOfhj+waC+nZpAhiC/zc8pgdJOCiBjqZpMHiF3gM0WFV/YMI11JUu4wczJDQp ibM+nuaDBhgnD0iHeNiCP4IpVweCS+gqzlEbMwiIJ9h+gjh//jvWhkzITl1Fa0TYKeyXhz82OHG4 hUjUJ4PjfHuiY7R2M2RVaYojhAa3XUEIgaYIhv9hhCNYhUt0ac4nHVmniGToiuT3fLbIfFlIRYmI adWnh1hSdacYNGUjNoJYaTriLwYYh4N4b9e1hC4jiWMYH2gXjEPoiwGiisw4iFaYjeVUjFlliCKo dhd4hbmIhaC4i4nYY4+IKC8oAe74jhLQhw9DGeQCh4pXPR1XQqGYSpNTj5GUXzZzLs3yPYcTkJko ilanHQTHgGOIiuCRgOPHb1TYildHf97IivtmkelIkctng7JoiZJGiFtnhXW4jjsCjBMAj+9ojifF PwyTMIrz/pK6U2vd4i84I5O8wzMRI5PkwzsXo4/RiIdmdYcMGYEmiR/i2BoZVI3ymERtlpR/OJEy GHZTtZRht40xloAZaZWRBo7y94VHqUWRqBgq6Y4gqXTPyCVAk5PXVW5raTuheEVpOTOR8zOx84xq Q41BuSqlCI0/GJbtgW9/+IoliYugiIA4NpUDiE7K9YoK6IzLBZUcOYDPB39KyIgOqSSQUZac2Zmc yX6woy7lE5Oh1DqTdjF1SZALGJOseZN0CZPqM4dFWZi/MY1+CYGZyYdX2UGOGX2N6JHqmGm+qX/y N5zymJEluINNOXYVKZhFmZsmw42I8ZmqYTU985ZyaTga/mOTqSk71gab3gk7czmTM4mX2LeXEAki fTmbQmmN9VGZsdiIismSb0ibxTmfYElWzUmfhtibu6mYzjlkfuhd7slNLPmZ5scsZBNn85iT2cky V9Od2mmarwObDpoz8wiUCBmMOESU/nebBfoehEkbkCaG2riY/ceKXYmB0WOiuliO87ef3yiFu8iU Wmd2Ido+JLh+LbeW11NCMlSaXCiko+k99og+41mPXuhS2AmeeomQBrKeH/qcgBmINQh9nzaWVypO WiqF9Daj+dalkkmjb+ii/Cl2IemcN4qfOWpDvkGivOmIuDic4rilHUk7Xxpdsjml6ekatsmeAtqm 1LGR/ss4ok8JpjVmqEoJo3bKjIkajiGIgF3ap/iWprNIoFUqliq6qVNYlRlomL1YVV7zgc3npCAK qMGxkHy6l5l6HMR5gFk5pnUog2zqpQNKq/XWf3l6qJQJkda1m2ualGFqn4J6dnKqhc21mP2prPZB OX06iHuKngFanR4alCNnpJ50P9AZiyDJmK3IqydqopG5qN16pRtZooVJXYhZfuXqlN/qro15nNvK ILdCpqpYiCPZiQ9iq4eoPk/6r8Ohqg25OPkFnj9UrN64q4EaifmJhfrHomfalA/7qOa6sOPaqCPK pf+JqwjrIKqCldexnCL5rNjYrssYrRtKY7Xxp0wJ/jTVw4+cOq+EuoWOOqnAqZUke6mXibM4iqj7 6W+Qiq+9Cp8p+psde3bkkbRKWxeAuqq12iRSOrDayTPfKZWt+qq0Wp/Mx6tbyrEJK7Qeaa/vGoMN CKr/aYA1Gq//Rpvz2rYHJ60py6x3Uq1GOTNAel316rY+i7OYClYAerFdhZGMypJpu7aB255Am64K O4qeKq5he7WQ+1Rg6rQceiNRG4EFS7UABzlfUQAE4LkFALqi+7mjG7qke7qmm7qlu7qoy7qq27qw +7qy67q0S7q067qf27qgG7u7O7u8u7qie7u2y7u6+7vEm7q5q7q1q7zJ27vG67vMG7q9O73HK7vN /lu801u6qHu90ju8s7u84Fu94gu94Uu+41u+6Hu+6mu+7Ju+7bu+7hu/8Bu71eu89vu5ALsldKuX 0AKz/QuVmqUADLAAAqwABMwABozAC6DADJzADrzAD9zAEDzBElzBEXzBFIzBFpzBHNzABXzADvzB H4zAJBzCJVzCIIzCBbzBCCzCCuzCF7zCBizDHawAMAzBN2zBKNzCL+zBPizDJxzDQYzDP9zARjzD O2zCSEzDRczEDnzETZzCSgzCNVzFLKzBWGzFWXzFWtzFXPzFWxzGXizGYDzGZlzGaEzGanzFQNzG CFwAlCtEl2uK43NFoZmdHBfEemzDPMzHflzA/oDcx4H8x4JcyIR8yIOcyIasyIe8x47sxpD8yJLs x5NcyZE8yJacyZesyZy8yZ7cyaD8yaLcyYxcyot8yoiMyqacyqy8yq6syoYcyrI8yrQ8y7Zcy7h8 y29sqZVrJPsricgYMzBLoM8yyiR8zAKMzAygzMyczM68zM/czNA8zdJczdF8zdOcy9qsy9vczdz8 zd4czuA8zrVszdSMzeaczui8zufczurszuxszuI8z+Rcz/R8z5NcAC9KpUEzx3R4kHeclzQGAKQM y61s0K980Aq9yvbc0Pj80A4d0RA90eCc0BaN0Bi90Bl90RpN0R4t0SD90W0Mx+dYt3MbavmL/qfY KlEyGsCZ/M4wHc8yDc80/c4iHdI4fdM6ndM8bcwzHdM1/dNCHdREDdTSvNNI3dNKjcskTcxTmmr+ /JyL2rcELcocfdUbndUdvdRcndRe3dVgPc9Y3dFjXdZaPdZhndZfvdZwXLbdl2W/jKZeSYuP6dKb bNRDjddFnddrrdZ+3deA/dcnrNeEzdd7fdiFnc2CHdiMLdH6zMsmPSBR/YmIOIVtVtWTbNZkfdac 3ciN/dmLHdqg/dCaXdqdbdqbTcmjLdqsrc1NbdI2Oi5x7dbuWqh1LcV6nNi6bdh6vdq+3drA/dt3 zdvEjdjFvds0LdzBvdyX3NQ0u4OFKbCR/o2B44rZVn3a2J3aCc3c3K3c3v3XqB3e2S3erNzd5v3d CtDWhwndFokts82qUx1jdl3JyF3fx/3M6H3e+p3fN23fxv3f/p3Y/L3fwf3YFam1PSvdTyq3G2nd mT3eEK7dsTzgFE7gFX7P5J3hEU7eFt7hn/3awZqvjFtu7123Y7q28x3JAX7fAI7NF+7hMP7in7zi LV7jNC7PMZ7jXu3clB3iumork92QlF2NC2PJGi7hSM7IOr7kMs7kR/7kG57RTD7lIq3efVumyplK JX6KjFt/jYLbQHzjLC7gVF7mTf7iYm7jY77mZt7mD23gK/RcIT5BCu6XaHrlRX7JUJ7k/tnt5n5+ 5sG954Ie5eUN6Iau1iBupl4OmluOuD6Igl6X4oPN5mkO1Id+6X9u3pVO6Zx+2Jj+6Uv92mPZ4/1X 51Ld5TULKI886HyO5JkO6rAu2qw+64Qe67ae01Z+qKgu340eqAs+SGCu5sKe5rde7K8O1ps+7J1u 6cdu7OEM54/p1KNIOUFudR8qfw5O662O1s7e7N4+0doe7hH+7eQuyokOruyNiywblHCLGWWZ28vO 4pw56e3s2/Pe7fiu6fGu7PxO5vn+77IM7XM64odq6t3ntI3hmSrZwu+u2uHOmW2MyfZelgBf8eV+ 8RZf8efOdW5db+tu4iBKGQoPj8lM/vGKfc0mX9/3Du+tvfIZj/Ew//Iyn+OJFavXrjoGL+Ttvpkj 744ErAAND8kF3PC23PNGf/RIn/RKv/REP/Pb3PQxH/VOL/UnLPBUme6MjtKnyvFwaxhM3/P4bfIy vPRjX5bB/t0QP8tfv/aeeeZiT/VT//Jv7/SJvq7T/io5b+07vxhHf8BzT8JM381pf+EuT+Bsf/gL n8tQH/dw3+yLf/E1L07snaud8/FcHrc4vwAKP/SJv8cr/PeMH/oVjfikX/qmf/qor/SN/9WgX+5W D9nBednVjptxDCkUbfain/t+3fq6L9Kp//vAH/ymT/V17+Naq+693oApPTQAEAC9/r/6mY770P/8 xc773w7t6638mpb3tL/zkZEy1D/94h/+5B/cj//yG4/l+kn5li9VQrrSRRqZfVP+9D/+9l//+I/r 7C7iig4osw8QEwRGADAhgsCCExIeLEjQIMKBDwVKDFDRYgAFDDJu1NiR40ePIUGOFFmS5EmTKVGu VNmS5UuXMWHOlFmT5k2bOXHu1NmT50+fQYEOFVqU6FGjSZEiLSDx4MODT6FKjFiV6lMAFLRu5Uqh 4cSoYK8+XKjQ4FezaRmOfRr1IkalcZfKpTvXbl28d/Xm5bvXb1/AfwUHJjz4ZIG2VKdKDZu48WKF XSWXZcwWLFqsERuipRyRsUXD/oVFhyY92nRp1KdVp2a92nVr2B2bOlb82LPVygOzSuaKdurt2wUB DCcrMWFZ37QZYgywoHls6K+lR6c+3Xp17Ne1Z+fuUgHi2r9v5378eDdvrZ2Biyf4dbPms8bHIxxe v75F+/n17+ff3/9/AAMUcEACCzTwQAQTVHBBBht08EEII5RwQgortPBCDDOsr6n1aBPLttyMQ2+r 5CwLTj6zMlMrxQ+rImgBBd5yDsbtauzuRhtzxHFHHXvk8Ue6CHAKMiJxmy+s89BTj72rkIuvOIdU DMtFhBh46yIagdTSRy639LJLML8UM0ydOEysQ+BAFEu3EdMzkcm1VOQMIihb/kwMgIyutChLMsf0 s09A/xQ0UEIHZerMKYmckjzIkuRtyUQjddIhKOeEUzeNYtTzuUI7NdRTUD8VNVRSuZuNykgtU7Mq Ryd7M1Ws6jNO1liJU25NABboiLmLRvW1VGB/FTZYYod96dREi0w1zala7QrSV6kcktnwzPsIRtD4 NLZYbrf1tltwv61OyDeVNbfJNr2KtrJFpV3WQ9wAMKkiccO1t15879U3X6LA+822cxUlK11o2V3T Q0Td/ZcsbT3ilN99I4Z4YokrFva7Ic+8FOB2I2uzRIPny1jhaafFSqUALFaZYpZXdrnl7jRC9uBo RR7S2d7QDHlhkRMWmGGU/h5+eWiYiTa6aKSVMlNhWDd2CmcS120R1al9ZvSsluBKeuuju+b6a69D 8tdnm3fODWo3L9V55KsT7jjXlVIGe+6w6ba77nAxtrpac8vzeESQp1b7SJIZlTduvO9WPHHGF/9S 5p8BVnVNET9e+3LxxjK5Z7izbtjxxkMHfXTRR1ta2pGdNo9gqS/3u2OyT2ZJ69JJt7123G8/tOeF bzWSTcsHbxr1kPdG8nOR5M59ed2Zd775kfT+PcSmX/9bydadhqxt4g93SXnonxc/fPIZh9z67QWn HiHWhW/dYNip7nx25Mu3f3z87+f3dM3htzN9tKnLbNmDF/em5b3Z6S9//gtUYAPtNbb0aU9zlQMc 5oYnMPTtbX7fAx8DPehAEH4wUKeaoO/S57cABs6C5Vrf5rA2kz2FUIYinGENtUOuWyWLY5RjTApX OMDiRdBnGwwalmx4RBomEYmkgWAJ+WY9JLEOiOoz0bJ4dieZ6Kl+SuTiErv4xX5tTk1WbKEP3TdF qu3QZERMyVu8+EYwxhGONMEh8UoGxUZJkYpoLNLkhmgT0MhRkHMcZCFH0sQCoul3FMTeGff4PyYp jI1FJGQlDXnJJZLQbb07YR4tx8cLDg+PT9OJ0Cx5Skym8n4Q1NgEnRiv9oWSgK5sIVa2SBJTqlKX qORl7TSZOr91cnWf/nzkD/+Xw5v1hHa9ZOYunXm3OnKyijzEVSxnmR+yyCqbtqJmWybpuWaG85nj /FoTI/kuYV7vUbOMSmectKKvqBGBgCRnPcV5T5X90n9CpCbwKuhI+PRQPlGik/8Ycst52VOh+GSo vaK5Q6n0r5M+BGWdULQWeAaMIEHJZUM9ulCQ+smcfePd78woyx7ax6LvkdIxFYJQXH5UpiGl6Zj0 OREMVg2AejTmO30aUCo9KAAaImpRjXpUpCZVqUtlalOd+lSoRrU/iFSbGql3UnbqJj6ZIeiKXJgr jsK0pmOdaVlVU0eNWZGfw6xgRc9W0LRMyoUMAcoyyXpXs+Z1NSRM/l0Ep1fN4KH0MgGdU1fVg6h5 3qSjeGWsXh3LF6pqlG3zoWgxm1Wnn1r0q2LFZWM9+1jQ5uWXT5Qmz85izYqqdJvxVOneyFIUu4ZW tp+lLU4eup5popMhPAUowgpHLW9ytiSLnW1xa3vcQxqvrxENJlZQa9lWunaTBzRKB417XeRmNyOj 5V4w/1pZY/p2rkZq1zdhqF30Yhe7t/0ZeSd72sBS5QEGeAoBHpDb3y6XlEMhbnr9q16aRpZRiUwr +4jpGQO4xwCKjBzTNGfemlj3vxMGsEe5yzsT3gqrUgEABAYCgcCJkmSES6wyK0xhFH+UvQVeW8fg 29YPCWABT1kA/rQUqVweQvi8J+ZxihUqYMIxmDYbnkgC8pMAZO5TuUNWioR7/GQfV1J64y0bP9Xp KoMlQAAAEACSw1Nl1272KP2FcpmjzEXIUbl63dTMc01bWqumMahxcfKZzXxnJQL5vZ10EXjHS2CX unCNwg0ang1t5y9euGSStQ2Rn5KAARRkAPfdMxkdfKYS84TMiD50p5kHHumS1tJ+joqRiQOABetQ dVS+GaFRxmlYe1qBM/vzl/lMZIQ0wCwP6AxzI3lFzsmlzrKOdbEd9x0DDljIAzswVHLlkBpPzqXJ xpWrT7JpYmfb2EY7H7BzyucXNzJRB8gPAlqMU4NeWiF0Gfa2/rX9bqLxL8wDpCxvw4KALQvA3BmG M83uqOOcxNbdA4d30lhZ6zWfzc1hJmk6xbjuuWCb4BMv+L1Gy2o1ehLG+VW1WmspLYArluIjr3jL bhu/VSs8vhGAwAAG0oAt79tmfM7gnO3S7pKTXOe/iizC2RzFZpPbILyuj8ypxuZXItba4Nx503Nu rAujnHBXRS0AHHCQBLt8AQLAsH5pziq8CPzpTif7n1bsb1VP/crPokpCHDAcSqvw4S7mXsgDvvSx 573sNgJy/NpVRtQK4AERiLSQIvD2c9s6yX3OC873rnfI90jRV5u7xrEnFQTYJ+4H4Ldv6e5vu4s8 8qN/PJnO/p7T6Ob4uZkfgK4PMmm+JeQstKIPcb6e6erivfSk5z1h9Ex5zzeLp+LFLTcn9c5ahj7g u2d+702lZk4S37nxncAAEuCAozdGOFqV00BvzRexN1/8zhfN6Vm8PhTq8SAQWIAB9O16arI0o5TC KPpfuheJk1//46/L77tu6bXLGZNpAHwzgAXwsN84Du6jk8I6uhdqPP7bPwkUjcmzIz8SvgNLGAeA NMdwj+KoFPhYI6IaKqkqQRM8QRRMQRVcQRZsQRekkIPzuV/rIWuqNbhaCEtpwPNTPsXSvQn8wQhs iWiCPjlLP2JKDAgQEpgbAARsJ/24wSepP2CCOPDzwSAE/kIs9IiZQTkTeiVci4AEm4AtAwACsBoP 7D6uopng+ovwy0I3vMKY8BeJErS/s7x1Ohv2AwAEALGv0ioQ/EDJkZ2+cLw3LEQ45IiTg75EYpXn WgsCsDpek6RZ4SaFoL1p4sFSyr9D3MRC7LlQW7zdarb6Gg6uAwDOG7FPnEJB9IsY4kRXNESSiDpW U7zLaMQJeIABEABdIwAPw7F5U8X7Az8jekVihEWZkT4Hiz5m2ziqgDRJozRfTEZbe0C90CJjvEZX vKkGkyaV+6fHMDXhSDVBI8LgC0b865ViTMdCRLb3cS85I7Wz0LWCiERgC7WHa5bACCRs3MdDlMXu giQa/ly5iXi2goi2fyRH9cFEnGAOK+RHhyw2BmCvIOu84LA3gyA3+zC39loVHMNH0iBEdQzJyKMq X0Odc5k+b7wKfOMyo1M24FI33WjILBJJmpTAKfOdMUI3gYFHl8xJaiMt3MM/mXxIooyy0zGgPesf XDMtFptIaTSOoZzJopxKsiPJysu+BLRIZUOmfloyzTgNkKRKsUQ0w7PAAqvDsVhK/jiAXnQvnDTL mEwNTRxLuqSwoywpwZoSnuyPBdOv85Mz41iNsKxJwiQ2PbvKGQzAqBGPBJA5BGgAlounKttGw4lK mpjLwszMO6tAFyMpvdRKGRuIBXC5FfG1VZHBjWqN/jbUTNY8NPNTQ50cNTebgASzjwUbzX2SKC6s NtgYzLr8zezyvzo0TSLhyQlYSX0zCAHAvoRjSnULSsLATOCczsaqwKSjxVBMyV+ULMCMHYWkM+oM TxR7za9Dy3C7wzWBOWzqOIejNoaYDt9sTfnELv97pcpztOp7wj5qofcaIstUpv8UTwHFJOsExUVD ycvDlSS8rwXwMvyqud+CztBYzQGtUJoiz6bsScVMG/OYgATgPAjgunJ0ord8mgAtpflMUTyrTwNF GHikzQYgOi7DylG6I5DTDulUUR0tqwK1QBLdUHWBjAdQQi6DTKugRaeMn++8CwrdUSfVKwwtQr8i /giL9Da09C7gYzzsiE8L7dJUYlEf9R/8RDvNsETVYghtKtElDbsT9VI3ZaAerTx5qtIhnYAlhABM I6wQRL7vqpEmfVNALaQopUOXws8wHMOyXCmI4Cod5Jw29QkufVJJbSYwlVPVE0WEyMM9LIu0jMK4 CsHPo8LsyNFALdUPitNfNELtLI5HdIBIREsFZFTve8dH1TRTvdVUGtSO7MYErYpHnFFTJA/ayywp 1EsWJMEXTFZlXVZmbVZnfVZovRBas8dNUlVxmwpc1MUJ4EU7kr8UaUDgklDXINVJLdc5WhpqNUmq w1SOQxFiLU3Qq1WhiFRcrdflSVSEBEagW9WD/qjTrYO9O9FTWU1D3hHX3pRXe01Yl6nUaGREdj3U 4XioHNxTUK2iNR0MejVXjT0iVEXFnRJIhtBUguIw2msPbjJZzIgkg30NclVYlw0bXZVGXkVPVtlW SOy1G3tKFELYed1YnxUnhlU3trrWsPjVUjxFWiLCzOkhMGnZn31a++nYcVxXZnyKbN3Ftuw3G7Se iy2MjH1ZsB2amL1Ha10nInHG6oNGZuFIrIyXMPlaqI3b5glasgWsqjUIcFQIcSzJvzpQEuNZonDa sB1ciZHa2PnYVc21XcNZZazbB+sTuCVcyXWodrXBB9NKgpwAg9Spv5zCRgHc6pJb0UUiuq1W/jt0 FfHAyKJbtuZyS7f9EsEdXdmdG8NV10u924NAzpacUp2qKqCB3NkNXgUa2+kqW9TdTew8yclcxbcV Xuctn9JtW0aiWUVk3Tdr3a6VS9CdXO7tktq1UeNlO8pcW+5Mu/0KlMh9XvXNF+J1wJnFsoHsj5pp z8bNXtWI3e7N30KJ3skaWrN1Qv44N/5Eyvf8kz9dXwRume9NPVhqNlI0AAVgTsC8QAjVy+0VtgTO YLppX31dRqK1UwWoTQAYAARYAFGzzyDyyE7BXw1uYUHhX2QE0hJ5iAaINNszXzyKs8u44IjTXx+u mAV23X394AYI4fog4RnrukVKtwQMlZQ5/uAfjuIREq90BTwH5jIIxj4b7V9wUzb77U19dGExzhdt TNd02jD/KKklnra0BJUrkWI4DhZQA8j8WmI/S+MgMtA1tiVB2ZQ4/mNQUTSERKYvlFLpTbcdWlkc scYxbmRviUG2ddzphd8RkzaH+1E+9pRecQ4WBmRPDowyJlPwPV3x3U2IQuEufq1PyZY8gWJHfmUe MacSna7LZdfDbc6MM5svZtmRaMVP/uUaQSvn9Dn/PV4rbRJtmj3bU2bJbBpFXmFXBmZpFq2zxMsj pdpePeZ20tM/xKhX2WUeqQgehmVy5glt3OLiJWUBRKfwmFg0XNS1eeZVjuZyrmcmquZZ/qaWSWY7 JdPnODm+ilUWcG5aerFng66Ocw5VfMbAxK1H4IhVBvQ+4ixgi8GW9J1mjFYJWdbNe6xl3PW3NQLE b61YY41WoUJWk05plV5plm5pl1bWhB5mA11Kn6zZrYpogr2igRYTix7njPZhWvPdzsRm6hWxPruo kRbpq5HncBHng37q0BBmetPQYi7lmulQZ3PXWd1Jugnjn4Zqo5BDz1Ti9+XnR9KYlAVopa4aps4X cf5quM6JaS0m+6vqdW5H/UTZSUzZZdlpYCnouA5sjXbJc+JO48xZzzXdQi2dtwZrwYaJLQSzUQ7f u54iM17oHPNpQPFlx+7smZBD9szj/n46T0rurcpdMxUeHYv2bNY+lsFRXjyi6as+bbg0x9xp7Mdu 7VBuztFG0KKWmsuGSYqGnopobeP+iLusZnfk2tkUrHw93LPQbFHh7Nz+5JECNPMs65xxK1EObr30 IMA+bscO5fKdqOYGbtomVL9uGdwW709OxBPG4VrEVO5+7qNr69AJ7+qG5Y0ORKSj7MV07sK272aR bnDxavd+5Zgm3+ye748Or/SOLvxWbU1JcDjub63l4uz8YGN6yUFGCAPHF/228BZecA1H0sMGKAJn sjcq7v3m3jm+5B9V5wDPKmtW2oOaoxF/cecN6hlvXe2Omvr23Q8X1UGibhJPWHZk/nCv42LZHvLg LnBU0u+LTnKa7LZFPHG+pVL6hi5pM2NM6SVxHkYeB1R0Vbst51wZ7nDTrl7bnnIZKfOnFes0Z/IC SnEBZ+dUnPAP2pQQt/LRm2uuBEC7rnEo//I6znFn2hR0lHMBBW1/1nKdXPNDR6NUNHJe0hSMyBKL JnNAT9HIDjIkXZgn9/Kp/i1FD6cmfeNPF0tIt7Sa9hA8t/HxrQ0+5yU+caNWp8mgRp855KRSj+dm SdNKpMTpWm9DyhJWd3ROXPLErLkQIW2zZvMbzqj5c7Bbr6lOR3Jmd75e584TX3MVXwtw9VZOLTBk Z6ht3/FdH0l6S6c03/DftmxP/n1XyUydbC+ude/kdk+vb89lOg7IhpYleGaRkW6pTUr3xlr3bie5 M6/rhit0N6lvKbT3X6dGsruSP294QsJXX7e/azawgb/qcr9peK2Vl055qLoSlW95l395mH/BMxfi sb4TrTxrKPxAuQrXjV/4VvZ0jkcvjwd3gJf2yjZ1gy8sS2HnfCe4jVj3ng968pl5Cq563y7tPOdT BdQsNcETmlz2fg+tgyv6xGwzgeyppynZ1qqqph89ZY/zsCeri0Nkqxf5bM7z7rajvo56Ttt3qVeo RATAsvfg/82qSKZlFJpUho/7cPLESx6lWX93MCcjhQdCjf97QpLFPUblYE+5/nZNt7ZXx1zXdczv Ikh+fIeLfCrycMVuEr53e464fMZPonPG5N4mfGPmbj233cQH29Fv9NmPWlz2fEm5+RW6cXh5sNe/ wt9n99JfHEEGedvvfN4+ZtTDdBd+e6BPqOe3mCUfzppXWeN3H8Tu3B5afof0++Rp7+7HF/K2ZIin /gtEfocOfZfdd7hvf33ZaN6t0asHCAoCBQKYEGECwoMHExpE2HBhQ4YQFTKMOLHiQgALFDDg6LEj yI8iQ5IcabIkypMqU7Jc6bIlzJcyY9KcabMmzps6c5ZcEOAn0KBChe4sytMo0qNKkzJd6rQp1KdS o1KdWsDiw4pZL2qlSBHA/sCwYQtmleiQolm0ZbFiRbvwIICpcqvSnWu3Lt67epES3djRrwLADIYS Lmw4aN7Eexcrbsz4sePIT6+ybXt2K+auYMWKLXjx82Wua71i7IpRo+TUkFerbs16NVCdgGd7pP23 Nu6Oh3fzdu379e/gwIcrJlCWdOaIykl/5dzZLPTRydW6LV19Qlzh2olz3+79boDvIm0Hzl3+NnoF vNcbFt/9vfv48EEW4CoaM/PLFTc7J7j8P2imBcjWW/rBJZh8Cc6nIIMLOsgUeRGaRxt7FQqF4IMZ NrghZFchl59+AOKHXX8DkUWdiGmlmFmBLGanIYwcyhgjjTPiJWF6OJZn/iGPNtb4o3eU2ReaZShq VqJ/A6Io2pJEEqgfakBK6SOVU1pZJV06avkRjzxiiCVLAVz5nnEtFhggaPnBhSQFJ67YZJPRmani i2DaOeadeeK5Z1Fb5jghl12y5x1QX/K5l5ClTSdniBmx6ZmT0jH55nGKGhSlnpkeqimnm3oKlZ/n iUqeoBUaKtKFnTZVn6IQjThifvz156aSIsYpaasN1fkpr6r2+quvwRIX6palngrsUR7m6up9kyYk q3OQMlrrtJHOGRGmyAq7rbbdcvstcBIS5a1VLKr4qpq6PlpttbfCmeuu4MpL7rz10nuvUbHh65Rx //nbYqWmkYiktLgy/squwWZmay/D+zb8sMPehhdxUayae52R6ULLGa3W2koptS3GSzHJEJtcMson B6vsvwaqCPBEGz9XK7UG4zrnwinrrPLOPfP8c42JXlxZy6TJPBbC79YKANPSDnmpz1EDPbXUVVPd mMUwC1zdddiuS7PH1brpdMA5X2012mernTbbHrF8ZpHQDdkcwUl/rKS0brY88tp9t/2334F7q2zX Wr9cWQRHmwhy2LiOXalbZgM+ueCVU345lkLH/WqKdJfYsd3IjZa33FBifrrlqaO+eoJZB4w45yJ/ 7XHNTT5uX9O567477737/jvwwQs/PPHFG3888skrvzzzzTv/PPTR/ks/PfXVW3899tlrH/zbLnPd qLmK+2ez0taSvuilAvu7vrPsg69++/G/7/5+8M8vv/35078//vwjpLf/9Ne/Ad6vgAJ8HwAJeMAF BrCBCvxPAg3oQAk+sIIUhBIDLZjBC26wg3r7kPfQZxHxtYlxB3McQwoGQrIFDGNPmhMMrSNDy9AQ bjUs3XFY6MIY3rCFL5yhDYOIwx0CUYc/7CERkXhEIfqQh0yM3BKHGMUmAlGKTrRiFctixCtSUYlc TOITpwjGLWYRjFj0YhnFqMa3QMpworubFtdFPjjK6XxxSpyliAYwPWqFj8rxI7P6uMdBCrKQ2Mkj If+YyEAq0pCM/nykQwAZyUVO8n+IdGQlG6lJSLqsk5fcZCY5WT9JepKUnxSlKVNJyct8MJSuLOUq T/lKWcISkxhUpS1pqUtcgrKWmgQdCEsnPxKq0ISMu13Y2njGMH5xjWlsJjRTCLlnUhON1mRmNYWo zC5i85rL/CY3v7lNM4aznOQ8pzNrOM50drOd4ERnNHU1TW+ak53vtGelilm0dmWGmKEjkruw07RF fUWY2bxnPN1ZTycCE5/wPOhCIQrFeSr0ofS0aEVHaNCLOrSjCT1jQz8aUY6KFKMhlahHUVrSJXYM bkI0EgRn908BOYmQRtLnLmPJS1TqtKeGxOlOZxlUX/I0l34E/qpPe5lToya1qL9c31CXqtSoUhUu UG2qULFK1Kwy9adX7epUtSpVpzq1mIYrZLocVbc5polSPUSXuUaa0ZXStYouTSlJVarXG961rnn9 61ztejjAInSvgX0riA6r2MISlqJxxShjFyvXjWZsaAVcU93AdsJ38fV9aIosaCcrWhduLbSQHS1e z+pXyZ62tU8qLWpXa1p7Oou1qZ3tSmHrWtnGFqXn+uz3qONPtgLUhJBMl3Q+di6CKpe5bV2u6KKb MFjR9LnOLS50b4bd62a3r6+TLme5K17wNpe8wIVrd8ur3fRa17zbJe/htBZe97L3vesd73SR2977 0he/8+Vv/n47Rz/5qiuztGtcQF83YMv6V73/fbCD1es+GzZ4vxC2cIT3O2F+1rfDFbbvhT15Xg/3 t8QADnF6aXriDIOYxSQG8IZXjOEZt5jGL3ZrWmfotbUGtK1ge2l8M7m5D78YxUSGq3SPbGIjL5nF 3pWhjZUs4xpT+clDbnKUsUzlIidXy1zO8pTra+W7fnnLUmYyg99Y28P5U7PJJe5GlavmMJ/ZxVK2 FIjKrOc6gxnPyeGzmb18Z9jNGc2GtrOgk/znRNOZ0Wj2c6ER3ehJP/rK0wzmkXhszDz3OITwHRCg 9+xoOH5PxaKmtKRDDMJJBfLQYHZ1lee5olDTetQ+bm6t/lH9alLTcNa2DrSuY60W5i4Ybm0+8GY3 vRYJBxfYsD71f0ub2GBDO9US3ueqrb3rbQNb2kPjdrXBjV8P5/rZg57bt52tbXX32dddRvJ+5Njp wcI5zZb9MbvzHW7qgo/A+/73h5GrYnwD/Ndi5pyAOVzudZfZyAsXt5YFnnBqPzzf0y6f/zw3K2Wz GtkBbl+vzW3wc/f7YJ2GOMVNbD8Ks5zhFb9xjCtL8JfTXNw1T/mbO/7umY+85zmvKYKDzJXhzjt2 HA8RdYnIc5yLPOmyzvbSmy51p7e82Qr3+dRzXHVLozzrFnf5zb2e4/XCN+wu13oIg7xhjUfr6KYu +lcG/rpytDKu62fPSu72I/dLDfSsxDY7xPWW92f1XX1/x/rd4840vS+e8Iv3e9kRb/fEFR4ucrd8 4wUNeHWTBVt7p3zmBRr6Vtdd3wvvfEY+P3jMR3DMZyH60eG+ItIJnMKHZ/rdH5c+eeKR9/S+vdfD /fjdW7X3xf995HGPct0b/5DNJ1uko554ROv+kPJ0viVLv9zNe3j4xHe+7u247OQH/8jef/73ySL+ p1H32DN1u6SYX3Iyp5j73KU99q0vflyTf/qBt/7x6R+2QFojnZzpGRz+nc/+WRfw+V++JeAAol8M RZn9kVdBCN4A5p9nINP29d/kcR4AWlJGiKAIcqC9/sWbprkZp8Ef/oXcPrVYwVGbVaUfDZbaohHX B36Z+mVg8SHT1pGe9OUgcwHT7figwjWgEKoc84UfD9IdBUqesylTEUqTBh6hBx4gpSlTgWwgFa4f 0GmMTNWbCoKM/HHdkCEhFj7aCAbgDo7gpW0XGsbgf3Gh7wmgG1rdDRqgHJbXBYaeAjYh/UXfgSWh drFhHdLh8dme5kFh99WPG9KeCYZXHNpfBO0eJEpTzbAP7I1h/yEM/tkUjhWg9m0eGzUhIuafKDLg Fe5hW0GK+J0iUt3XJDIiZmTeiUxhHaYiHK7izaVQ4YVgG2YfHh5ZBWLi9fVgFwLiIFaSHvZiImrU /gzOoBcOVqyEoey935LInyKS3fjhYBpe2x1WoTjmmXjNovKx0usZox0KYx7ynzeyIgatoTh64bD1 lzmK3TFi3yXmIrqZHik+iyNm3z4G4DvWHy0mViXeYgRG4oKh4OdgYwN6YgR6GjOGIhAuIzx6hdPg IkGCmj3yIiPyDkDyHkNGRzmC5DlGIwByJCp6pCyiZNMF5EomYzhenC6S20HG40gi4/VNY0He493J ZCmGYzCG4K3dlfuJocf1mDa+YIcJ4tXh3CgV1CMqIx5+ZEEiHjSS4Doa5RviZFZKZfrI4x/W5Fee ZFjCmtEY40C2ZNjUI51V3FpOZFfCIvxB5TkK/l0I5iMerSFD6lzMyFvs3aVytCC8XaTJ3WReJh0L sSRO+RtaNqPPmSImliShmRlQcltBHaNjNmRcwqSkaQYPMqFZchZeYmVMLocUViZNsiMn7mJahqZq ahFWkKZrFhe6JeU1KiVo5J2i9eNTdqNkThrjVZ5v/k/lwVtUwuVwqqU6gl7eJKdNLqdilh/u/KLo Refw6dconqYDgshxIud2hieG6Rgx/lqsnMYvHid0muE/IWZK1qJE7I7jtRF5/tx1bOJSRuR0XebY eSdwZqawvdZrqdYXdqdwImiluVGuBBBowic+ytxlahK2YWQ7BqF96RaDdVZwMqedkVwaHZF5/nbi S8amhjmlC4LSRd7RwDzka76dsomoAnnocwEoFmroteSoCAkoDAIa1DWod9koWDYnOAIdkEIZwj1o RWKoXnbNV10RhI3oZ04Zd+qoKJ4hiUqikjbpFH0l/TGbfr4nYZIW2lVpdaLollKdGhUobp7pE5po hrbMkcKOqfGoQVIp+gSTlcbYnWopnC5QqVUW0nmZjaoijO0PmzqWlMqeoRLpjMYZgwrWYOlmjPKm kTLSBC2qnCUokzroK1kpTAlpZCoor2WbEjldgw0pqcoPpoGqXqbqqGIo2jmWqdJoj26jw7lXmc4p XKbbrY6igM7qcXkprbpPmHrji77bG+7q/jAmH6daKLOeqquuoK1SJ4TK5po1U8xB64cq6QoiaaIC Jre+6XAyEIW+YKFiV7p24M/NXaKiF5paKruWq6cmEp3qHL9R6hhCZI3iUKbGq2k+a1QCarh+UqyO q5sOqMQR2AQ6ZZQe7MCWqob+kIRSp6riW7QC2STCKq52q5ommY5mq6/2qYWiYbQWK5lRa8kdqwEm K4tyacbOq0Uu6TKe7GMti7XSbM7+aqhelo6R1mEi7MXWrAihm6vSEWgObbIdkMa+5rUGbLWiJdP6 UNy0qmclrJj+agc93b3G2rNYY6Uy6lv+K6umXYdiLdkmXMjumZ2arJqOLA89Kakqbbt+/uzExm2z xCbdxmzPAmczcqxJEurbyqm9Gm3Q8mzJ6qrdSqjhHirbcQy/yis38i2/jeztCeziXu6emlvbOmvG Gd60DS5Q7m3l4o+e4uzC6i3Epi19ZSnmtu7r9ufa3eyy0mmx6aylXuvWCiKDlk9gGhhERi7CpG11 je3TYmndlu1v4ezOXijCHu+uIimmFi5sEinpFu9/dtK1zN3xkmyjZm7fRgp/ruvO4S7Ilu7VIhZF Zm/Uiu2Kgq87gmt20YlgOu2YIhvlCm77Aiz8atbadqqooibr+ufyut7+lufBfuu2kqlB+an1Su0E qWzg5q75Tm7CFk6bhu5RfhcHHfB+/vbqAPcrBr/v0IHtvkoui2rQ3PYad83ZBiXY9tppAJdozEJq 1zJs9a4wVmIv+hJuFq3uw8KuzZZnk1nhimmqyPYsjvps/8qsy9Zu9BJbP/5mLdbvB6PwzObvqjqx 8cJsmMWtDMfum05t45phrs4RAggA0xwABMBJ49WuadiiFi6vQBWmSAJxhKUYAaks+wWxO6IY73Lw yQapshKvB8+UBUVbrbZpprnoFcPoE4NwIuvwBEPtC+dxwyIuuW6x3SJfXOEnZpIXAgDAA0xAAwDA AHjM+REwWgxf6PmZrhAh6OAxAp/vrDpZ1v5kEbOwyHbQ9DKyFn+p6xruLSvuV4Hy/uM+BwVHMkZq sfeqqxhnMPoqsrdpcijrbdniq8N27uhA37m8stEN0XZ6qfd5Hic/Mz8ZqNoVLTrr8hdDsRdPpwKr c6YeMjeScZw+GSE38sY9sfDC2STX8hxF8yUf3ObM8BmX69jxG/vyaUI3xACgcinHjPptoEYIgAEc xAMQANMYAAQgRAKosUdTngEYhytftAEwxAEwTQIwhAEMwCnLckJE9EFAACojZwMIAAFAxEoDQAJo NEcDgEebcdChKi7b8zBf8NgiqgaNcNA6M0If6EIrrlNTKBim4BWLbfDWMOBaMvQObrQRaICmaVRj 8PxycCWPb4mactMYwAPEHd8h/icCLAAAIMAERPQEPAAA7HQCaIRepzTTOEBc891c1zVCjPICnHJL TwBij7I+DV9fL0AE0PVPC1Rh23UEIPYpK8BdF4Re98tXq13HqZy7PbADuxghp/Y0J+/uGhBSy+ns nrXf2rBD9vMj32/W7rG13WnsTm06U9GPWjPpJjGvSa/4CrSNKcRGN00DEB5yxnXiCMAEqDEBNLdB qPF8uqJ2X4p0RwB2J04qe7dF08mJ/PUEGAAACDblcTdCfDcqi3d1J6njVu38SfNVqu5pE7G7TjIP /2gwI68eTnUhPnUDVzFWiykzIzJYo9rZkrBRJ5gP589rP/QGF6nVNpsf67dB/jxARHd3Ha93Hddx TjONADR3Ocuxc4c4far4Y0uLGtu0hzfe49HniANAidcpVYuY0SmxIAu3O1NzOHP1PBsp8d4u4sY2 O4NuycGPvu7nP19jNn8jb0uyz2LszTZ0954nKA94L6P1EcMYRaf4jG+ghzfAKEs3dj/ESccye4u3 Wbh3S4X4Qaw0eh9A6rH3dIOOmds4kJ3odB51+VqsWnsw0Ibu5452njaxsBI0fR/couc4Zj3kMt+2 +77qwjW4F/O22nYw2i5ikCMz3NJbhrdpRDtABJwyZnf2AyiAjNc1qk8AR0OATQ9ABET2Z8u5HCPA qzO2X990ZqNGOd+5QsQ0/gA0t+XpumH/+gLodSrH+qyrb4VXaFjf2ugO+pkyr7TveJJ/sgqbrlJj KxP7+euZsJNj8Ysi+h5OOT47ug9Hb1lfsycPuRMSsKCHKgT0tACkuikLwAA4wJg7gE4bRAT0NAF8 dK13dBuvueUBfJkYhGMPtUEYQImPHpt7HgB8NN+dckovxMN/9L0zTcFjUu1ULqDzeLUntYM3rNUW b39/nKKjqpCq2oJzOd5ZMYJTOmFqOyEmt6WTdr8acqe/szZvMDnOtmnTbn8erdKjq7/OCUc3/IdL KxpR+wLns30H/dEbKmxJ+GpT8fx2OwfxcvmKO/damsA0ud08+WA6IJfp/nHZs/vLUq7zNi+G07du p+yXey7eRvjSEyhaN21EPIAaW7flCZnfM5FsM3Tpyfvc5z0FK/4+o7vEUvt/13AgK2wP6+JVS3ql J7i8WqfjCyofW/3XtzYSP++gEjnRy25o42kmU23fm1EY2RXTDABns9Ecry0drTNxL+2CTzglf1Y1 E3e0S34fhz3Yd2NaB7R8Mzm5p72543wxtiwB0tjoq3zmNr7Mt1w4O3S85zE7g+LTxP4ZUROm/uzA Saq7ZTrcV3kOSx/JGvfq43DL+67dv7y7o+zV1159Ox3LAsSECBMIDhxYUGDCgwoJMkS40GDDiA8l JqS4kCFEhxkrTuR4/rGjxY0aLXqMqNFkRZAIWR4kKfJlTIohUdJU6fBkSZs5c66sibHnx5EcSXok 2hKpTqVCeTZUWvPjz5lPQ4J0eZQlzKortVodmtJoULBapU7tKVPmzLFib7LNevVtW7lx6XalCndo XalN1c4FQAFwYMEUAJDdmtKs4cRQv9p0zLRxWchrcXJl25TyWa+Yj04MOnmn3a6I7V5eLBI0471c RyeF+9owWtc6YTfGelW1StmcccfGWto3a9OWg9vm27k1ad6+OSNf/tx5VKe9NyPXm5fz38GDC9uO rNj72NOngX4nTvk8cLyp50Kmizct8PeohzOnfR86cfaPTSvXjX82/qoArE66ympzaz72PHNPvtzi Wo68x0BLj8KlEJTMOvXka+26DjeMj7reQJSrudva0m67wArLzcHwwBPPRQz74888BZOb7rvjoINt x+gWDCtHEuv6MEgagUTPPs3gC/BAHP1bkj4cl7JOMxr7qq65zPIqDsnP6vvSPC1nFLLEHn/0EU0z DcwqTQZbFDEhFFMkDIA67bwTzzz13JPPPv38E9BABR2U0EINPRTRRBVdlNFGHX0U0kglnZTSSi29 FNNMNWV0zk49/RTUUEUdldRSTT0V1VRVXZXVVl19FdZYZZ2V1lptvRXXXHXdlddeff0V2GCFHZbY Yo09FtlklV2WL9lmnX0W2milnZbaaq29Fttstd2W2269/RbccMUdl9xyzT0X3XTVXZfddt1lNSAA ADs= ------_=_NextPart_000_01C35CAA.EB6EF8E0 Content-Type: image/gif; name="graph.gif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="graph.gif" R0lGODlhMQNvAfcAAAAAAAAAhEpKSmtjY3t7c4SEhIyMhJyclKWlnLW1rb29tcbGvcbGxtbOxt7W zufe1u/n3vfv5/8A////9/////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////ywAAAAAMQNvAQAI/gApCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN mzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izVgXAtavXr2DDih1LtqzZs2jT ql3Ltq3bt3Djyp1Lt67du3jz6t3Lt6/fv4AD010IYEKECYYRH07MeLFjxZAbR34suTLly5MzW9aM ebPnzqA5i/48OjTp06ZTl16NmrXq1rBfy3ZNO3bt2bZz4959u7du37x/Cw9OHLjx4cYBED5eHLnz 5tCZS38+PTr169azV9+Onbv27tQF/osf/xf898XKFRY+7729effs38uPTx++/fn36+Pfb3p9/v/8 AXhZYQEil15CBOqnoIAMFriggw0+KGGEFEJo4WwJVjjhhdP5t+FuByLkoYYkcmjihyWieGKKLK7o IogvtqhiahnOyFqIB9Uo444x9mijjzz+KGSQRHqWIZBIquhfkY/haNCSSTIpZZRUDlnllFZm2duI V3bJno5aNuZkQWBiaaaXZ4apZppsoomdjt2NyCV63H312ZK8rTcnc1AetuYEYxLUp5t/FtqmoYQe qmiilQ36ZmRw+pkYdEfiCel0gEJmHZxRBjoQp4iGuqiojJJq6qhSlnmdnIxVNulx/nge2eSrv0Xg aHGDSuqjpwLlWiqqvwZ7qrDADkucr5sFgOGlmXKV2JLO6vmsYl1lJqth/iVYmLPocYuts9g2i9i2 cnq77bfXhksrrVbySgGoxMZrbLH0ylvvsPBWFsC+ssX6rbra/ptpuLZSa6234xp8GLfSAmwwoNLa 2nCmC4/bcMGNtqorkO4ia+/H84J878gic+jrZfvuC1ulCVdccMUtZ9syxZaZOy3BA1uq880yw/xy z6LBq6uQHWuK2KshJ02y0iUz7TSTQkOWcsqtsYoxxgHDnLWd7B6NtcIDvwxxwGIqTLbE1YY9Nmce D11i0Yut63bTS9dN991P433p/mJT9+333347xjLNEYddOIGRqkun2Fmr7bCuMhN+s6SWOk6n3Bqz WDTmceftud2f6y166KGVKamfgSMt2eWMP7w14mZPGzfNWoO9tey3E3x25Lt33XbXF8LtdeZzkw76 8aMjb3ypjmZuWMqdbVbt4hRDe+7CaaO9+tjeoq3t9BZbT6Dk3LcKvvjOX0388D9uvvH7yUPYVQOJ NZA9kWJB3CDCxD1gAPCmQYAAACCABJyGf9IBFwKrVqmwxG95rFPd6RSjrM0ULzOUkR4Gh8caz9gG fpi5oGZURzOjmXBFwjsh/B6Yn64cYDEHAJ+a8te9/4CrOTeMDQK+YsDSpSs6/jmMTQ3zx0K6Na9z rQIgBynlKhGGcIOqyeAKpbhBD/psfUabkfuwSEII7g8ABshWGBPUgAEAYAAOSMwDCMAVAzxAMRBg IxjfOAH/cYUAEFjMAgQwgAd4q4xnpB8Vu8eVB5jRjRaDAB8N4wAzorFbz8rQHgcAAQUCwJBz/NYe BdAAP5lLT17xmgMA8ELDxDCNjOEKBCZgPwFYLJLUAkADBCCABfgpjm2kYwRmCQAERFKRA3ilxGZZ S0kBEo2T2qT90tU9M66yksHkijIdc0wHLGaNbcyj8oJkOs6xb3ubquIHR1icCW6viaKhngqxuKEU etOEXgwQV+xHP3pya5Re/nljBMzYFQIkhp93NIwcuRLMCOCTgOBaZlf0aUJwWWyAbUQXKVn5lTRK LJb16wpEvwVRMIavK6i8oSXBhxgzHo2AkhmgLTUl0mx9hX4TACgA/GlQryhAoqUc6fwQo9BC8hQs vhvfBHZYz15yjysWPahP9+kVmm6zR0f8JvDQiRxzTvA16RROZCwIxaxGbZ3yW847MVfE80TrhTHU 3wTY+MZR5hQAqxQTXLd6GD8SiI0G3OF62DoBtxaPkEZdpsV8uUo2+nKH/tQf9hSD16Fa0peCldhh Z/qvxVpWUwkAgC0XAIAEDE2vXOmhYtUqMc9mlqaqjAxb/RhMiBG2sqGN/sBpBXrJvpLyMI3NLDM9 ZD+0ylKyjk0sX/0KsbjGc03dnCI4s4ipjaUvq1bszWPmNhoP4mydSHQifNwJwm8eF0DOiqGtXsiw r7hyArolwE0Xk971GuYBCZDjt56pU66ct1EZ+uR8YWnZlv5yApUEJSyLC2BLYlRgj6mkP9kY11Yl AKA99C/26Eug9g6YcnMdcGoD/FH77pfD0yVtgV05wEQWGJReOa+Fv7sr561vdlR8bq2kalXoPpE3 MdbuBSOYXakqUT5b7DF2n1ofZ3E2jPSrr7cSYIBDTkoBTfboLjtrVxOD2IGYQZh/RQwuDo+2pREI s4FhC4AwX/TMX94T/pIpe1XDQICziHPpgUGM3ij/D80YFZyATyzRtHHrovhtDBvth9oyiznOdjoM k53M4nYx15xdZG6kZxxieJLzx7mR4Dmj98TfCTms6uFid4ncQhRXlq+dCeJiJzDAB+CTtnkFF6ot jeA0VxYxhg3ut9Ko18Q0ttdotuQB0EtZiPF6y0NTKEw7N8A0Vllix3apAmTLZsjIGgAO8ON5g2jJ ac92rbV9TK6BLZkgZtaMnoXYsGcbgVkHuqwkiuqQqYpErXZNuedUonbz/ekaT3pyon6xgILs4+42 2j3giuGw1dpTKQ8UjIt5uAEOA9ASE5ug9/zK/zSj5e+9MqP5xC1Q/g2jgK7w8+NnBos1wZ1oVnNl 4a0aoCtDXHKv+JLloewztnHtlYlTtCu+RHN/K3qYht9ZqTnU86sUalGVHwbpd5b4wV+U3IAvd9Kz gfHRNM3Veud4NW2e99fVOdZR64e7ARfy1IG4HnpedgFmFEDQARxDMK7yMBCouwHuDoFDVhIBh1EA H6tsGLgTcO5uy6F+8WxQRy4blwOILGISwMcryxlixHw8GyN/QwcM0Oen2+HNLyP4w6tx85KXJi07 aZgI6P3urBzg3LkdZ2VCxvByZwwx4ew8VacN86u/fdznnvdswttE8vYmp+lqHLdpvbpcDzFWBQ5W 6Rvtq2W3oVhH/p39428oPHNt5WnGSVXUpFb8z62haVxc6dAEZ9OWfiL8qW/9rrGxlEKPrvc19+js 31jSuNF1AHhCMuZ1NkZ9WMdBYDNvytdCy9Fvabd/EGIdYwR0YAcbB3gaFcgVc1czQuV+XFWAWzVj MpaBX7cu1dV+gzZgpCYsycd9yyeCpEFdMVh//naDVQRpOiiAPFZwEQhk2/eD77R2FBIdrmdfHbh+ UWSC6VR3uSdC6peCOfhj+waC+nZpAhiC/zc8pgdJOCiBjqZpMHiF3gM0WFV/YMI11JUu4wczJDQp ibM+nuaDBhgnD0iHeNiCP4IpVweCS+gqzlEbMwiIJ9h+gjh//jvWhkzITl1Fa0TYKeyXhz82OHG4 hUjUJ4PjfHuiY7R2M2RVaYojhAa3XUEIgaYIhv9hhCNYhUt0ac4nHVmniGToiuT3fLbIfFlIRYmI adWnh1hSdacYNGUjNoJYaTriLwYYh4N4b9e1hC4jiWMYH2gXjEPoiwGiisw4iFaYjeVUjFlliCKo dhd4hbmIhaC4i4nYY4+IKC8oAe74jhLQhw9DGeQCh4pXPR1XQqGYSpNTj5GUXzZzLs3yPYcTkJko ilanHQTHgGOIiuCRgOPHb1TYildHf97IivtmkelIkctng7JoiZJGiFtnhXW4jjsCjBMAj+9ojifF PwyTMIrz/pK6U2vd4i84I5O8wzMRI5PkwzsXo4/RiIdmdYcMGYEmiR/i2BoZVI3ymERtlpR/OJEy GHZTtZRht40xloAZaZWRBo7y94VHqUWRqBgq6Y4gqXTPyCVAk5PXVW5raTuheEVpOTOR8zOx84xq Q41BuSqlCI0/GJbtgW9/+IoliYugiIA4NpUDiE7K9YoK6IzLBZUcOYDPB39KyIgOqSSQUZac2Zmc yX6woy7lE5Oh1DqTdjF1SZALGJOseZN0CZPqM4dFWZi/MY1+CYGZyYdX2UGOGX2N6JHqmGm+qX/y N5zymJEluINNOXYVKZhFmZsmw42I8ZmqYTU985ZyaTga/mOTqSk71gab3gk7czmTM4mX2LeXEAki fTmbQmmN9VGZsdiIismSb0ibxTmfYElWzUmfhtibu6mYzjlkfuhd7slNLPmZ5scsZBNn85iT2cky V9Od2mmarwObDpoz8wiUCBmMOESU/nebBfoehEkbkCaG2riY/ceKXYmB0WOiuliO87ef3yiFu8iU Wmd2Ido+JLh+LbeW11NCMlSaXCiko+k99og+41mPXuhS2AmeeomQBrKeH/qcgBmINQh9nzaWVypO WiqF9Daj+dalkkmjb+ii/Cl2IemcN4qfOWpDvkGivOmIuDic4rilHUk7Xxpdsjml6ekatsmeAtqm 1LGR/ss4ok8JpjVmqEoJo3bKjIkajiGIgF3ap/iWprNIoFUqliq6qVNYlRlomL1YVV7zgc3npCAK qMGxkHy6l5l6HMR5gFk5pnUog2zqpQNKq/XWf3l6qJQJkda1m2ualGFqn4J6dnKqhc21mP2prPZB OX06iHuKngFanR4alCNnpJ50P9AZiyDJmK3IqydqopG5qN16pRtZooVJXYhZfuXqlN/qro15nNvK ILdCpqpYiCPZiQ9iq4eoPk/6r8Ohqg25OPkFnj9UrN64q4EaifmJhfrHomfalA/7qOa6sOPaqCPK pf+JqwjrIKqCldexnCL5rNjYrssYrRtKY7Xxp0wJ/jTVw4+cOq+EuoWOOqnAqZUke6mXibM4iqj7 6W+Qiq+9Cp8p+psde3bkkbRKWxeAuqq12iRSOrDayTPfKZWt+qq0Wp/Mx6tbyrEJK7Qeaa/vGoMN CKr/aYA1Gq//Rpvz2rYHJ60py6x3Uq1GOTNAel316rY+i7OYClYAerFdhZGMypJpu7aB255Am64K O4qeKq5he7WQ+1Rg6rQceiNRG4EFS7UABzlfUQAE4LkFALqi+7mjG7qke7qmm7qlu7qoy7qq27qw +7qy67q0S7q067qf27qgG7u7O7u8u7qie7u2y7u6+7vEm7q5q7q1q7zJ27vG67vMG7q9O73HK7vN /lu801u6qHu90ju8s7u84Fu94gu94Uu+41u+6Hu+6mu+7Ju+7bu+7hu/8Bu71eu89vu5ALsldKuX 0AKz/QuVmqUADLAAAqwABMwABozAC6DADJzADrzAD9zAEDzBElzBEXzBFIzBFpzBHNzABXzADvzB H4zAJBzCJVzCIIzCBbzBCCzCCuzCF7zCBizDHawAMAzBN2zBKNzCL+zBPizDJxzDQYzDP9zARjzD O2zCSEzDRczEDnzETZzCSgzCNVzFLKzBWGzFWXzFWtzFXPzFWxzGXizGYDzGZlzGaEzGanzFQNzG CFwAlCtEl2uK43NFoZmdHBfEemzDPMzHflzA/oDcx4H8x4JcyIR8yIOcyIasyIe8x47sxpD8yJLs x5NcyZE8yJacyZesyZy8yZ7cyaD8yaLcyYxcyot8yoiMyqacyqy8yq6syoYcyrI8yrQ8y7Zcy7h8 y29sqZVrJPsricgYMzBLoM8yyiR8zAKMzAygzMyczM68zM/czNA8zdJczdF8zdOcy9qsy9vczdz8 zd4czuA8zrVszdSMzeaczui8zufczurszuxszuI8z+Rcz/R8z5NcAC9KpUEzx3R4kHeclzQGAKQM y61s0K980Aq9yvbc0Pj80A4d0RA90eCc0BaN0Bi90Bl90RpN0R4t0SD90W0Mx+dYt3MbavmL/qfY KlEyGsCZ/M4wHc8yDc80/c4iHdI4fdM6ndM8bcwzHdM1/dNCHdREDdTSvNNI3dNKjcskTcxTmmr+ /JyL2rcELcocfdUbndUdvdRcndRe3dVgPc9Y3dFjXdZaPdZhndZfvdZwXLbdl2W/jKZeSYuP6dKb bNRDjddFnddrrdZ+3deA/dcnrNeEzdd7fdiFnc2CHdiMLdH6zMsmPSBR/YmIOIVtVtWTbNZkfdac 3ciN/dmLHdqg/dCaXdqdbdqbTcmjLdqsrc1NbdI2Oi5x7dbuWqh1LcV6nNi6bdh6vdq+3drA/dt3 zdvEjdjFvds0LdzBvdyX3NQ0u4OFKbCR/o2B44rZVn3a2J3aCc3c3K3c3v3XqB3e2S3erNzd5v3d CtDWhwndFokts82qUx1jdl3JyF3fx/3M6H3e+p3fN23fxv3f/p3Y/L3fwf3YFam1PSvdTyq3G2nd mT3eEK7dsTzgFE7gFX7P5J3hEU7eFt7hn/3awZqvjFtu7123Y7q28x3JAX7fAI7NF+7hMP7in7zi LV7jNC7PMZ7jXu3clB3iumork92QlF2NC2PJGi7hSM7IOr7kMs7kR/7kG57RTD7lIq3efVumyplK JX6KjFt/jYLbQHzjLC7gVF7mTf7iYm7jY77mZt7mD23gK/RcIT5BCu6XaHrlRX7JUJ7k/tnt5n5+ 5sG954Ie5eUN6Iau1iBupl4OmluOuD6Igl6X4oPN5mkO1Id+6X9u3pVO6Zx+2Jj+6Uv92mPZ4/1X 51Ld5TULKI886HyO5JkO6rAu2qw+64Qe67ae01Z+qKgu340eqAs+SGCu5sKe5rde7K8O1ps+7J1u 6cdu7OEM54/p1KNIOUFudR8qfw5O662O1s7e7N4+0doe7hH+7eQuyokOruyNiywblHCLGWWZ28vO 4pw56e3s2/Pe7fiu6fGu7PxO5vn+77IM7XM64odq6t3ntI3hmSrZwu+u2uHOmW2MyfZelgBf8eV+ 8RZf8efOdW5db+tu4iBKGQoPj8lM/vGKfc0mX9/3Du+tvfIZj/Ew//Iyn+OJFavXrjoGL+Ttvpkj 744ErAAND8kF3PC23PNGf/RIn/RKv/REP/Pb3PQxH/VOL/UnLPBUme6MjtKnyvFwaxhM3/P4bfIy vPRjX5bB/t0QP8tfv/aeeeZiT/VT//Jv7/SJvq7T/io5b+07vxhHf8BzT8JM381pf+EuT+Bsf/gL n8tQH/dw3+yLf/E1L07snaud8/FcHrc4vwAKP/SJv8cr/PeMH/oVjfikX/qmf/qor/SN/9WgX+5W D9nBednVjptxDCkUbfain/t+3fq6L9Kp//vAH/ymT/V17+Naq+693oApPTQAEAC9/r/6mY770P/8 xc773w7t6638mpb3tL/zkZEy1D/94h/+5B/cj//yG4/l+kn5li9VQrrSRRqZfVP+9D/+9l//+I/r 7C7iig4osw8QEwRGADAhgsCCExIeLEjQIMKBDwVKDFDRYgAFDDJu1NiR40ePIUGOFFmS5EmTKVGu VNmS5UuXMWHOlFmT5k2bOXHu1NmT50+fQYEOFVqU6FGjSZEiLSDx4MODT6FKjFiV6lMAFLRu5Uqh 4cSoYK8+XKjQ4FezaRmOfRr1IkalcZfKpTvXbl28d/Xm5bvXb1/AfwUHJjz4ZIG2VKdKDZu48WKF XSWXZcwWLFqsERuipRyRsUXD/oVFhyY92nRp1KdVp2a92nVr2B2bOlb82LPVygOzSuaKdurt2wUB DCcrMWFZ37QZYgywoHls6K+lR6c+3Xp17Ne1Z+fuUgHi2r9v5378eDdvrZ2Biyf4dbPms8bHIxxe v75F+/n17+ff3/9/AAMUcEACCzTwQAQTVHBBBht08EEII5RwQgortPBCDDOsr6n1aBPLttyMQ2+r 5CwLTj6zMlMrxQ+rImgBBd5yDsbtauzuRhtzxHFHHXvk8Ue6CHAKMiJxmy+s89BTj72rkIuvOIdU DMtFhBh46yIagdTSRy639LJLML8UM0ydOEysQ+BAFEu3EdMzkcm1VOQMIihb/kwMgIyutChLMsf0 s09A/xQ0UEIHZerMKYmckjzIkuRtyUQjddIhKOeEUzeNYtTzuUI7NdRTUD8VNVRSuZuNykgtU7Mq Ryd7M1Ws6jNO1liJU25NABboiLmLRvW1VGB/FTZYYod96dREi0w1zala7QrSV6kcktnwzPsIRtD4 NLZYbrf1tltwv61OyDeVNbfJNr2KtrJFpV3WQ9wAMKkiccO1t15879U3X6LA+822cxUlK11o2V3T Q0Td/ZcsbT3ilN99I4Z4YokrFva7Ic+8FOB2I2uzRIPny1jhaafFSqUALFaZYpZXdrnl7jRC9uBo RR7S2d7QDHlhkRMWmGGU/h5+eWiYiTa6aKSVMlNhWDd2CmcS120R1al9ZvSsluBKeuuju+b6a69D 8tdnm3fODWo3L9V55KsT7jjXlVIGe+6w6ba77nAxtrpac8vzeESQp1b7SJIZlTduvO9WPHHGF/9S 5p8BVnVNET9e+3LxxjK5Z7izbtjxxkMHfXTRR1ta2pGdNo9gqS/3u2OyT2ZJ69JJt7123G8/tOeF bzWSTcsHbxr1kPdG8nOR5M59ed2Zd775kfT+PcSmX/9bydadhqxt4g93SXnonxc/fPIZh9z67QWn HiHWhW/dYNip7nx25Mu3f3z87+f3dM3htzN9tKnLbNmDF/em5b3Z6S9//gtUYAPtNbb0aU9zlQMc 5oYnMPTtbX7fAx8DPehAEH4wUKeaoO/S57cABs6C5Vrf5rA2kz2FUIYinGENtUOuWyWLY5RjTApX OMDiRdBnGwwalmx4RBomEYmkgWAJ+WY9JLEOiOoz0bJ4dieZ6Kl+SuTiErv4xX5tTk1WbKEP3TdF qu3QZERMyVu8+EYwxhGONMEh8UoGxUZJkYpoLNLkhmgT0MhRkHMcZCFH0sQCoul3FMTeGff4PyYp jI1FJGQlDXnJJZLQbb07YR4tx8cLDg+PT9OJ0Cx5Skym8n4Q1NgEnRiv9oWSgK5sIVa2SBJTqlKX qORl7TSZOr91cnWf/nzkD/+Xw5v1hHa9ZOYunXm3OnKyijzEVSxnmR+yyCqbtqJmWybpuWaG85nj /FoTI/kuYV7vUbOMSmectKKvqBGBgCRnPcV5T5X90n9CpCbwKuhI+PRQPlGik/8Ycst52VOh+GSo vaK5Q6n0r5M+BGWdULQWeAaMIEHJZUM9ulCQ+smcfePd78woyx7ax6LvkdIxFYJQXH5UpiGl6Zj0 OREMVg2AejTmO30aUCo9KAAaImpRjXpUpCZVqUtlalOd+lSoRrU/iFSbGql3UnbqJj6ZIeiKXJgr jsK0pmOdaVlVU0eNWZGfw6xgRc9W0LRMyoUMAcoyyXpXs+Z1NSRM/l0Ep1fN4KH0MgGdU1fVg6h5 3qSjeGWsXh3LF6pqlG3zoWgxm1Wnn1r0q2LFZWM9+1jQ5uWXT5Qmz85izYqqdJvxVOneyFIUu4ZW tp+lLU4eup5popMhPAUowgpHLW9ytiSLnW1xa3vcQxqvrxENJlZQa9lWunaTBzRKB417XeRmNyOj 5V4w/1pZY/p2rkZq1zdhqF30Yhe7t/0ZeSd72sBS5QEGeAoBHpDb3y6XlEMhbnr9q16aRpZRiUwr +4jpGQO4xwCKjBzTNGfemlj3vxMGsEe5yzsT3gqrUgEABAYCgcCJkmSES6wyK0xhFH+UvQVeW8fg 29YPCWABT1kA/rQUqVweQvi8J+ZxihUqYMIxmDYbnkgC8pMAZO5TuUNWioR7/GQfV1J64y0bP9Xp KoMlQAAAEACSw1Nl1272KP2FcpmjzEXIUbl63dTMc01bWqumMahxcfKZzXxnJQL5vZ10EXjHS2CX unCNwg0ang1t5y9euGSStQ2Rn5KAARRkAPfdMxkdfKYS84TMiD50p5kHHumS1tJ+joqRiQOABetQ dVS+GaFRxmlYe1qBM/vzl/lMZIQ0wCwP6AxzI3lFzsmlzrKOdbEd9x0DDljIAzswVHLlkBpPzqXJ xpWrT7JpYmfb2EY7H7BzyucXNzJRB8gPAlqMU4NeWiF0Gfa2/rX9bqLxL8wDpCxvw4KALQvA3BmG M83uqOOcxNbdA4d30lhZ6zWfzc1hJmk6xbjuuWCb4BMv+L1Gy2o1ehLG+VW1WmspLYArluIjr3jL bhu/VSs8vhGAwAAG0oAt79tmfM7gnO3S7pKTXOe/iizC2RzFZpPbILyuj8ypxuZXItba4Nx503Nu rAujnHBXRS0AHHCQBLt8AQLAsH5pziq8CPzpTif7n1bsb1VP/crPokpCHDAcSqvw4S7mXsgDvvSx 573sNgJy/NpVRtQK4AERiLSQIvD2c9s6yX3OC873rnfI90jRV5u7xrEnFQTYJ+4H4Ldv6e5vu4s8 8qN/PJnO/p7T6Ob4uZkfgK4PMmm+JeQstKIPcb6e6erivfSk5z1h9Ex5zzeLp+LFLTcn9c5ahj7g u2d+702lZk4S37nxncAAEuCAozdGOFqV00BvzRexN1/8zhfN6Vm8PhTq8SAQWIAB9O16arI0o5TC KPpfuheJk1//46/L77tu6bXLGZNpAHwzgAXwsN84Du6jk8I6uhdqPP7bPwkUjcmzIz8SvgNLGAeA NMdwj+KoFPhYI6IaKqkqQRM8QRRMQRVcQRZsQRekkIPzuV/rIWuqNbhaCEtpwPNTPsXSvQn8wQhs iWiCPjlLP2JKDAgQEpgbAARsJ/24wSepP2CCOPDzwSAE/kIs9IiZQTkTeiVci4AEm4AtAwACsBoP 7D6uopng+ovwy0I3vMKY8BeJErS/s7x1Ohv2AwAEALGv0ioQ/EDJkZ2+cLw3LEQ45IiTg75EYpXn WgsCsDpek6RZ4SaFoL1p4sFSyr9D3MRC7LlQW7zdarb6Gg6uAwDOG7FPnEJB9IsY4kRXNESSiDpW U7zLaMQJeIABEABdIwAPw7F5U8X7Az8jekVihEWZkT4Hiz5m2ziqgDRJozRfTEZbe0C90CJjvEZX vKkGkyaV+6fHMDXhSDVBI8LgC0b865ViTMdCRLb3cS85I7Wz0LWCiERgC7WHa5bACCRs3MdDlMXu giQa/ly5iXi2goi2fyRH9cFEnGAOK+RHhyw2BmCvIOu84LA3gyA3+zC39loVHMNH0iBEdQzJyKMq X0Odc5k+b7wKfOMyo1M24FI33WjILBJJmpTAKfOdMUI3gYFHl8xJaiMt3MM/mXxIooyy0zGgPesf XDMtFptIaTSOoZzJopxKsiPJysu+BLRIZUOmfloyzTgNkKRKsUQ0w7PAAqvDsVhK/jiAXnQvnDTL mEwNTRxLuqSwoywpwZoSnuyPBdOv85Mz41iNsKxJwiQ2PbvKGQzAqBGPBJA5BGgAlounKttGw4lK mpjLwszMO6tAFyMpvdRKGRuIBXC5FfG1VZHBjWqN/jbUTNY8NPNTQ50cNTebgASzjwUbzX2SKC6s NtgYzLr8zezyvzo0TSLhyQlYSX0zCAHAvoRjSnULSsLATOCczsaqwKSjxVBMyV+ULMCMHYWkM+oM TxR7za9Dy3C7wzWBOWzqOIejNoaYDt9sTfnELv97pcpztOp7wj5qofcaIstUpv8UTwHFJOsExUVD ycvDlSS8rwXwMvyqud+CztBYzQGtUJoiz6bsScVMG/OYgATgPAjgunJ0ord8mgAtpflMUTyrTwNF GHikzQYgOi7DylG6I5DTDulUUR0tqwK1QBLdUHWBjAdQQi6DTKugRaeMn++8CwrdUSfVKwwtQr8i /giL9Da09C7gYzzsiE8L7dJUYlEf9R/8RDvNsETVYghtKtElDbsT9VI3ZaAerTx5qtIhnYAlhABM I6wQRL7vqpEmfVNALaQopUOXws8wHMOyXCmI4Cod5Jw29QkufVJJbSYwlVPVE0WEyMM9LIu0jMK4 CsHPo8LsyNFALdUPitNfNELtLI5HdIBIREsFZFTve8dH1TRTvdVUGtSO7MYErYpHnFFTJA/ayywp 1EsWJMEXTFZlXVZmbVZnfVZovRBas8dNUlVxmwpc1MUJ4EU7kr8UaUDgklDXINVJLdc5WhpqNUmq w1SOQxFiLU3Qq1WhiFRcrdflSVSEBEagW9WD/qjTrYO9O9FTWU1D3hHX3pRXe01Yl6nUaGREdj3U 4XioHNxTUK2iNR0MejVXjT0iVEXFnRJIhtBUguIw2msPbjJZzIgkg30NclVYlw0bXZVGXkVPVtlW SOy1G3tKFELYed1YnxUnhlU3trrWsPjVUjxFWiLCzOkhMGnZn31a++nYcVxXZnyKbN3Ftuw3G7Se iy2MjH1ZsB2amL1Ha10nInHG6oNGZuFIrIyXMPlaqI3b5glasgWsqjUIcFQIcSzJvzpQEuNZonDa sB1ciZHa2PnYVc21XcNZZazbB+sTuCVcyXWodrXBB9NKgpwAg9Spv5zCRgHc6pJb0UUiuq1W/jt0 FfHAyKJbtuZyS7f9EsEdXdmdG8NV10u924NAzpacUp2qKqCB3NkNXgUa2+kqW9TdTew8yclcxbcV Xuctn9JtW0aiWUVk3Tdr3a6VS9CdXO7tktq1UeNlO8pcW+5Mu/0KlMh9XvXNF+J1wJnFsoHsj5pp z8bNXtWI3e7N30KJ3skaWrN1Qv44N/5Eyvf8kz9dXwRume9NPVhqNlI0AAVgTsC8QAjVy+0VtgTO YLppX31dRqK1UwWoTQAYAARYAFGzzyDyyE7BXw1uYUHhX2QE0hJ5iAaINNszXzyKs8u44IjTXx+u mAV23X394AYI4fog4RnrukVKtwQMlZQ5/uAfjuIREq90BTwH5jIIxj4b7V9wUzb77U19dGExzhdt TNd02jD/KKklnra0BJUrkWI4DhZQA8j8WmI/S+MgMtA1tiVB2ZQ4/mNQUTSERKYvlFLpTbcdWlkc scYxbmRviUG2ddzphd8RkzaH+1E+9pRecQ4WBmRPDowyJlPwPV3x3U2IQuEufq1PyZY8gWJHfmUe MacSna7LZdfDbc6MM5svZtmRaMVP/uUaQSvn9Dn/PV4rbRJtmj3bU2bJbBpFXmFXBmZpFq2zxMsj pdpePeZ20tM/xKhX2WUeqQgehmVy5glt3OLiJWUBRKfwmFg0XNS1eeZVjuZyrmcmquZZ/qaWSWY7 JdPnODm+ilUWcG5aerFng66Ocw5VfMbAxK1H4IhVBvQ+4ixgi8GW9J1mjFYJWdbNe6xl3PW3NQLE b61YY41WoUJWk05plV5plm5pl1bWhB5mA11Kn6zZrYpogr2igRYTix7njPZhWvPdzsRm6hWxPruo kRbpq5HncBHng37q0BBmetPQYi7lmulQZ3PXWd1Jugnjn4Zqo5BDz1Ti9+XnR9KYlAVopa4aps4X cf5quM6JaS0m+6vqdW5H/UTZSUzZZdlpYCnouA5sjXbJc+JO48xZzzXdQi2dtwZrwYaJLQSzUQ7f u54iM17oHPNpQPFlx+7smZBD9szj/n46T0rurcpdMxUeHYv2bNY+lsFRXjyi6as+bbg0x9xp7Mdu 7VBuztFG0KKWmsuGSYqGnopobeP+iLusZnfk2tkUrHw93LPQbFHh7Nz+5JECNPMs65xxK1EObr30 IMA+bscO5fKdqOYGbtomVL9uGdwW709OxBPG4VrEVO5+7qNr69AJ7+qG5Y0ORKSj7MV07sK272aR bnDxavd+5Zgm3+ye748Or/SOLvxWbU1JcDjub63l4uz8YGN6yUFGCAPHF/228BZecA1H0sMGKAJn sjcq7v3m3jm+5B9V5wDPKmtW2oOaoxF/cecN6hlvXe2Omvr23Q8X1UGibhJPWHZk/nCv42LZHvLg LnBU0u+LTnKa7LZFPHG+pVL6hi5pM2NM6SVxHkYeB1R0Vbst51wZ7nDTrl7bnnIZKfOnFes0Z/IC SnEBZ+dUnPAP2pQQt/LRm2uuBEC7rnEo//I6znFn2hR0lHMBBW1/1nKdXPNDR6NUNHJe0hSMyBKL JnNAT9HIDjIkXZgn9/Kp/i1FD6cmfeNPF0tIt7Sa9hA8t/HxrQ0+5yU+caNWp8mgRp855KRSj+dm SdNKpMTpWm9DyhJWd3ROXPLErLkQIW2zZvMbzqj5c7Bbr6lOR3Jmd75e584TX3MVXwtw9VZOLTBk Z6ht3/FdH0l6S6c03/DftmxP/n1XyUydbC+ude/kdk+vb89lOg7IhpYleGaRkW6pTUr3xlr3bie5 M6/rhit0N6lvKbT3X6dGsruSP294QsJXX7e/azawgb/qcr9peK2Vl055qLoSlW95l395mH/BMxfi sb4TrTxrKPxAuQrXjV/4VvZ0jkcvjwd3gJf2yjZ1gy8sS2HnfCe4jVj3ng968pl5Cq563y7tPOdT BdQsNcETmlz2fg+tgyv6xGwzgeyppynZ1qqqph89ZY/zsCeri0Nkqxf5bM7z7rajvo56Ttt3qVeo RATAsvfg/82qSKZlFJpUho/7cPLESx6lWX93MCcjhQdCjf97QpLFPUblYE+5/nZNt7ZXx1zXdczv Ikh+fIeLfCrycMVuEr53e464fMZPonPG5N4mfGPmbj233cQH29Fv9NmPWlz2fEm5+RW6cXh5sNe/ wt9n99JfHEEGedvvfN4+ZtTDdBd+e6BPqOe3mCUfzppXWeN3H8Tu3B5afof0++Rp7+7HF/K2ZIin /gtEfocOfZfdd7hvf33ZaN6t0asHCAoCBQKYEGECwoMHExpE2HBhQ4YQFTKMOLHiQgALFDDg6LEj yI8iQ5IcabIkypMqU7Jc6bIlzJcyY9KcabMmzps6c5ZcEOAn0KBChe4sytMo0qNKkzJd6rQp1KdS o1KdWsDiw4pZL2qlSBHA/sCwYQtmleiQolm0ZbFiRbvwIICpcqvSnWu3Lt67epES3djRrwLADIYS Lmw4aN7Eexcrbsz4sePIT6+ybXt2K+auYMWKLXjx82Wua71i7IpRo+TUkFerbs16NVCdgGd7pP23 Nu6Oh3fzdu379e/gwIcrJlCWdOaIykl/5dzZLPTRydW6LV19Qlzh2olz3+79boDvIm0Hzl3+NnoF vNcbFt/9vfv48EEW4CoaM/PLFTc7J7j8P2imBcjWW/rBJZh8Cc6nIIMLOsgUeRGaRxt7FQqF4IMZ NrghZFchl59+AOKHXX8DkUWdiGmlmFmBLGanIYwcyhgjjTPiJWF6OJZn/iGPNtb4o3eU2ReaZShq VqJ/A6Io2pJEEqgfakBK6SOVU1pZJV06avkRjzxiiCVLAVz5nnEtFhggaPnBhSQFJ67YZJPRmani i2DaOeadeeK5Z1Fb5jghl12y5x1QX/K5l5ClTSdniBmx6ZmT0jH55nGKGhSlnpkeqimnm3oKlZ/n iUqeoBUaKtKFnTZVn6IQjThifvz156aSIsYpaasN1fkpr6r2+quvwRIX6palngrsUR7m6up9kyYk q3OQMlrrtJHOGRGmyAq7rbbdcvstcBIS5a1VLKr4qpq6PlpttbfCmeuu4MpL7rz10nuvUbHh65Rx //nbYqWmkYiktLgy/squwWZmay/D+zb8sMPehhdxUayae52R6ULLGa3W2koptS3GSzHJEJtcMson B6vsvwaqCPBEGz9XK7UG4zrnwinrrPLOPfP8c42JXlxZy6TJPBbC79YKANPSDnmpz1EDPbXUVVPd mMUwC1zdddiuS7PH1brpdMA5X2012mernTbbHrF8ZpHQDdkcwUl/rKS0brY88tp9t/2334F7q2zX Wr9cWQRHmwhy2LiOXalbZgM+ueCVU345lkLH/WqKdJfYsd3IjZa33FBifrrlqaO+eoJZB4w45yJ/ 7XHNTT5uX9O567477737/jvwwQs/PPHFG3888skrvzzzzTv/PPTR/ks/PfXVW3899tlrH/zbLnPd qLmK+2ez0taSvuilAvu7vrPsg69++/G/7/5+8M8vv/35078//vwjpLf/9Ne/Ad6vgAJ8HwAJeMAF BrCBCvxPAg3oQAk+sIIUhBIDLZjBC26wg3r7kPfQZxHxtYlxB3McQwoGQrIFDGNPmhMMrSNDy9AQ bjUs3XFY6MIY3rCFL5yhDYOIwx0CUYc/7CERkXhEIfqQh0yM3BKHGMUmAlGKTrRiFctixCtSUYlc TOITpwjGLWYRjFj0YhnFqMa3QMpworubFtdFPjjK6XxxSpyliAYwPWqFj8rxI7P6uMdBCrKQ2Mkj If+YyEAq0pCM/nykQwAZyUVO8n+IdGQlG6lJSLqsk5fcZCY5WT9JepKUnxSlKVNJyct8MJSuLOUq T/lKWcISkxhUpS1pqUtcgrKWmgQdCEsnPxKq0ISMu13Y2njGMH5xjWlsJjRTCLlnUhON1mRmNYWo zC5i85rL/CY3v7lNM4aznOQ8pzNrOM50drOd4ERnNHU1TW+ak53vtGelilm0dmWGmKEjkruw07RF fUWY2bxnPN1ZTycCE5/wPOhCIQrFeSr0ofS0aEVHaNCLOrSjCT1jQz8aUY6KFKMhlahHUVrSJXYM bkI0EgRn908BOYmQRtLnLmPJS1TqtKeGxOlOZxlUX/I0l34E/qpPe5lToya1qL9c31CXqtSoUhUu UG2qULFK1Kwy9adX7epUtSpVpzq1mIYrZLocVbc5polSPUSXuUaa0ZXStYouTSlJVarXG961rnn9 61ztejjAInSvgX0riA6r2MISlqJxxShjFyvXjWZsaAVcU93AdsJ38fV9aIosaCcrWhduLbSQHS1e z+pXyZ62tU8qLWpXa1p7Oou1qZ3tSmHrWtnGFqXn+uz3qONPtgLUhJBMl3Q+di6CKpe5bV2u6KKb MFjR9LnOLS50b4bd62a3r6+TLme5K17wNpe8wIVrd8ur3fRa17zbJe/htBZe97L3vesd73SR2977 0he/8+Vv/n47Rz/5qiuztGtcQF83YMv6V73/fbCD1es+GzZ4vxC2cIT3O2F+1rfDFbbvhT15Xg/3 t8QADnF6aXriDIOYxSQG8IZXjOEZt5jGL3ZrWmfotbUGtK1ge2l8M7m5D78YxUSGq3SPbGIjL5nF 3pWhjZUs4xpT+clDbnKUsUzlIidXy1zO8pTra+W7fnnLUmYyg99Y28P5U7PJJe5GlavmMJ/ZxVK2 FIjKrOc6gxnPyeGzmb18Z9jNGc2GtrOgk/znRNOZ0Wj2c6ER3ehJP/rK0wzmkXhszDz3OITwHRCg 9+xoOH5PxaKmtKRDDMJJBfLQYHZ1lee5olDTetQ+bm6t/lH9alLTcNa2DrSuY60W5i4Ybm0+8GY3 vRYJBxfYsD71f0ub2GBDO9US3ueqrb3rbQNb2kPjdrXBjV8P5/rZg57bt52tbXX32dddRvJ+5Njp wcI5zZb9MbvzHW7qgo/A+/73h5GrYnwD/Ndi5pyAOVzudZfZyAsXt5YFnnBqPzzf0y6f/zw3K2Wz GtkBbl+vzW3wc/f7YJ2GOMVNbD8Ks5zhFb9xjCtL8JfTXNw1T/mbO/7umY+85zmvKYKDzJXhzjt2 HA8RdYnIc5yLPOmyzvbSmy51p7e82Qr3+dRzXHVLozzrFnf5zb2e4/XCN+wu13oIg7xhjUfr6KYu +lcG/rpytDKu62fPSu72I/dLDfSsxDY7xPWW92f1XX1/x/rd4840vS+e8Iv3e9kRb/fEFR4ucrd8 4wUNeHWTBVt7p3zmBRr6Vtdd3wvvfEY+P3jMR3DMZyH60eG+ItIJnMKHZ/rdH5c+eeKR9/S+vdfD /fjdW7X3xf995HGPct0b/5DNJ1uko554ROv+kPJ0viVLv9zNe3j4xHe+7u247OQH/8jef/73ySL+ p1H32DN1u6SYX3Iyp5j73KU99q0vflyTf/qBt/7x6R+2QFojnZzpGRz+nc/+WRfw+V++JeAAol8M RZn9kVdBCN4A5p9nINP29d/kcR4AWlJGiKAIcqC9/sWbprkZp8Ef/oXcPrVYwVGbVaUfDZbaohHX B36Z+mVg8SHT1pGe9OUgcwHT7figwjWgEKoc84UfD9IdBUqesylTEUqTBh6hBx4gpSlTgWwgFa4f 0GmMTNWbCoKM/HHdkCEhFj7aCAbgDo7gpW0XGsbgf3Gh7wmgG1rdDRqgHJbXBYaeAjYh/UXfgSWh drFhHdLh8dme5kFh99WPG9KeCYZXHNpfBO0eJEpTzbAP7I1h/yEM/tkUjhWg9m0eGzUhIuafKDLg Fe5hW0GK+J0iUt3XJDIiZmTeiUxhHaYiHK7izaVQ4YVgG2YfHh5ZBWLi9fVgFwLiIFaSHvZiImrU /gzOoBcOVqyEoey935LInyKS3fjhYBpe2x1WoTjmmXjNovKx0usZox0KYx7ynzeyIgatoTh64bD1 lzmK3TFi3yXmIrqZHik+iyNm3z4G4DvWHy0mViXeYgRG4oKh4OdgYwN6YgR6GjOGIhAuIzx6hdPg IkGCmj3yIiPyDkDyHkNGRzmC5DlGIwByJCp6pCyiZNMF5EomYzhenC6S20HG40gi4/VNY0He493J ZCmGYzCG4K3dlfuJocf1mDa+YIcJ4tXh3CgV1CMqIx5+ZEEiHjSS4Doa5RviZFZKZfrI4x/W5Fee ZFjCmtEY40C2ZNjUI51V3FpOZFfCIvxB5TkK/l0I5iMerSFD6lzMyFvs3aVytCC8XaTJ3WReJh0L sSRO+RtaNqPPmSImliShmRlQcltBHaNjNmRcwqSkaQYPMqFZchZeYmVMLocUViZNsiMn7mJahqZq ahFWkKZrFhe6JeU1KiVo5J2i9eNTdqNkThrjVZ5v/k/lwVtUwuVwqqU6gl7eJKdNLqdilh/u/KLo Refw6dconqYDgshxIud2hieG6Rgx/lqsnMYvHid0muE/IWZK1qJE7I7jtRF5/tx1bOJSRuR0XebY eSdwZqawvdZrqdYXdqdwImiluVGuBBBowic+ytxlahK2YWQ7BqF96RaDdVZwMqedkVwaHZF5/nbi S8amhjmlC4LSRd7RwDzka76dsomoAnnocwEoFmroteSoCAkoDAIa1DWod9koWDYnOAIdkEIZwj1o RWKoXnbNV10RhI3oZ04Zd+qoKJ4hiUqikjbpFH0l/TGbfr4nYZIW2lVpdaLollKdGhUobp7pE5po hrbMkcKOqfGoQVIp+gSTlcbYnWopnC5QqVUW0nmZjaoijO0PmzqWlMqeoRLpjMYZgwrWYOlmjPKm kTLSBC2qnCUokzroK1kpTAlpZCoor2WbEjldgw0pqcoPpoGqXqbqqGIo2jmWqdJoj26jw7lXmc4p XKbbrY6igM7qcXkprbpPmHrji77bG+7q/jAmH6daKLOeqquuoK1SJ4TK5po1U8xB64cq6QoiaaIC Jre+6XAyEIW+YKFiV7p24M/NXaKiF5paKruWq6cmEp3qHL9R6hhCZI3iUKbGq2k+a1QCarh+UqyO q5sOqMQR2AQ6ZZQe7MCWqob+kIRSp6riW7QC2STCKq52q5ommY5mq6/2qYWiYbQWK5lRa8kdqwEm K4tyacbOq0Uu6TKe7GMti7XSbM7+aqhelo6R1mEi7MXWrAihm6vSEWgObbIdkMa+5rUGbLWiJdP6 UNy0qmclrJj+agc93b3G2rNYY6Uy6lv+K6umXYdiLdkmXMjumZ2arJqOLA89Kakqbbt+/uzExm2z xCbdxmzPAmczcqxJEurbyqm9Gm3Q8mzJ6qrdSqjhHirbcQy/yis38i2/jeztCeziXu6emlvbOmvG Gd60DS5Q7m3l4o+e4uzC6i3Epi19ZSnmtu7r9ufa3eyy0mmx6aylXuvWCiKDlk9gGhhERi7CpG11 je3TYmndlu1v4ezOXijCHu+uIimmFi5sEinpFu9/dtK1zN3xkmyjZm7fRgp/ruvO4S7Ilu7VIhZF Zm/Uiu2Kgq87gmt20YlgOu2YIhvlCm77Aiz8atbadqqooibr+ufyut7+lufBfuu2kqlB+an1Su0E qWzg5q75Tm7CFk6bhu5RfhcHHfB+/vbqAPcrBr/v0IHtvkoui2rQ3PYad83ZBiXY9tppAJdozEJq 1zJs9a4wVmIv+hJuFq3uw8KuzZZnk1nhimmqyPYsjvps/8qsy9Zu9BJbP/5mLdbvB6PwzObvqjqx 8cJsmMWtDMfum05t45phrs4RAggA0xwABMBJ49WuadiiFi6vQBWmSAJxhKUYAaks+wWxO6IY73Lw yQapshKvB8+UBUVbrbZpprnoFcPoE4NwIuvwBEPtC+dxwyIuuW6x3SJfXOEnZpIXAgDAA0xAAwDA AHjM+REwWgxf6PmZrhAh6OAxAp/vrDpZ1v5kEbOwyHbQ9DKyFn+p6xruLSvuV4Hy/uM+BwVHMkZq sfeqqxhnMPoqsrdpcijrbdniq8N27uhA37m8stEN0XZ6qfd5Hic/Mz8ZqNoVLTrr8hdDsRdPpwKr c6YeMjeScZw+GSE38sY9sfDC2STX8hxF8yUf3ObM8BmX69jxG/vyaUI3xACgcinHjPptoEYIgAEc xAMQANMYAAQgRAKosUdTngEYhytftAEwxAEwTQIwhAEMwCnLckJE9EFAACojZwMIAAFAxEoDQAJo NEcDgEebcdChKi7b8zBf8NgiqgaNcNA6M0If6EIrrlNTKBim4BWLbfDWMOBaMvQObrQRaICmaVRj 8PxycCWPb4mactMYwAPEHd8h/icCLAAAIMAERPQEPAAA7HQCaIRepzTTOEBc891c1zVCjPICnHJL TwBij7I+DV9fL0AE0PVPC1Rh23UEIPYpK8BdF4Re98tXq13HqZy7PbADuxghp/Y0J+/uGhBSy+ns nrXf2rBD9vMj32/W7rG13WnsTm06U9GPWjPpJjGvSa/4CrSNKcRGN00DEB5yxnXiCMAEqDEBNLdB qPF8uqJ2X4p0RwB2J04qe7dF08mJ/PUEGAAACDblcTdCfDcqi3d1J6njVu38SfNVqu5pE7G7TjIP /2gwI68eTnUhPnUDVzFWiykzIzJYo9rZkrBRJ5gP589rP/QGF6nVNpsf67dB/jxARHd3Ha93Hddx TjONADR3Ocuxc4c4far4Y0uLGtu0hzfe49HniANAidcpVYuY0SmxIAu3O1NzOHP1PBsp8d4u4sY2 O4NuycGPvu7nP19jNn8jb0uyz2LszTZ0954nKA94L6P1EcMYRaf4jG+ghzfAKEs3dj/ESccye4u3 Wbh3S4X4Qaw0eh9A6rH3dIOOmds4kJ3odB51+VqsWnsw0Ibu5452njaxsBI0fR/couc4Zj3kMt+2 +77qwjW4F/O22nYw2i5ikCMz3NJbhrdpRDtABJwyZnf2AyiAjNc1qk8AR0OATQ9ABET2Z8u5HCPA qzO2X990ZqNGOd+5QsQ0/gA0t+XpumH/+gLodSrH+qyrb4VXaFjf2ugO+pkyr7TveJJ/sgqbrlJj KxP7+euZsJNj8Ysi+h5OOT47ug9Hb1lfsycPuRMSsKCHKgT0tACkuikLwAA4wJg7gE4bRAT0NAF8 dK13dBuvueUBfJkYhGMPtUEYQImPHpt7HgB8NN+dckovxMN/9L0zTcFjUu1ULqDzeLUntYM3rNUW b39/nKKjqpCq2oJzOd5ZMYJTOmFqOyEmt6WTdr8acqe/szZvMDnOtmnTbn8erdKjq7/OCUc3/IdL KxpR+wLns30H/dEbKmxJ+GpT8fx2OwfxcvmKO/damsA0ud08+WA6IJfp/nHZs/vLUq7zNi+G07du p+yXey7eRvjSEyhaN21EPIAaW7flCZnfM5FsM3Tpyfvc5z0FK/4+o7vEUvt/13AgK2wP6+JVS3ql J7i8WqfjCyofW/3XtzYSP++gEjnRy25o42kmU23fm1EY2RXTDABns9Ecry0drTNxL+2CTzglf1Y1 E3e0S34fhz3Yd2NaB7R8Mzm5p72543wxtiwB0tjoq3zmNr7Mt1w4O3S85zE7g+LTxP4ZUROm/uzA Saq7ZTrcV3kOSx/JGvfq43DL+67dv7y7o+zV1159Ox3LAsSECBMIDhxYUGDCgwoJMkS40GDDiA8l JqS4kCFEhxkrTuR4/rGjxY0aLXqMqNFkRZAIWR4kKfJlTIohUdJU6fBkSZs5c66sibHnx5EcSXok 2hKpTqVCeTZUWvPjz5lPQ4J0eZQlzKortVodmtJoULBapU7tKVPmzLFib7LNevVtW7lx6XalCndo XalN1c4FQAFwYMEUAJDdmtKs4cRQv9p0zLRxWchrcXJl25TyWa+Yj04MOnmn3a6I7V5eLBI0471c RyeF+9owWtc6YTfGelW1StmcccfGWto3a9OWg9vm27k1ad6+OSNf/tx5VKe9NyPXm5fz38GDC9uO rNj72NOngX4nTvk8cLyp50Kmizct8PeohzOnfR86cfaPTSvXjX82/qoArE66ympzaz72PHNPvtzi Wo68x0BLj8KlEJTMOvXka+26DjeMj7reQJSrudva0m67wArLzcHwwBPPRQz74888BZOb7rvjoINt x+gWDCtHEuv6MEgagUTPPs3gC/BAHP1bkj4cl7JOMxr7qq65zPIqDsnP6vvSPC1nFLLEHn/0EU0z DcwqTQZbFDEhFFMkDIA67bwTzzz13JPPPv38E9BABR2U0EINPRTRRBVdlNFGHX0U0kglnZTSSi29 FNNMNWV0zk49/RTUUEUdldRSTT0V1VRVXZXVVl19FdZYZZ2V1lptvRXXXHXdlddeff0V2GCFHZbY Yo09FtlklV2WL9lmnX0W2milnZbaaq29Fttstd2W2269/RbccMUdl9xyzT0X3XTVXZfddt1lNSAA ADs= ------_=_NextPart_000_01C35CAA.EB6EF8E0-- From gruber@research.att.com Thu Aug 07 15:05:16 2003 Received: from h-135-207-24-32.research.att.com ([135.207.24.32] helo=mailman.research.att.com) by omniorb-support.com with esmtp (Exim 4.14) id 19klOG-0003mP-79 for omninotify-list@omniorb-support.com; Thu, 07 Aug 2003 15:05:16 +0100 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mailman.research.att.com (8.12.8/8.12.8) with ESMTP id h77E0Oeo013220; Thu, 7 Aug 2003 10:00:24 -0400 Received: from pcgruberhome (brow2116.research.att.com [135.207.58.116]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id h77E0ZZ09241; Thu, 7 Aug 2003 10:00:35 -0400 (EDT) From: "Robert E. Gruber" To: "'Cameron Rochester'" , Subject: RE: [omniNotify] omniNotify Performance Tuning Question / subscription bug Date: Thu, 7 Aug 2003 10:00:35 -0400 Message-ID: <000901c35cec$46426720$743acf87@research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Cc: Robert E Gruber X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2003 14:05:16 -0000 Cameron, let me make sure I understand your test setup. Is this true: You have a single client program that connects through a single proxy. Then it either adds 512 filters, where each filter subscribes to one event type, or it adds one filter with 512 constraints, where each constraint matches a single event type. The same client then supplies events of all 512 types. So you are not checking the scaling of omniNotify with number of clients, but rather with either the number of filters or the number of constraints per filter? Also, the bug you reported occurs if you run two such clients? Also, what config do you use? (The default channel.cfg?) -- Bob > One other thing - does omniNotify clean up invalid > suppliers/consumers/filters if a client application crashes? Once a proxy is marked as a problem (exception occurred when using to its connected client) the proxy no longer holds onto events queued for the client, but the proxy itself is not destroyed right away. To do a final cleanup of such 'dead' proxies and their related admins and filters, you need to use 'cleanup both' on the server using the do_command API. -- Bob -----Original Message----- From: omninotify-list-bounces@omniorb-support.com [mailto:omninotify-list-bounces@omniorb-support.com] On Behalf Of Cameron Rochester Sent: Thursday, August 07, 2003 2:13 AM To: 'Robert E. Gruber'; omninotify-list@omniorb-support.com Subject: RE: [omniNotify] omniNotify Performance Tuning Question Robert, I grabbed the latest omniNotify snapshot (and the latest omniORB snapshot) and checked the update.log, it contained the following entry: "Changed things so event lock is not held across push (required different approach for omniORB3 vs. omniORB4). Also remove all events from outgoing queue of a proxy that gets _pxstatus set to RDI_Exception." I assume this is the fix you have mentioned? After a few hours of building I was ready to go again. One other thing - does omniNotify clean up invalid suppliers/consumers/filters if a client application crashes? On to the testing.... environment: - Solaris 2.8 (Sunfire V480 - 2 x 1.1G with 4,096MB RAM. GCC 3.2.1) running omniNotify - Win2k (P4 2.4G with 512MB RAM. VS 6.0) running test client I performed the test again and found performance to be a little better. For the implementation of the client please refer to the "omniNotify subscription bug" email I also sent today, I use the same application for gathering performance data. Performance for unique subscriptions had improved but still exhibited very poor perfomance with > 32 unique subscribers. Performance for unique subscriptions was generally double the last build with > 16 unique subscribers. Shared subscriptions again show what approaches a flat performance rate. For a graph of this data please see http://ii.net/~rochest/graph.gif. The graph shows performance with up to 1024 subscribed types. Our system can easily require in excess of 1000 subscribed event types. Regards Cameron Rochester -----Original Message----- From: Robert E. Gruber [mailto:gruber@research.att.com] Sent: Wednesday, August 06, 2003 11:34 PM To: 'Cameron Rochester'; omninotify-list@omniorb-support.com Cc: Robert E. Gruber Subject: RE: [omniNotify] omniNotify Performance Tuning Question omniNotify is supposed to scale with clients much better than Cameron describes. The poor scaling he reports may be due to a bug that was recently fixed (a lock was held across push calls where it should not be). Perhaps Cameron would you be willing to get the latest omniORB and omniNotify from sourceforge and try benchmarking again? For those interesting in getting stuff from sourceforge, I will send another email describing how to do this. A new omniORB 4 release will happen soon, and this will be followed by the long-awaited (!) omniNotify 2.0 official release (which depends on the upcoming omniORB 4, at least for the Windows port). Next email: getting sources. -- Bob -----Original Message----- From: omninotify-list-bounces@omniorb-support.com [mailto:omninotify-list-bounces@omniorb-support.com] On Behalf Of Cameron Rochester Sent: Tuesday, August 05, 2003 8:27 PM To: omninotify-list@omniorb-support.com Subject: RE: [omniNotify] omniNotify Performance Tuning Question Patrick, How many consumers are connected to the notification service? What is the complexity of the filters that you have in place? I have found with testing that performance drops off considerably as consumers increase (it is much worse than a linear degradation). However, evaluating more complex filters and having less consumers is actually a lot faster. Our system used to have multiple connections to the notification service from the same client. I changed the approach and reduced the number of connections while increasing the filter complexity and found performance to be much better while reducing load on the service. Having said that, I never saw the kind of lag that you are experiencing. Running the service on a (relatively) slow dual processor solaris box (2 x 400MHz, 512Mb RAM) and sending/receiving events from a seperate windows client (P4 2.4G, 512Mb RAM) the notification service would still manage approx 10 events/sec with 1700 unique subscribers. The faster approach was to create a filter with a constraint expression seq with 1700 individual constraints (but only one connection) and then perform simple filtering on the client side to ensure the correct subscriber receives the correct event. With this approach the notification service sustains ~500 events/sec with 1700 subscribed types. With 1-2 subscribed types it would manage upwards of 600 events/sec. So, the service should be able to handle significantly more than 15-20 events minute, but we probably need a bit more information regarding the way in which you are consuming events. Cheers Cameron Rochester -----Original Message----- From: Patrick Vaughan [mailto:plvaugh@sandia.gov] Sent: Wednesday, August 06, 2003 6:55 AM To: omninotify-list@omniorb-support.com Cc: omniorb-list@omniorb-support.com Subject: [omniNotify] omniNotify Performance Tuning Question Greetings, I've been running an application which uses omniORB/omniORBpy with omniNotify. Everything works, but the performance in respect to event passing seems quite slow. The load on the system is about 15-20 events per minute. I'm seeing delays of around a full minute from the time an event is sent to the time the event arrives. I've run the application on both a Mac OS X 10.2.6 system and a Red Hat Linux 7.3.2 system. The delay is about the same regardless of the system I run the application on. Any suggestions on how to decrease the delay in event delivery would be appreciated. Thanks. _______________________________________________ omninotify-list mailing list omninotify-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omninotify-list _______________________________________________ omninotify-list mailing list omninotify-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omninotify-list From jay.welch@transcore.com Thu Aug 07 19:06:17 2003 Received: from atlexs1.transcore.com ([208.206.232.12] helo=atlexs1.tcore.com) by omniorb-support.com with esmtp (Exim 4.14) id 19kp9V-0003yi-6A for omninotify-list@omniorb-support.com; Thu, 07 Aug 2003 19:06:17 +0100 Received: by ATLEXS1 with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Aug 2003 14:02:50 -0400 Message-ID: <1B3C572E7415D511A5CD00025558571503408877@ATLEXS1> From: "Welch, Jay" To: "'omninotify-list@omniorb-support.com'" Date: Thu, 7 Aug 2003 14:02:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35D0E.1C619B70" Subject: [omniNotify] Windows Linking Problems X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2003 18:06:17 -0000 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C35D0E.1C619B70 Content-Type: text/plain; charset="iso-8859-1" Hi all, Looking through the archives I have seen some mention about some issues porting omniNotify to windows. The problem is when linking the CosNotify402_rt.lib and CosNotify402_rt.exp. Message: CosNotify402_rt.exp : error LNK2001: unresolved external symbol "public: __thiscall std::basic_istream >::_Sentry_base etc... Along with other symbols that refer to the standard library. In my limited experience with windows development I do believe this error is caused by the common mistake of using mis-matched compiler options between the various builds of the libraries. I was wondering if someone could help me in finding the appropriate config files that I can check to make sure that the appropriate -MD or -MDd options are being set. By the way this build is on a Windows 2000 machine and the config platform is x86_nt_4.0_vs_7. I appreciate any and all responses to this question. Jay Welch 3500 Parkway Lane Suite 600 Norcross GA. 30092 Work:(770) 246-6263 ------_=_NextPart_001_01C35D0E.1C619B70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Windows Linking Problems

Hi all,
   Looking through the = archives I have seen some mention about some issues porting omniNotify = to windows. The problem is when linking the CosNotify402_rt.lib and = CosNotify402_rt.exp.

    Message: = CosNotify402_rt.exp : error LNK2001: unresolved external symbol = "public: __thiscall std::basic_istream<char,struct = std::char_traits<char> >::_Sentry_base etc...

    Along with other = symbols that refer to the standard library. In my limited experience = with windows development I do believe this error is caused by the = common mistake of using mis-matched compiler options between the = various builds of the libraries. I was wondering if someone could help = me in finding the appropriate config files that I can check to make = sure that the appropriate -MD or -MDd options are being set. By the way = this build is on a Windows 2000 machine and the config platform is = x86_nt_4.0_vs_7. I appreciate any and all responses to this = question.


Jay Welch
3500 Parkway Lane
Suite 600
Norcross GA. 30092
Work:(770) 246-6263

------_=_NextPart_001_01C35D0E.1C619B70-- From Cameron.Rochester@Ripple-Systems.com Fri Aug 08 03:52:15 2003 Received: from [203.17.161.11] (helo=webmailme.motherwell.com.au) by omniorb-support.com with smtp (Exim 4.14) id 19kxMU-0004N1-I1 for omninotify-list@omniorb-support.com; Fri, 08 Aug 2003 03:52:14 +0100 Received: (qmail 27396 invoked by uid 1007); 8 Aug 2003 02:47:43 -0000 Received: from Cameron.Rochester@Ripple-Systems.com by webmailme by uid 1004 with qmail-scanner-1.15 (uvscan: v4.1.60/v4283. Clear:. Processed in 2.803268 secs); 08 Aug 2003 02:47:43 -0000 Received: from unknown (HELO envelope.pth.motherwell.com.au) (192.168.70.14) by webmailme.motherwell.com.au with SMTP; 8 Aug 2003 02:47:39 -0000 Received: by envelope.pth.motherwell.com.au with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Aug 2003 10:47:39 +0800 Message-ID: From: Cameron Rochester To: "'Robert E. Gruber'" Subject: RE: [omniNotify] omniNotify Performance Tuning Question / subscri ption bug Date: Fri, 8 Aug 2003 10:47:37 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: "'omninotify-list@omniorb-support.com'" X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2003 02:52:15 -0000 Robert, > Once a proxy is marked as a problem (exception occurred when > using to its connected client) the proxy no longer holds onto > events queued for the client, but the proxy itself is not > destroyed right away. To do a final cleanup of such 'dead' > proxies and their related admins and filters, you need to > use 'cleanup both' on the server using the do_command API. Is it safe to call server->do_command( "cleanup both" ) at regular intervals? For example our Notification Service application wraps the omniNotify library and makes use of the AttNotification interface to retrieve the server and the initial eventChannelFactory. From there it doesn't make use of the interactive interface or anything other than standard CosNotify interfaces. Is it ok to call "cleanup both" at regular, configurable, intervals throughout the lifetime of the application? This will not effect filters/admins/proxies that are in a normal state? Thanks again Cameron -----Original Message----- From: omninotify-list-bounces@omniorb-support.com [mailto:omninotify-list-bounces@omniorb-support.com] On Behalf Of Cameron Rochester Sent: Thursday, August 07, 2003 2:13 AM To: 'Robert E. Gruber'; omninotify-list@omniorb-support.com Subject: RE: [omniNotify] omniNotify Performance Tuning Question Robert, I grabbed the latest omniNotify snapshot (and the latest omniORB snapshot) and checked the update.log, it contained the following entry: "Changed things so event lock is not held across push (required different approach for omniORB3 vs. omniORB4). Also remove all events from outgoing queue of a proxy that gets _pxstatus set to RDI_Exception." I assume this is the fix you have mentioned? After a few hours of building I was ready to go again. One other thing - does omniNotify clean up invalid suppliers/consumers/filters if a client application crashes? On to the testing.... environment: - Solaris 2.8 (Sunfire V480 - 2 x 1.1G with 4,096MB RAM. GCC 3.2.1) running omniNotify - Win2k (P4 2.4G with 512MB RAM. VS 6.0) running test client I performed the test again and found performance to be a little better. For the implementation of the client please refer to the "omniNotify subscription bug" email I also sent today, I use the same application for gathering performance data. Performance for unique subscriptions had improved but still exhibited very poor perfomance with > 32 unique subscribers. Performance for unique subscriptions was generally double the last build with > 16 unique subscribers. Shared subscriptions again show what approaches a flat performance rate. For a graph of this data please see http://ii.net/~rochest/graph.gif. The graph shows performance with up to 1024 subscribed types. Our system can easily require in excess of 1000 subscribed event types. Regards Cameron Rochester -----Original Message----- From: Robert E. Gruber [mailto:gruber@research.att.com] Sent: Wednesday, August 06, 2003 11:34 PM To: 'Cameron Rochester'; omninotify-list@omniorb-support.com Cc: Robert E. Gruber Subject: RE: [omniNotify] omniNotify Performance Tuning Question omniNotify is supposed to scale with clients much better than Cameron describes. The poor scaling he reports may be due to a bug that was recently fixed (a lock was held across push calls where it should not be). Perhaps Cameron would you be willing to get the latest omniORB and omniNotify from sourceforge and try benchmarking again? For those interesting in getting stuff from sourceforge, I will send another email describing how to do this. A new omniORB 4 release will happen soon, and this will be followed by the long-awaited (!) omniNotify 2.0 official release (which depends on the upcoming omniORB 4, at least for the Windows port). Next email: getting sources. -- Bob -----Original Message----- From: omninotify-list-bounces@omniorb-support.com [mailto:omninotify-list-bounces@omniorb-support.com] On Behalf Of Cameron Rochester Sent: Tuesday, August 05, 2003 8:27 PM To: omninotify-list@omniorb-support.com Subject: RE: [omniNotify] omniNotify Performance Tuning Question Patrick, How many consumers are connected to the notification service? What is the complexity of the filters that you have in place? I have found with testing that performance drops off considerably as consumers increase (it is much worse than a linear degradation). However, evaluating more complex filters and having less consumers is actually a lot faster. Our system used to have multiple connections to the notification service from the same client. I changed the approach and reduced the number of connections while increasing the filter complexity and found performance to be much better while reducing load on the service. Having said that, I never saw the kind of lag that you are experiencing. Running the service on a (relatively) slow dual processor solaris box (2 x 400MHz, 512Mb RAM) and sending/receiving events from a seperate windows client (P4 2.4G, 512Mb RAM) the notification service would still manage approx 10 events/sec with 1700 unique subscribers. The faster approach was to create a filter with a constraint expression seq with 1700 individual constraints (but only one connection) and then perform simple filtering on the client side to ensure the correct subscriber receives the correct event. With this approach the notification service sustains ~500 events/sec with 1700 subscribed types. With 1-2 subscribed types it would manage upwards of 600 events/sec. So, the service should be able to handle significantly more than 15-20 events minute, but we probably need a bit more information regarding the way in which you are consuming events. Cheers Cameron Rochester -----Original Message----- From: Patrick Vaughan [mailto:plvaugh@sandia.gov] Sent: Wednesday, August 06, 2003 6:55 AM To: omninotify-list@omniorb-support.com Cc: omniorb-list@omniorb-support.com Subject: [omniNotify] omniNotify Performance Tuning Question Greetings, I've been running an application which uses omniORB/omniORBpy with omniNotify. Everything works, but the performance in respect to event passing seems quite slow. The load on the system is about 15-20 events per minute. I'm seeing delays of around a full minute from the time an event is sent to the time the event arrives. I've run the application on both a Mac OS X 10.2.6 system and a Red Hat Linux 7.3.2 system. The delay is about the same regardless of the system I run the application on. Any suggestions on how to decrease the delay in event delivery would be appreciated. Thanks. _______________________________________________ omninotify-list mailing list omninotify-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omninotify-list _______________________________________________ omninotify-list mailing list omninotify-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omninotify-list From Cameron.Rochester@Ripple-Systems.com Fri Aug 08 03:53:17 2003 Received: from [203.17.161.11] (helo=webmailme.motherwell.com.au) by omniorb-support.com with smtp (Exim 4.14) id 19kxNU-0004Nx-Ft for omninotify-list@omniorb-support.com; Fri, 08 Aug 2003 03:53:16 +0100 Received: (qmail 27439 invoked by uid 1007); 8 Aug 2003 02:48:45 -0000 Received: from Cameron.Rochester@Ripple-Systems.com by webmailme by uid 1004 with qmail-scanner-1.15 (uvscan: v4.1.60/v4283. Clear:. Processed in 5.196368 secs); 08 Aug 2003 02:48:45 -0000 Received: from unknown (HELO envelope.pth.motherwell.com.au) (192.168.70.14) by webmailme.motherwell.com.au with SMTP; 8 Aug 2003 02:48:39 -0000 Received: by envelope.pth.motherwell.com.au with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Aug 2003 10:48:39 +0800 Message-ID: From: Cameron Rochester To: omninotify-list@omniorb-support.com Subject: RE: [omniNotify] omniNotify Performance Tuning Question / subscri ption bug Date: Fri, 8 Aug 2003 10:48:30 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2003 02:53:17 -0000 Robert, (sorry about duplicate email. Forgot to cc to omniNotify list) I am using the default channel.cfg. I don't quite do it the way you have interpreted, sorry about the lack of clarity. Method 1: (older and slower approach for our project) Application creates 512 proxies to match the 512 StructuredPushConsumer's, each StructuredPushConsumer creates a single Filter (each Filter has a single constraint) on it's associated Proxy. The StructuredPushConsumer's are created in a loop, one after the other with the filter being added as soon as the StructuredPushConsumer is created. After all the StructuredPushConsumer's are created the same application will send events that will only match one of the created constraints. Method 2: (faster approach for our project) Application creates 1 proxy to match a single StructuredPushConsumer, the StructuredPushConsumer creates a single filter with an empty constraint. 512 subscribers are then added - each subscriber adds its own constraint to the existing Filter, one at a time, using add_constraints() (The constraintExpSeq being passed to the filter only contains one constraint). I know it would be faster to add all the constraints in one go with 512 constraints in the constraintExpSeq, but that approach does not suit our project. Once all the subscribers have been added the application starts sending events as in method 1. (Obviously some client side filtering based on EventType needs to be applied in this scenario) The bug occurs only in Method 2: Start one instance of the application, once all constraints have been updated on the single filter the application starts to send and receive events. Now that the events are flowing start another instance of the application, as soon as the constraints start being updated on the Filter the NS will lock up, as described in my earlier email. Does that clear it up a little? Cheers Cameron -----Original Message----- From: Robert E. Gruber [mailto:gruber@research.att.com] Sent: Thursday, August 07, 2003 10:01 PM To: 'Cameron Rochester'; omninotify-list@omniorb-support.com Cc: Robert E Gruber Subject: RE: [omniNotify] omniNotify Performance Tuning Question / subscription bug Cameron, let me make sure I understand your test setup. Is this true: You have a single client program that connects through a single proxy. Then it either adds 512 filters, where each filter subscribes to one event type, or it adds one filter with 512 constraints, where each constraint matches a single event type. The same client then supplies events of all 512 types. So you are not checking the scaling of omniNotify with number of clients, but rather with either the number of filters or the number of constraints per filter? Also, the bug you reported occurs if you run two such clients? Also, what config do you use? (The default channel.cfg?) -- Bob > One other thing - does omniNotify clean up invalid > suppliers/consumers/filters if a client application crashes? Once a proxy is marked as a problem (exception occurred when using to its connected client) the proxy no longer holds onto events queued for the client, but the proxy itself is not destroyed right away. To do a final cleanup of such 'dead' proxies and their related admins and filters, you need to use 'cleanup both' on the server using the do_command API. -- Bob -----Original Message----- From: omninotify-list-bounces@omniorb-support.com [mailto:omninotify-list-bounces@omniorb-support.com] On Behalf Of Cameron Rochester Sent: Thursday, August 07, 2003 2:13 AM To: 'Robert E. Gruber'; omninotify-list@omniorb-support.com Subject: RE: [omniNotify] omniNotify Performance Tuning Question Robert, I grabbed the latest omniNotify snapshot (and the latest omniORB snapshot) and checked the update.log, it contained the following entry: "Changed things so event lock is not held across push (required different approach for omniORB3 vs. omniORB4). Also remove all events from outgoing queue of a proxy that gets _pxstatus set to RDI_Exception." I assume this is the fix you have mentioned? After a few hours of building I was ready to go again. One other thing - does omniNotify clean up invalid suppliers/consumers/filters if a client application crashes? On to the testing.... environment: - Solaris 2.8 (Sunfire V480 - 2 x 1.1G with 4,096MB RAM. GCC 3.2.1) running omniNotify - Win2k (P4 2.4G with 512MB RAM. VS 6.0) running test client I performed the test again and found performance to be a little better. For the implementation of the client please refer to the "omniNotify subscription bug" email I also sent today, I use the same application for gathering performance data. Performance for unique subscriptions had improved but still exhibited very poor perfomance with > 32 unique subscribers. Performance for unique subscriptions was generally double the last build with > 16 unique subscribers. Shared subscriptions again show what approaches a flat performance rate. For a graph of this data please see http://ii.net/~rochest/graph.gif. The graph shows performance with up to 1024 subscribed types. Our system can easily require in excess of 1000 subscribed event types. Regards Cameron Rochester -----Original Message----- From: Robert E. Gruber [mailto:gruber@research.att.com] Sent: Wednesday, August 06, 2003 11:34 PM To: 'Cameron Rochester'; omninotify-list@omniorb-support.com Cc: Robert E. Gruber Subject: RE: [omniNotify] omniNotify Performance Tuning Question omniNotify is supposed to scale with clients much better than Cameron describes. The poor scaling he reports may be due to a bug that was recently fixed (a lock was held across push calls where it should not be). Perhaps Cameron would you be willing to get the latest omniORB and omniNotify from sourceforge and try benchmarking again? For those interesting in getting stuff from sourceforge, I will send another email describing how to do this. A new omniORB 4 release will happen soon, and this will be followed by the long-awaited (!) omniNotify 2.0 official release (which depends on the upcoming omniORB 4, at least for the Windows port). Next email: getting sources. -- Bob -----Original Message----- From: omninotify-list-bounces@omniorb-support.com [mailto:omninotify-list-bounces@omniorb-support.com] On Behalf Of Cameron Rochester Sent: Tuesday, August 05, 2003 8:27 PM To: omninotify-list@omniorb-support.com Subject: RE: [omniNotify] omniNotify Performance Tuning Question Patrick, How many consumers are connected to the notification service? What is the complexity of the filters that you have in place? I have found with testing that performance drops off considerably as consumers increase (it is much worse than a linear degradation). However, evaluating more complex filters and having less consumers is actually a lot faster. Our system used to have multiple connections to the notification service from the same client. I changed the approach and reduced the number of connections while increasing the filter complexity and found performance to be much better while reducing load on the service. Having said that, I never saw the kind of lag that you are experiencing. Running the service on a (relatively) slow dual processor solaris box (2 x 400MHz, 512Mb RAM) and sending/receiving events from a seperate windows client (P4 2.4G, 512Mb RAM) the notification service would still manage approx 10 events/sec with 1700 unique subscribers. The faster approach was to create a filter with a constraint expression seq with 1700 individual constraints (but only one connection) and then perform simple filtering on the client side to ensure the correct subscriber receives the correct event. With this approach the notification service sustains ~500 events/sec with 1700 subscribed types. With 1-2 subscribed types it would manage upwards of 600 events/sec. So, the service should be able to handle significantly more than 15-20 events minute, but we probably need a bit more information regarding the way in which you are consuming events. Cheers Cameron Rochester -----Original Message----- From: Patrick Vaughan [mailto:plvaugh@sandia.gov] Sent: Wednesday, August 06, 2003 6:55 AM To: omninotify-list@omniorb-support.com Cc: omniorb-list@omniorb-support.com Subject: [omniNotify] omniNotify Performance Tuning Question Greetings, I've been running an application which uses omniORB/omniORBpy with omniNotify. Everything works, but the performance in respect to event passing seems quite slow. The load on the system is about 15-20 events per minute. I'm seeing delays of around a full minute from the time an event is sent to the time the event arrives. I've run the application on both a Mac OS X 10.2.6 system and a Red Hat Linux 7.3.2 system. The delay is about the same regardless of the system I run the application on. Any suggestions on how to decrease the delay in event delivery would be appreciated. Thanks. _______________________________________________ omninotify-list mailing list omninotify-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omninotify-list _______________________________________________ omninotify-list mailing list omninotify-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omninotify-list From gruber@research.att.com Fri Aug 08 18:13:55 2003 Received: from h-135-207-24-16.research.att.com ([135.207.24.16] helo=linux.research.att.com) by omniorb-support.com with esmtp (Exim 4.14) id 19lAoN-0004lg-5t for omninotify-list@omniorb-support.com; Fri, 08 Aug 2003 18:13:55 +0100 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by linux.research.att.com (8.12.8/8.12.8) with ESMTP id h78H9wPj028685; Fri, 8 Aug 2003 13:09:58 -0400 Received: from pcgruber (pc-gruber.research.att.com [135.207.23.156]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id h78H8nZ15541; Fri, 8 Aug 2003 13:08:50 -0400 (EDT) From: "Robert E. Gruber" To: "'Cameron Rochester'" Subject: RE: [omniNotify] omniNotify Performance Tuning Question / subscription bug Date: Fri, 8 Aug 2003 13:05:36 -0400 Message-ID: <006401c35dcf$49f6cb70$9c17cf87@pcgruber> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Cc: "Robert E. Gruber" , omninotify-list@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2003 17:13:55 -0000 'cleanup both' will remove all proxies that have no connection or whose connection is marked as broken due to a communication failure. The only danger in calling it at an arbitrary time would be this kind of sequence 1. client C obtains a proxy P 2. some other thread or client does a 'cleanup both' 3. client C attempts to connect to proxy P Since step 2 would destroy P, step 3 would fail. I should probably change the cleanup so that it does not destroy recently-created proxies that have not yet received a connect request. This would fix this potential race condition. -- Bob -----Original Message----- From: omninotify-list-bounces@omniorb-support.com [mailto:omninotify-list-bounces@omniorb-support.com] On Behalf Of Cameron Rochester Sent: Thursday, August 07, 2003 10:48 PM To: 'Robert E. Gruber' Cc: 'omninotify-list@omniorb-support.com' Subject: RE: [omniNotify] omniNotify Performance Tuning Question / subscription bug Robert, > Once a proxy is marked as a problem (exception occurred when > using to its connected client) the proxy no longer holds onto > events queued for the client, but the proxy itself is not > destroyed right away. To do a final cleanup of such 'dead' > proxies and their related admins and filters, you need to > use 'cleanup both' on the server using the do_command API. Is it safe to call server->do_command( "cleanup both" ) at regular intervals? For example our Notification Service application wraps the omniNotify library and makes use of the AttNotification interface to retrieve the server and the initial eventChannelFactory. From there it doesn't make use of the interactive interface or anything other than standard CosNotify interfaces. Is it ok to call "cleanup both" at regular, configurable, intervals throughout the lifetime of the application? This will not effect filters/admins/proxies that are in a normal state? Thanks again Cameron -----Original Message----- From: omninotify-list-bounces@omniorb-support.com [mailto:omninotify-list-bounces@omniorb-support.com] On Behalf Of Cameron Rochester Sent: Thursday, August 07, 2003 2:13 AM To: 'Robert E. Gruber'; omninotify-list@omniorb-support.com Subject: RE: [omniNotify] omniNotify Performance Tuning Question Robert, I grabbed the latest omniNotify snapshot (and the latest omniORB snapshot) and checked the update.log, it contained the following entry: "Changed things so event lock is not held across push (required different approach for omniORB3 vs. omniORB4). Also remove all events from outgoing queue of a proxy that gets _pxstatus set to RDI_Exception." I assume this is the fix you have mentioned? After a few hours of building I was ready to go again. One other thing - does omniNotify clean up invalid suppliers/consumers/filters if a client application crashes? On to the testing.... environment: - Solaris 2.8 (Sunfire V480 - 2 x 1.1G with 4,096MB RAM. GCC 3.2.1) running omniNotify - Win2k (P4 2.4G with 512MB RAM. VS 6.0) running test client I performed the test again and found performance to be a little better. For the implementation of the client please refer to the "omniNotify subscription bug" email I also sent today, I use the same application for gathering performance data. Performance for unique subscriptions had improved but still exhibited very poor perfomance with > 32 unique subscribers. Performance for unique subscriptions was generally double the last build with > 16 unique subscribers. Shared subscriptions again show what approaches a flat performance rate. For a graph of this data please see http://ii.net/~rochest/graph.gif. The graph shows performance with up to 1024 subscribed types. Our system can easily require in excess of 1000 subscribed event types. Regards Cameron Rochester -----Original Message----- From: Robert E. Gruber [mailto:gruber@research.att.com] Sent: Wednesday, August 06, 2003 11:34 PM To: 'Cameron Rochester'; omninotify-list@omniorb-support.com Cc: Robert E. Gruber Subject: RE: [omniNotify] omniNotify Performance Tuning Question omniNotify is supposed to scale with clients much better than Cameron describes. The poor scaling he reports may be due to a bug that was recently fixed (a lock was held across push calls where it should not be). Perhaps Cameron would you be willing to get the latest omniORB and omniNotify from sourceforge and try benchmarking again? For those interesting in getting stuff from sourceforge, I will send another email describing how to do this. A new omniORB 4 release will happen soon, and this will be followed by the long-awaited (!) omniNotify 2.0 official release (which depends on the upcoming omniORB 4, at least for the Windows port). Next email: getting sources. -- Bob -----Original Message----- From: omninotify-list-bounces@omniorb-support.com [mailto:omninotify-list-bounces@omniorb-support.com] On Behalf Of Cameron Rochester Sent: Tuesday, August 05, 2003 8:27 PM To: omninotify-list@omniorb-support.com Subject: RE: [omniNotify] omniNotify Performance Tuning Question Patrick, How many consumers are connected to the notification service? What is the complexity of the filters that you have in place? I have found with testing that performance drops off considerably as consumers increase (it is much worse than a linear degradation). However, evaluating more complex filters and having less consumers is actually a lot faster. Our system used to have multiple connections to the notification service from the same client. I changed the approach and reduced the number of connections while increasing the filter complexity and found performance to be much better while reducing load on the service. Having said that, I never saw the kind of lag that you are experiencing. Running the service on a (relatively) slow dual processor solaris box (2 x 400MHz, 512Mb RAM) and sending/receiving events from a seperate windows client (P4 2.4G, 512Mb RAM) the notification service would still manage approx 10 events/sec with 1700 unique subscribers. The faster approach was to create a filter with a constraint expression seq with 1700 individual constraints (but only one connection) and then perform simple filtering on the client side to ensure the correct subscriber receives the correct event. With this approach the notification service sustains ~500 events/sec with 1700 subscribed types. With 1-2 subscribed types it would manage upwards of 600 events/sec. So, the service should be able to handle significantly more than 15-20 events minute, but we probably need a bit more information regarding the way in which you are consuming events. Cheers Cameron Rochester -----Original Message----- From: Patrick Vaughan [mailto:plvaugh@sandia.gov] Sent: Wednesday, August 06, 2003 6:55 AM To: omninotify-list@omniorb-support.com Cc: omniorb-list@omniorb-support.com Subject: [omniNotify] omniNotify Performance Tuning Question Greetings, I've been running an application which uses omniORB/omniORBpy with omniNotify. Everything works, but the performance in respect to event passing seems quite slow. The load on the system is about 15-20 events per minute. I'm seeing delays of around a full minute from the time an event is sent to the time the event arrives. I've run the application on both a Mac OS X 10.2.6 system and a Red Hat Linux 7.3.2 system. The delay is about the same regardless of the system I run the application on. Any suggestions on how to decrease the delay in event delivery would be appreciated. Thanks. _______________________________________________ omninotify-list mailing list omninotify-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omninotify-list _______________________________________________ omninotify-list mailing list omninotify-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omninotify-list _______________________________________________ omninotify-list mailing list omninotify-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omninotify-list From tmacd@eintelligence-inc.com Tue Sep 02 18:46:34 2003 Received: from [198.174.211.202] (helo=hubbub.eintelligence-inc.com) by omniorb-support.com with esmtp (Exim 4.14) id 19uFEg-00036s-HY for omninotify-list@omniorb-support.com; Tue, 02 Sep 2003 18:46:34 +0100 Received: from sundeva.eintelligence-inc.com (sundeva.eintelligence-inc.com [172.16.64.15]) by hubbub.eintelligence-inc.com (8.12.9/8.12.9) with ESMTP id h82Hk3B0021421 for ; Tue, 2 Sep 2003 12:46:03 -0500 (CDT) Received: from sundeva.eintelligence-inc.com (tmacd@localhost [127.0.0.1]) by sundeva.eintelligence-inc.com (8.12.9/8.12.9) with ESMTP id h82HjXpE000011 for ; Tue, 2 Sep 2003 12:45:33 -0500 (CDT) Received: (from tmacd@localhost) by sundeva.eintelligence-inc.com (8.12.9/8.12.9/Submit) id h82HjXoo000009 for omninotify-list@omniorb-support.com; Tue, 2 Sep 2003 12:45:33 -0500 (CDT) From: Tom MacDonald Message-Id: <200309021745.h82HjXoo000009@sundeva.eintelligence-inc.com> To: omninotify-list@omniorb-support.com Date: Tue, 2 Sep 2003 12:45:32 -0500 (CDT) X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [omniNotify] omniorb 4.0 error X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2003 17:46:34 -0000 I'm using, omniorb 4.0 built with g++ 3.2.2 and the server part of the client/server is running on red hat linux. While starting up the server I get the following message: Unable to create an endpoint of this description: giop:tcp:prodlinux:12721 SystemException::INITIALIZE but only when I start the server up a 2nd time. If I reboot the system, I can start up the server just fine. If I then try to restart the server I get the above message. The C++ code that causes this to happen is: CORBA::ORB_var orb = CORBA::ORB_init(argc, argv, "omniORB4"); if (verbose) { std::cout << "+Initialization of 'CORBA::ORB_var' complete." << std::endl; } // create the BOA, the BOA will use the properties object CORBA::BOA_var boa = orb->BOA_init(argc, argv, "omniORB4_BOA"); if (verbose) { std::cout << "+Initialization of 'CORBA::BOA_var' complete." << std::endl; } The first 'verbose' message prints just fine. The second 'verbose' message never prints. So, it must be the call to "orb->BOA_init" that is causing the SystemException to be raised. Intersting argv parameters are: -ORBendPoint giop:tcp:prodlinux:12721 -ORBsupportBootstrapAgent 1 -ORBInitRef NameService=corbaloc::prodlinux:12720/NameService Is this indicating a problem with port 12721 or maybe 12720? Thanks in advance for any assistance you can offer. From duncan@grisby.org Wed Sep 03 17:29:31 2003 Received: from pc1-cmbg4-5-cust104.cmbg.cable.ntl.com ([81.96.72.104] helo=grisby.dyndns.org) by omniorb-support.com with esmtp (Exim 4.14) id 19uaVf-0003xi-8u; Wed, 03 Sep 2003 17:29:31 +0100 Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h83GTRX22261; Wed, 3 Sep 2003 17:29:29 +0100 Message-Id: <200309031629.h83GTRX22261@grisby.dyndns.org> X-Authentication-Warning: pc1-cmbg4-5-cust104.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: Tom MacDonald Subject: Re: [omniNotify] omniorb 4.0 error In-Reply-To: Message from Tom MacDonald of "Tue, 02 Sep 2003 12:45:32 CDT." <200309021745.h82HjXoo000009@sundeva.eintelligence-inc.com> From: Duncan Grisby Date: Wed, 03 Sep 2003 17:29:27 +0100 Cc: omninotify-list@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2003 16:29:31 -0000 On Tuesday 2 September, Tom MacDonald wrote: > While starting up the server I get the following message: > > Unable to create an endpoint of this description: giop:tcp:prodlinux:12721 > SystemException::INITIALIZE > > but only when I start the server up a 2nd time. If I reboot the > system, I can start up the server just fine. If I then try to restart > the server I get the above message. There must be something left behind listening on port 12721. Use netstat -a to see it. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From gruber@research.att.com Fri Sep 26 13:55:41 2003 Received: from h-135-207-24-16.research.att.com ([135.207.24.16] helo=linux.research.att.com) by omniorb-support.com with esmtp (Exim 4.14) id 1A2s8L-0004OZ-GN for omninotify-list@omniorb-support.com; Fri, 26 Sep 2003 13:55:41 +0100 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by linux.research.att.com (8.12.8/8.12.8) with ESMTP id h8QCtLet029903; Fri, 26 Sep 2003 08:55:21 -0400 Received: from pcgruberhome (brow2116.research.att.com [135.207.58.116]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id h8QCt9Z29513; Fri, 26 Sep 2003 08:55:09 -0400 (EDT) From: "Robert E. Gruber" To: Date: Fri, 26 Sep 2003 08:55:09 -0400 Message-ID: <000501c3842d$6aecbb80$743acf87@research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Cc: 'Cameron Rochester' , Robert E Gruber Subject: [omniNotify] omniNotify status update X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2003 12:55:41 -0000 Here is a quick status update on omniNotify. Cameron Rochester found a deadlock case a few weeks ago, and I have been busy trying to make sure that not only is this case fixed, but all possible deadlock cases are fixed. The outcome will be a more robust omniNotify. Here are details on what I have been doing: I did two kinds of code rewrites: 1. I made sure all locks are acquired using helper objects that are placed on the stack when the lock is acquired and that unlock the object on scope exit (when the helper object destructor is run). This makes sure locks are properly unlocked even when exceptions are thrown or there are return statements out of scope, etc. 2. I added a new debugging flag, TW_DEBUG (thread wrapper debug), which, when set, causes lock acquistion/release info to be dumped to stderr or to a file. Then I wrote a Perl script that examines this dumped info for potential deadlock scenarios. By running with TW_DEBUG=1 with the example that Cameron found, plus just my normal range of test cases, I have identified a set of required fixes. I am now working on the fixes. Certain incoming requests will need to grab all of the locks that they need up front, so that the lock order that they use is one that is required to prevent deadlocks. For example, a proxy object in some cases will need to first grab the channel lock, then the typemap lock, then its own lock. This means when it calls channel methods it needs to tell the channel 'by the way, I already hold the channel and typemap locks', so a number of internal APIs need to change. I should have something that people can try out by Tuesday or Wednesday. I hope the delay in the release of omniNotify will be worth it. I didn't want to do the next major release with a known deadlock bug! Thanks for you patience. -- Bob From gruber@research.att.com Thu Oct 23 14:49:35 2003 Received: from h-135-207-24-32.research.att.com ([135.207.24.32] helo=mailman.research.att.com) by omniorb-support.com with esmtp (Exim 4.14) id 1ACfqJ-0007HF-Io for omninotify-list@omniorb-support.com; Thu, 23 Oct 2003 14:49:35 +0100 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mailman.research.att.com (8.12.8/8.12.8) with ESMTP id h9NDiTLZ016871 for ; Thu, 23 Oct 2003 09:44:29 -0400 Received: from pcgruber (pc-gruber.research.att.com [135.207.23.156]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id h9NDn4Z17268; Thu, 23 Oct 2003 09:49:04 -0400 (EDT) From: "Robert E. Gruber" To: Date: Thu, 23 Oct 2003 09:49:21 -0400 Message-ID: <007201c3996c$76720f10$9c17cf87@pcgruber> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0073_01C3994A.EF606F10" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Cc: "Robert E. Gruber" Subject: [omniNotify] Latest omniNotify 2 alpha update X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2003 13:49:35 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0073_01C3994A.EF606F10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We are now using the dev branch (omniNotify2_develop) in preparation for the upcoming 2.0 release. I have checked in the changes described in my previous email (deadlock fixes, all locks acquired using helper objects) into the dev branch. There is also now support for object GC for long-lived notifd: see channel.cfg for details. It would be great if some people could check out the omniNotify2_develop branch and try it out. This page describes how to do that. http://www.research.att.com/~ready/omniNotify/nfy_beta_download.html If you are getting snapshots rather than using CVS, you may have to wait a day for the latest code to be available in a snapshot. (Duncan, would you be willing to send email when the latest snapshot reflects the changes I just checked in?) BTW I will be traveling so I won't be able to respond to email until Monday. Thanks, -- Bob ------=_NextPart_000_0073_01C3994A.EF606F10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We are now using = the dev branch (omniNotify2_develop) in preparation for

the upcoming 2.0 release.   I have checked in the changes described = in

my previous email = (deadlock fixes, all locks acquired using helper

objects) into the = dev branch.  There is also now support for object GC

for long-lived = notifd: see channel.cfg for details. 

 

It would be great = if some people could check out the omniNotify2_develop

branch and try it = out.  This page describes how to do that.

 

http://www.research.att.com/~ready/omniNotify/nfy_beta_download.html=

 

If you are getting = snapshots rather than using CVS, you may have to wait a day for the latest code to = be available in a snapshot.  (Duncan, would you be willing to send email when the latest snapshot reflects the changes I just checked in?)

 

BTW I will be = traveling so I won't be able to respond to email until Monday.

 

Thanks, =

-- = Bob

 

 

 

 

 

------=_NextPart_000_0073_01C3994A.EF606F10-- From duncan@grisby.org Thu Oct 23 15:46:13 2003 Received: from cpc1-cmbg4-5-0-cust104.cmbg.cable.ntl.com ([81.96.72.104] helo=grisby.dyndns.org) by omniorb-support.com with esmtp (Exim 4.14) id 1ACgj6-0007QU-UZ; Thu, 23 Oct 2003 15:46:12 +0100 Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h9NEkCa19301; Thu, 23 Oct 2003 15:46:12 +0100 Message-Id: <200310231446.h9NEkCa19301@grisby.dyndns.org> X-Authentication-Warning: cpc1-cmbg4-5-0-cust104.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: "Robert E. Gruber" Subject: Re: [omniNotify] Latest omniNotify 2 alpha update In-Reply-To: Message from "Robert E. Gruber" of "Thu, 23 Oct 2003 09:49:21 EDT." <007201c3996c$76720f10$9c17cf87@pcgruber> From: Duncan Grisby Date: Thu, 23 Oct 2003 15:46:12 +0100 Cc: omninotify-list@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2003 14:46:13 -0000 On Thursday 23 October, "Robert E. Gruber" wrote: > If you are getting snapshots rather than using CVS, you may have to > wait a day for the latest code to be available in a snapshot. > (Duncan, would you be willing to send email when the latest snapshot > reflects the changes I just checked in?) I just manually ran the script, so the snapshot now contains the changes. (I changed it to snapshot the omniNotify2_develop branch too.) Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From Cameron.Rochester@Ripple-Systems.com Mon Oct 27 05:03:52 2003 Received: from webmailme.motherwell.com.au ([203.17.161.11]) by omniorb-support.com with smtp (Exim 4.14) id 1ADzXj-0007g4-8w for omninotify-list@omniorb-support.com; Mon, 27 Oct 2003 05:03:51 +0000 Received: (qmail 27600 invoked by uid 1007); 27 Oct 2003 05:03:47 -0000 Received: from Cameron.Rochester@Ripple-Systems.com by webmailme by uid 1004 with qmail-scanner-1.15 (uvscan: v4.1.60/v4299. Clear:. Processed in 1.544451 secs); 27 Oct 2003 05:03:47 -0000 Received: from unknown (HELO envelope.pth.motherwell.com.au) (192.168.70.14) by webmailme.motherwell.com.au with SMTP; 27 Oct 2003 05:03:45 -0000 Received: by envelope.pth.motherwell.com.au with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Oct 2003 13:03:45 +0800 Message-ID: From: Cameron Rochester To: "'Robert E. Gruber'" Subject: RE: [omniNotify] Latest omniNotify 2 alpha update Date: Mon, 27 Oct 2003 13:03:45 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C39C47.B2A0CE80" Cc: omninotify-list@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2003 05:03:52 -0000 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C39C47.B2A0CE80 Content-Type: text/plain; charset="iso-8859-1" I have dloaded the latest snapshots and it seems to work well. I could not repeat the subscription bug that prompted a lot of this work. I can also confirm that this new release works with omniORB 4.01. The Object GC functionality looks great. We should be moving these new changes into our integration bed within the week, this will provide a much tougher work-out than my test applications. I will let everyone know how it goes. Thanks for your efforts! Cameron -----Original Message----- From: Robert E. Gruber [mailto:gruber@research.att.com] Sent: Thursday, October 23, 2003 9:49 PM To: omninotify-list@omniorb-support.com Cc: Robert E. Gruber Subject: [omniNotify] Latest omniNotify 2 alpha update We are now using the dev branch (omniNotify2_develop) in preparation for the upcoming 2.0 release. I have checked in the changes described in my previous email (deadlock fixes, all locks acquired using helper objects) into the dev branch. There is also now support for object GC for long-lived notifd: see channel.cfg for details. It would be great if some people could check out the omniNotify2_develop branch and try it out. This page describes how to do that. http://www.research.att.com/~ready/omniNotify/nfy_beta_download.html If you are getting snapshots rather than using CVS, you may have to wait a day for the latest code to be available in a snapshot. (Duncan, would you be willing to send email when the latest snapshot reflects the changes I just checked in?) BTW I will be traveling so I won't be able to respond to email until Monday. Thanks, -- Bob ------_=_NextPart_001_01C39C47.B2A0CE80 Content-Type: text/html; charset="iso-8859-1"
I have dloaded the latest snapshots and it seems to work well. I could not repeat the subscription bug that prompted a lot of this work.
 
I can also confirm that this new release works with omniORB 4.01. The Object GC functionality looks great.
 
We should be moving these new changes into our integration bed within the week, this will provide a much tougher work-out than my test applications. I will let everyone know how it goes.
 
Thanks for your efforts!
Cameron
-----Original Message-----
From: Robert E. Gruber [mailto:gruber@research.att.com]
Sent: Thursday, October 23, 2003 9:49 PM
To: omninotify-list@omniorb-support.com
Cc: Robert E. Gruber
Subject: [omniNotify] Latest omniNotify 2 alpha update

We are now using the dev branch (omniNotify2_develop) in preparation for

the upcoming 2.0 release.   I have checked in the changes described in

my previous email (deadlock fixes, all locks acquired using helper

objects) into the dev branch.  There is also now support for object GC

for long-lived notifd: see channel.cfg for details. 

 

It would be great if some people could check out the omniNotify2_develop

branch and try it out.  This page describes how to do that.

 

http://www.research.att.com/~ready/omniNotify/nfy_beta_download.html

 

If you are getting snapshots rather than using CVS, you may have to wait a day for the latest code to be available in a snapshot.  (Duncan, would you be willing to send email when the latest snapshot reflects the changes I just checked in?)

 

BTW I will be traveling so I won't be able to respond to email until Monday.

 

Thanks,

-- Bob

 

 

 

 

 

------_=_NextPart_001_01C39C47.B2A0CE80-- From zszyj@163.net Tue Oct 28 15:01:59 2003 Received: from [202.108.255.195] (helo=163.net) by omniorb-support.com with smtp (Exim 4.14) id 1AEVM6-0001Ba-VD for omninotify-list@omniorb-support.com; Tue, 28 Oct 2003 15:01:59 +0000 Received: from zyj (unknown [202.103.167.26]) by bjapp7 (Coremail) with SMTP id SYMEANyEnj8qAKca.1 for ; Tue, 28 Oct 2003 23:01:48 +0800 (CST) X-Originating-IP: [202.103.167.26] Date: Tue, 28 Oct 2003 23:0:7 +0800 From: "zszyj" To: omninotify-list@omniorb-support.com X-mailer: Foxmail 4.1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Message-Id: Subject: [omniNotify] Port to AIX X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2003 15:01:59 -0000 Hello all, I've successfully built omniNotify 2.0 on AIX5L with omniORB4, and the compiler is vacpp6. But for platform porting, some changes are required in the section "ifdef AIX" in the file "/mk/beforeauto.mk.in". See the detail information below. a. Correct line 931. It's clearly that a ahead "#" denotation is missed in the comment text: Incorrect text: error Not supported yet. Too nasty. Correct to: #error Not supported yet. Too nasty. b. Follow the line 931, insert some lines as below: CXXOPTIONS = -qstaticinline -qmaxmem=8192 -qlonglong -qlongdouble COPTIONS = -qmaxmem=8192 -qlonglong -qlongdouble OMNITHREAD_POSIX_CPPFLAGS = -DNoNanoSleep -DPthreadDraftVersion=10 OMNITHREAD_CPPFLAGS = -D_REENTRANT OMNITHREAD_LIB += -lpthread # this works only for xlc version >= 5 SharedLibraryPlatformLinkFlagsTemplate = -G Please notice the last line. You can't use "-qmkshobj" instead of "-G". Somehow, if you do that, a number of symbols are unresolved when linking. -- Tiga From duncan@grisby.org Wed Oct 29 16:23:37 2003 Received: from cpc1-cmbg4-5-0-cust104.cmbg.cable.ntl.com ([81.96.72.104] helo=grisby.dyndns.org) by omniorb-support.com with esmtp (Exim 4.14) id 1AEt6e-0002vL-Pa; Wed, 29 Oct 2003 16:23:36 +0000 Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h9TGNYo12188; Wed, 29 Oct 2003 16:23:36 GMT Message-Id: <200310291623.h9TGNYo12188@grisby.dyndns.org> X-Authentication-Warning: cpc1-cmbg4-5-0-cust104.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: "zszyj" Subject: Re: [omniNotify] Port to AIX In-Reply-To: Message from "zszyj" of "Tue, 28 Oct 2003 23:00:07 +0800." From: Duncan Grisby Date: Wed, 29 Oct 2003 16:23:33 +0000 Cc: "omninotify-list@omniorb-support.com" X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2003 16:23:37 -0000 On Tuesday 28 October, "zszyj" wrote: > I've successfully built omniNotify 2.0 on AIX5L with omniORB4, and > the compiler is vacpp6. But for platform porting, some changes are > required in the section "ifdef AIX" in the file > "/mk/beforeauto.mk.in". See the detail information > below. That's good. I assume Bob will check it in. > a. Correct line 931. It's clearly that a ahead "#" denotation is > missed in the comment text: > > Incorrect text: > error Not supported yet. Too nasty. Actually, that was an intentional error, to make sure the build failed on AIX. The aim was to make sure anyone trying to build on AIX looked at the rules to make sure they were right, rather than blindly using the wrong rules. Now you've figured out what the rules should be, the error can be removed. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From gruber@research.att.com Wed Oct 29 19:20:21 2003 Received: from h-135-207-24-32.research.att.com ([135.207.24.32] helo=mailman.research.att.com) by omniorb-support.com with esmtp (Exim 4.14) id 1AEvrh-0003AM-9Z for omninotify-list@omniorb-support.com; Wed, 29 Oct 2003 19:20:21 +0000 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mailman.research.att.com (8.12.8/8.12.8) with ESMTP id h9TJEgLZ021808; Wed, 29 Oct 2003 14:14:42 -0500 Received: from pcgruber (pc-gruber.research.att.com [135.207.23.156]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id h9TJJiZ14459; Wed, 29 Oct 2003 14:19:44 -0500 (EST) From: "Robert E. Gruber" To: "'Duncan Grisby'" , "'zszyj'" Subject: RE: [omniNotify] Port to AIX Date: Wed, 29 Oct 2003 14:19:54 -0500 Message-ID: <000701c39e51$a2b200a0$9c17cf87@pcgruber> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <200310291623.h9TGNYo12188@grisby.dyndns.org> Cc: omninotify-list@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2003 19:20:21 -0000 I checked in the suggested changes. Maybe someone with another AIX setup could try these definitions out? -----Original Message----- From: omninotify-list-bounces@omniorb-support.com [mailto:omninotify-list-bounces@omniorb-support.com] On Behalf Of Duncan Grisby Sent: Wednesday, October 29, 2003 11:24 AM To: zszyj Cc: omninotify-list@omniorb-support.com Subject: Re: [omniNotify] Port to AIX On Tuesday 28 October, "zszyj" wrote: > I've successfully built omniNotify 2.0 on AIX5L with omniORB4, and > the compiler is vacpp6. But for platform porting, some changes are > required in the section "ifdef AIX" in the file > "/mk/beforeauto.mk.in". See the detail information > below. That's good. I assume Bob will check it in. > a. Correct line 931. It's clearly that a ahead "#" denotation is > missed in the comment text: > > Incorrect text: > error Not supported yet. Too nasty. Actually, that was an intentional error, to make sure the build failed on AIX. The aim was to make sure anyone trying to build on AIX looked at the rules to make sure they were right, rather than blindly using the wrong rules. Now you've figured out what the rules should be, the error can be removed. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- _______________________________________________ omninotify-list mailing list omninotify-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omninotify-list From frederic.prin@silvaco.com Fri Dec 05 16:36:23 2003 Received: from portal.silvaco.com ([192.73.228.4]) by apasphere.com with esmtp (Exim 4.14) id 1ASIwJ-0005TH-03 for omninotify-list@omniorb-support.com; Fri, 05 Dec 2003 16:36:23 +0000 Received: from sbay.silvaco.com (sbay.Silvaco.COM [10.1.5.1]) by portal.silvaco.com (8.11.6+Sun/8.11.6) with ESMTP id hB5GaLW27819 for ; Fri, 5 Dec 2003 08:36:21 -0800 (PST) Received: from grenoble.silvaco.com (grenoble [10.66.5.1]) by sbay.silvaco.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17707 for ; Fri, 5 Dec 2003 08:36:20 -0800 (PST) Received: from bargy (bargy [10.66.10.24]) by grenoble.silvaco.com (8.9.1b+Sun/8.9.1) with SMTP id RAA11506 for ; Fri, 5 Dec 2003 17:36:17 +0100 (MET) Message-ID: <0f8b01c3bb4d$e85c60f0$180a420a@bargy> From: "FredP" To: Date: Fri, 5 Dec 2003 17:33:52 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0F88_01C3BB55.F340CB70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [omniNotify] Solaris5.8 64bits X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list Reply-To: FredP List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2003 16:36:23 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0F88_01C3BB55.F340CB70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello everybody, Is there someone who knows how compile omniNotify2.0beta for = sparc-solaris5.8 64bits ? A magic flag in configure command line ? Tweak the makefiles ? any suggestion are welcome since I'm a real dummy on autoconf makefiles. Thanks a lot ------------------------------------------------------------ Fr=E9d=E9ric Prin Software Engineer=20 Silvaco G.RE.CE =20 ------=_NextPart_000_0F88_01C3BB55.F340CB70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello everybody,
 
Is there someone who knows how compile=20 omniNotify2.0beta for sparc-solaris5.8 64bits ?
 
A magic flag in configure command line=20 ?
Tweak the makefiles ?
any suggestion are welcome since I'm a = real dummy=20 on autoconf makefiles.
 
Thanks a lot
 
------------------------------------------------------------
= Fr=E9d=E9ric=20 Prin           = Software=20 Engineer
Silvaco G.RE.CE  
 
 
------=_NextPart_000_0F88_01C3BB55.F340CB70-- From gruber@research.att.com Tue Dec 09 06:05:50 2003 Received: from mail-dark.research.att.com ([192.20.225.112]) by apasphere.com with esmtp (Exim 4.14) id 1ATb0I-0004oY-H8; Tue, 09 Dec 2003 06:05:50 +0000 Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by mail-dark.research.att.com (Postfix) with ESMTP id D4E7CC81E1; Tue, 9 Dec 2003 01:07:20 -0500 (EST) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-green.research.att.com (Postfix) with ESMTP id D6730F3AA2; Tue, 9 Dec 2003 01:05:42 -0500 (EST) Received: from PCSPOO (brow2115.research.att.com [135.207.58.115]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id hB965mZ16005; Tue, 9 Dec 2003 01:05:48 -0500 (EST) From: "Robert E. Gruber" To: , Date: Tue, 9 Dec 2003 01:06:49 -0500 Message-ID: <002d01c3be1a$a2e464d0$733acf87@PCSPOO> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Cc: gruber@research.att.com Subject: [omniNotify] omniNotify 2.0 ready for tagging? X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2003 06:05:50 -0000 Has anyone had any problems with the latest omniNotify2_develop branch, or does anyone know of build fixes that should be incorporated? Thanks, -- Bob From frederic.prin@silvaco.com Tue Dec 09 09:26:37 2003 Received: from portal.silvaco.com ([192.73.228.4]) by apasphere.com with esmtp (Exim 4.14) id 1ATe8b-00058z-CM; Tue, 09 Dec 2003 09:26:37 +0000 Received: from sbay.silvaco.com (sbay.Silvaco.COM [10.1.5.1]) by portal.silvaco.com (8.11.6+Sun/8.11.6) with ESMTP id hB99QXW07544; Tue, 9 Dec 2003 01:26:33 -0800 (PST) Received: from grenoble.silvaco.com (grenoble [10.66.5.1]) by sbay.silvaco.com (8.9.3+Sun/8.9.3) with ESMTP id BAA25223; Tue, 9 Dec 2003 01:26:32 -0800 (PST) Received: from bargy (bargy [10.66.10.24]) by grenoble.silvaco.com (8.9.1b+Sun/8.9.1) with SMTP id KAA11545; Tue, 9 Dec 2003 10:26:30 +0100 (MET) Message-ID: <134a01c3be36$8a6c2340$180a420a@bargy> From: "FredP" To: "Robert E. Gruber" , , References: <002d01c3be1a$a2e464d0$733acf87@PCSPOO> Date: Tue, 9 Dec 2003 10:26:34 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_1347_01C3BE3E.EB8E30C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: gruber@research.att.com Subject: [omniNotify] Re: [omniORB] omniNotify 2.0 ready for tagging? X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list Reply-To: FredP List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2003 09:26:37 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_1347_01C3BE3E.EB8E30C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by portal.silvaco.com id hB99QXW07544 Hi, Are you interrested by a patch for Solaris 5.8 64bit with CC: Sun WorkSho= p 6 update 1 C++ 5.2 2000/09/11 ? If yes, the patch to apply is attached. It concerns longlong support. This is the configure command line I used: PATH=3D/site/local/programs/python-2.2.3/sparc-solaris2-64/bin:$PATH export PATH LD_LIBRARY_PATH=3D\ /site/local/programs/omniORB-4.0.1/sparc-solaris2-64/lib:\ $LD_LIBRARY_PATH export LD_LIBRARY_PATH PYTHONPATH=3D/site/local/programs/omniORB-4.0.1/sparc-solaris2-64/lib/pyt= hon/ export PYTHONPATH ./configure CC=3D"cc -g -xtarget=3Dultra -xarch=3Dv9 -DSOLARISSPARC64" \ CXX=3D"CC -g -xtarget=3Dultra -xarch=3Dv9 -DSOLARISSPARC64" \ LD=3D"CC -g -xtarget=3Dultra -xarch=3Dv9 -DSOLARISSPARC64" \ PYTHON=3D/site/local/programs/python-2.2.3/sparc-solaris2-64/bin/python \ --prefix=3D/site/local/programs/omniNotify-2.0.0/sparc-solaris2-64/ --with-omniorb=3D/home/fredp/local/omniORB/omniORB-4.0.1-sparc-solaris2-6= 4/ make make install ------------------------------------------------------------ Fr=E9d=E9ric Prin Software Engineer Silvaco G.RE.CE ----- Original Message ----- From: "Robert E. Gruber" To: ; Cc: Sent: Tuesday, December 09, 2003 7:06 AM Subject: [omniORB] omniNotify 2.0 ready for tagging? > Has anyone had any problems with the latest omniNotify2_develop branch, > or does anyone know of build fixes that should be incorporated? > > Thanks, > -- Bob > > > > _______________________________________________ > omniORB-list mailing list > omniORB-list@omniorb-support.com > http://www.omniorb-support.com/mailman/listinfo/omniorb-list ------=_NextPart_000_1347_01C3BE3E.EB8E30C0 Content-Type: application/octet-stream; name="sparc-solaris-64-bit.patch" Content-Disposition: attachment; filename="sparc-solaris-64-bit.patch" Content-Transfer-Encoding: quoted-printable diff -ur omniNotify.orig/include/RDITimeWrappers.h = omniNotify/include/RDITimeWrappers.h=0A= --- omniNotify.orig/include/RDITimeWrappers.h 2003-07-03 = 14:01:25.000000000 +0000=0A= +++ omniNotify/include/RDITimeWrappers.h 2003-12-05 19:54:06.000000000 = +0000=0A= @@ -252,7 +252,8 @@=0A= }=0A= // pretty-printing of absolute local time -- no newline=0A= void out_local(RDIstrstream& str) {=0A= - CORBA::ULong ts, tn;=0A= + //CORBA::ULong ts, tn;=0A= + unsigned long ts, tn;=0A= get_posixbase_secs_nanosecs(ts, tn);=0A= RDI_posixbase_out_time(str, ts, tn);=0A= str << " (local time)";=0A= @@ -409,7 +410,8 @@=0A= }=0A= // pretty-printing of absolute univ time -- no newline=0A= void out_gmt(RDIstrstream& str) {=0A= - CORBA::ULong ts, tn;=0A= + //CORBA::ULong ts, tn;=0A= + unsigned long ts, tn;=0A= get_gmt_posixbase_secs_nanosecs(ts, tn);=0A= RDI_posixbase_out_time(str, ts, tn);=0A= str << " (greenwich mean time)";=0A= diff -ur omniNotify.orig/include/RDIstrstream.h = omniNotify/include/RDIstrstream.h=0A= --- omniNotify.orig/include/RDIstrstream.h 2003-07-03 14:01:25.000000000 = +0000=0A= +++ omniNotify/include/RDIstrstream.h 2003-12-05 19:30:00.000000000 +0000=0A= @@ -61,6 +61,9 @@=0A= RDIstrstream& operator<<(unsigned long n);=0A= RDIstrstream& operator<<(short n) {return operator<<((int)n);}=0A= RDIstrstream& operator<<(unsigned short n) {return = operator<<((unsigned int)n);}=0A= +#ifdef SOLARISSPARC64=0A= +#undef HAS_LongLong // only required on 64-bit Sparc/Solaris=0A= +#endif=0A= #ifdef HAS_LongLong=0A= RDIstrstream& operator<<(WRAPPED_CORBA_LONGLONG_TYPE n);=0A= RDIstrstream& operator<<(WRAPPED_CORBA_ULONGLONG_TYPE n);=0A= ------=_NextPart_000_1347_01C3BE3E.EB8E30C0-- From markzimm@io.frii.com Tue Dec 09 16:27:01 2003 Received: from io.frii.com ([216.17.222.1]) by apasphere.com with esmtp (Exim 4.14) id 1ATkhQ-0006Mf-OR for omninotify-list@omniorb-support.com; Tue, 09 Dec 2003 16:27:00 +0000 Received: from io.frii.com (localhost.frii.com [127.0.0.1]) by io.frii.com (8.12.10/8.12.10) with ESMTP id hB9GQxXn015500 for ; Tue, 9 Dec 2003 09:26:59 -0700 (MST) Received: (from markzimm@localhost) by io.frii.com (8.12.10/8.12.10/Submit) id hB9GQxI9015499 for omninotify-list@omniorb-support.com; Tue, 9 Dec 2003 09:26:59 -0700 (MST) Date: Tue, 9 Dec 2003 09:26:59 -0700 From: Mark Zimmerman To: omninotify-list@omniorb-support.com Subject: Re: [omniNotify] omniNotify 2.0 ready for tagging? Message-ID: <20031209162659.GA14982@io.frii.com> References: <002d01c3be1a$a2e464d0$733acf87@PCSPOO> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002d01c3be1a$a2e464d0$733acf87@PCSPOO> User-Agent: Mutt/1.4.1i X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2003 16:27:01 -0000 On Tue, Dec 09, 2003 at 01:06:49AM -0500, Robert E. Gruber wrote: > Has anyone had any problems with the latest omniNotify2_develop branch, > or does anyone know of build fixes that should be incorporated? > Barring any known breakage, I would like to see a baseline version declared so that we all have a known point from which to work. Small deviations to support special circumstances ought to be deferred to a 2.0.1 release. I appreciate your efforts to make it perfect and to address everyone's concerns, but that may never happen. Just my 2 cents worth... -- Mark From Cameron.Rochester@Ripple-Systems.com Wed Dec 10 00:29:00 2003 Received: from [203.17.161.11] (helo=webmailme.motherwell.com.au) by apasphere.com with smtp (Exim 4.14) id 1ATsDs-0006tH-3U for omninotify-list@omniorb-support.com; Wed, 10 Dec 2003 00:29:00 +0000 Received: (qmail 20646 invoked by uid 1010); 10 Dec 2003 00:28:24 -0000 Received: from Cameron.Rochester@Ripple-Systems.com by webmailme by uid 1004 with qmail-scanner-1.20 (uvscan: v4.1.60/v4307. Clear:RC:1(192.168.70.14):. Processed in 0.06693 secs); 10 Dec 2003 00:28:24 -0000 Received: from unknown (HELO envelope.pth.motherwell.com.au) (192.168.70.14) by webmailme.motherwell.com.au with SMTP; 10 Dec 2003 00:28:24 -0000 Received: by envelope.pth.motherwell.com.au with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Dec 2003 08:28:23 +0800 Message-ID: From: Cameron Rochester To: "'Robert E. Gruber'" , omninotify-list@omniorb-support.com Subject: RE: [omniNotify] omniNotify 2.0 ready for tagging? Date: Wed, 10 Dec 2003 08:28:22 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2003 00:29:00 -0000 Bob, Everything seems to be running quite well. I have integrated the latest development Notify service into our test and demo environments and it seems to be substantially more stable than 2.0Alpha. I have not seen a recurrence of the deadlock that you rectified in the latest release. As for building - we have built successfully on Solaris (gcc 3.2.2), Win32 (VC++ 6), and Redhat 9 (gcc 3.2.2). Regards Cameron -----Original Message----- From: Robert E. Gruber [mailto:gruber@research.att.com] Sent: Tuesday, 9 December 2003 2:07 PM To: omniorb-list@omniorb-support.com; omninotify-list@omniorb-support.com Cc: gruber@research.att.com Subject: [omniNotify] omniNotify 2.0 ready for tagging? Has anyone had any problems with the latest omniNotify2_develop branch, or does anyone know of build fixes that should be incorporated? Thanks, -- Bob _______________________________________________ omninotify-list mailing list omninotify-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omninotify-list From Cameron.Rochester@Ripple-Systems.com Wed Dec 17 05:53:47 2003 Received: from [203.17.161.11] (helo=webmailme.motherwell.com.au) by apasphere.com with smtp (Exim 4.14) id 1AWUd0-0004e9-HK for omninotify-list@omniorb-support.com; Wed, 17 Dec 2003 05:53:47 +0000 Received: (qmail 32238 invoked by uid 1010); 17 Dec 2003 05:53:10 -0000 Received: from Cameron.Rochester@Ripple-Systems.com by webmailme by uid 1004 with qmail-scanner-1.20 (uvscan: v4.1.60/v4308. Clear:RC:1(192.168.70.14):. Processed in 0.072937 secs); 17 Dec 2003 05:53:10 -0000 Received: from unknown (HELO envelope.pth.motherwell.com.au) (192.168.70.14) by webmailme.motherwell.com.au with SMTP; 17 Dec 2003 05:53:10 -0000 Received: by envelope.pth.motherwell.com.au with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Dec 2003 13:53:10 +0800 Message-ID: From: Cameron Rochester To: "'Robert E. Gruber'" , omninotify-list@omniorb-support.com Subject: RE: [omniNotify] omniNotify 2.0 ready for tagging? Date: Wed, 17 Dec 2003 13:53:06 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2003 05:53:47 -0000 Bob, I had problems building the latest omniNotify2_develop snapshot (as of 8/12/03) on Win32. It would seem that all the GNUMakefile's have been left out of the snapshot (they were in Duncan's original snapshot, released before your fixes to the deadlock issue). I copied the GNUMakefile's from the old snapshot into the necessary folders of the later snapshot and it builds fine. I am not sure if the Makefiles were missed from the snapshot or they have been lost along the way. It isn't a big deal, just took me a little while to figure out what was wrong ;) Cheers Cameron -----Original Message----- From: Robert E. Gruber [mailto:gruber@research.att.com] Sent: Tuesday, 9 December 2003 2:07 PM To: omniorb-list@omniorb-support.com; omninotify-list@omniorb-support.com Cc: gruber@research.att.com Subject: [omniNotify] omniNotify 2.0 ready for tagging? Has anyone had any problems with the latest omniNotify2_develop branch, or does anyone know of build fixes that should be incorporated? Thanks, -- Bob _______________________________________________ omninotify-list mailing list omninotify-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omninotify-list From Cameron.Rochester@Ripple-Systems.com Fri Dec 19 01:06:16 2003 Received: from [203.17.161.11] (helo=webmailme.motherwell.com.au) by apasphere.com with smtp (Exim 4.14) id 1AX95r-0006SX-CV for omninotify-list@omniorb-support.com; Fri, 19 Dec 2003 01:06:15 +0000 Received: (qmail 29126 invoked by uid 1010); 19 Dec 2003 01:05:39 -0000 Received: from Cameron.Rochester@Ripple-Systems.com by webmailme by uid 1004 with qmail-scanner-1.20 (uvscan: v4.1.60/v4309. Clear:RC:1(192.168.70.14):. Processed in 0.063798 secs); 19 Dec 2003 01:05:39 -0000 Received: from unknown (HELO envelope.pth.motherwell.com.au) (192.168.70.14) by webmailme.motherwell.com.au with SMTP; 19 Dec 2003 01:05:39 -0000 Received: by envelope.pth.motherwell.com.au with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Dec 2003 09:05:39 +0800 Message-ID: From: Cameron Rochester To: omninotify-list@omniorb-support.com Subject: [omniNotify] Consumer failure handling? Date: Fri, 19 Dec 2003 09:05:38 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2003 01:06:16 -0000 Hi all, If the NotificationService fails to push an event to a StructuredPushConsumer for any reason (say a TRANSIENT) will it automatically assume that the consumer is no longer valid and clean up? Or will it retry the event a couple of times before giving up and flagging the consumer offline? I ask this because we are seeing consumers occassionally stop receiving new events. This behaviour is obvious as we run multiple instances of an application, on the same workstation, that all subscribe identically. Occasionally we will observe that one of these applications will stop receiving new events while the others will continue quite happily. Very strange behaviour, and very difficult to debug. Thanks Cameron From gruber@research.att.com Fri Dec 19 17:57:44 2003 Received: from mail-dark.research.att.com ([192.20.225.112]) by apasphere.com with esmtp (Exim 4.14) id 1AXOsi-0007Xp-0w for omninotify-list@omniorb-support.com; Fri, 19 Dec 2003 17:57:44 +0000 Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by mail-dark.research.att.com (Postfix) with ESMTP id 57B29E80CF; Fri, 19 Dec 2003 12:59:09 -0500 (EST) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 66B3EF3AB0; Fri, 19 Dec 2003 12:56:00 -0500 (EST) Received: from pcgruber (pc-gruber.research.att.com [135.207.23.156]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id hBJHvgZ10199; Fri, 19 Dec 2003 12:57:43 -0500 (EST) From: "Robert E. Gruber" To: "'Cameron Rochester'" , Subject: RE: [omniNotify] Consumer failure handling? Date: Fri, 19 Dec 2003 12:56:53 -0500 Message-ID: <01c301c3c659$7d24d260$9c17cf87@pcgruber> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Cc: X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2003 17:57:44 -0000 Cameron, you are exactly right, a communication failure causes the channel to 'give up' on a consumer. There are two modes for connection reliability, 'best effort' and 'persistent', where omniNotify does not support the persistent option. It is possible that the current implementation of best effort delivery gives up too soon... I could look at making it try a certain number of additional times before 'giving up.' However, I will be traveling until January 2nd, so I will need to wait until then to look at it. Happy holidays everyone! -- Bob -----Original Message----- From: omninotify-list-bounces@omniorb-support.com [mailto:omninotify-list-bounces@omniorb-support.com] On Behalf Of Cameron Rochester Sent: Thursday, December 18, 2003 8:06 PM To: omninotify-list@omniorb-support.com Subject: [omniNotify] Consumer failure handling? Hi all, If the NotificationService fails to push an event to a StructuredPushConsumer for any reason (say a TRANSIENT) will it automatically assume that the consumer is no longer valid and clean up? Or will it retry the event a couple of times before giving up and flagging the consumer offline? I ask this because we are seeing consumers occassionally stop receiving new events. This behaviour is obvious as we run multiple instances of an application, on the same workstation, that all subscribe identically. Occasionally we will observe that one of these applications will stop receiving new events while the others will continue quite happily. Very strange behaviour, and very difficult to debug. Thanks Cameron _______________________________________________ omninotify-list mailing list omninotify-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omninotify-list From frederic.prin@silvaco.com Fri Jan 16 09:58:05 2004 Received: from portal.silvaco.com ([192.73.228.4]) by apasphere.com with esmtp (Exim 4.14) id 1AhQjr-0002Ff-To; Fri, 16 Jan 2004 09:58:04 +0000 Received: from sbay.silvaco.com (sbay.Silvaco.COM [10.1.5.1]) by portal.silvaco.com (8.11.6+Sun/8.11.6) with ESMTP id i0G9w1W01603; Fri, 16 Jan 2004 01:58:01 -0800 (PST) Received: from grenoble.silvaco.com (grenoble [10.66.5.1]) by sbay.silvaco.com (8.9.3+Sun/8.9.3) with ESMTP id BAA17149; Fri, 16 Jan 2004 01:57:59 -0800 (PST) Received: from parrachee (parrachee [10.66.10.32]) by grenoble.silvaco.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA28432; Fri, 16 Jan 2004 10:57:57 +0100 (MET) From: "Frederic Prin" To: , Date: Fri, 16 Jan 2004 10:56:12 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005E_01C3DC1F.5B50BA60" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: Subject: [omniNotify] Which omniORB works well with omniNotify ? X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 09:58:05 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_005E_01C3DC1F.5B50BA60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all, I was using omniORB-4.0.1 on (Linux RH7.1, RH9, Solaris 5.8- 32 and 64 bits, HPUX11, NT4, W2k) With omniNotify 2.0.ALPHA . It works well together for all platforms except for Windows. Notifd.exe crash when the EventChannel is narrowed. ( CORBA::Object_var channel_obj =3D init_naming_context->resolve( event_channel_name ) ; event_channel =3D CosNotifyChannelAdmin::EventChannel::_narrow( channel_obj ) ;) <<<< throw exception and crash notifd ) I read on the omniNotify web site that omniNotify 2.0 alpha may not compile or run properly with omniORB-4.0.1. I am in the process of upgrading omniORB to 4.0.3. What version of omniNotify do you preconize to use with omniORB-4.0.3. Thanks for your help Fred ( Fr=E9d=E9ric Prin ) Senior Software Engineer / S I L V A C O ( Grenoble REsearch CEnter \ Tel 04 56 38 10 33 ) __________________________/___ /__/__/__/__/__/__/__/__/__/__/ /__/__/__/__/__/__/__/__/_____/ /__/__/__/__/__/__/__/__/__/__/ ------=_NextPart_000_005E_01C3DC1F.5B50BA60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Which omniORB works well with omniNotify ?

Hello all,

I was using omniORB-4.0.1 on (Linux = RH7.1, RH9, Solaris 5.8- 32 and 64 bits, HPUX11, NT4, W2k)
With omniNotify = 2.0.ALPHA .

It works well = together for all platforms except for Windows. Notifd.exe crash when the = EventChannel is narrowed.
(
        = CORBA::Object_var channel_obj =3D = init_naming_context->resolve( event_channel_name ) ;
        = event_channel =3D = CosNotifyChannelAdmin::EventChannel::_narrow( channel_obj ) ;) = <<<< throw exception and crash notifd

)

I read on the = omniNotify web site that omniNotify 2.0 alpha may not compile or run = properly with omniORB-4.0.1.

I am in the = process of upgrading omniORB to 4.0.3.

What version of = omniNotify do you preconize to use with omniORB-4.0.3.

Thanks for your = help

Fred

           &n= bsp;           &nb= sp;      (
     Fr=E9d=E9ric Prin          = )
     Senior Software Engineer /
          S I L V A C = O      (
     Grenoble REsearch CEnter \
     Tel 04 56 38 10 = 33        )
    __________________________/___
   /__/__/__/__/__/__/__/__/__/__/
  = /__/__/__/__/__/__/__/__/_____/
 /__/__/__/__/__/__/__/__/__/__/

------=_NextPart_000_005E_01C3DC1F.5B50BA60-- From renej.frog@yucom.be Fri Jan 16 10:15:36 2004 Received: from elpis.telenet-ops.be ([195.130.132.40]) by apasphere.com with esmtp (Exim 4.14) id 1AhR0q-0002OQ-S4; Fri, 16 Jan 2004 10:15:36 +0000 Received: from localhost (apate.telenet-ops.be [195.130.132.57]) by elpis.telenet-ops.be (Postfix) with SMTP id 70FE637FA1; Fri, 16 Jan 2004 11:15:36 +0100 (MET) Received: from fnsnb40.jati.lan (d5153153F.kabel.telenet.be [81.83.21.63]) by apate.telenet-ops.be (Postfix) with ESMTP id 0F34037E49; Fri, 16 Jan 2004 11:15:36 +0100 (MET) From: Rene Jager To: Frederic Prin In-Reply-To: References: Content-Type: text/plain Message-Id: <1074248135.2785.40.camel@fnsnb40.jati.lan> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 16 Jan 2004 11:15:35 +0100 Content-Transfer-Encoding: 7bit Cc: omniorb-list@omniorb-support.com, omninotify-list@omniorb-support.com Subject: [omniNotify] Re: [omniORB] Which omniORB works well with omniNotify ? X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 10:15:36 -0000 On Fri, 2004-01-16 at 10:56, Frederic Prin wrote: > Hello all, > > I was using omniORB-4.0.1 on (Linux RH7.1, RH9, Solaris 5.8- 32 and 64 > bits, HPUX11, NT4, W2k) > With omniNotify 2.0.ALPHA . > > It works well together for all platforms except for Windows. > Notifd.exe crash when the EventChannel is narrowed. > ( > CORBA::Object_var channel_obj = init_naming_context->resolve( > event_channel_name ) ; > event_channel = CosNotifyChannelAdmin::EventChannel::_narrow( > channel_obj ) ;) <<<< throw exception and crash notifd > > ) > > I read on the omniNotify web site that omniNotify 2.0 alpha may not > compile or run properly with omniORB-4.0.1. > > I am in the process of upgrading omniORB to 4.0.3. > > What version of omniNotify do you preconize to use with omniORB-4.0.3. I'm using omniORB 4.0.3 with the latest omniNotify version: http://omniorb.sourceforge.net/snapshots/omniNotify-2-latest.tar.gz at the moment I use the latest of a month ago I guess and that works ok renej From frederic.prin@silvaco.com Fri Jan 16 10:35:22 2004 Received: from portal.silvaco.com ([192.73.228.4]) by apasphere.com with esmtp (Exim 4.14) id 1AhRJx-0002Xr-Lu; Fri, 16 Jan 2004 10:35:21 +0000 Received: from sbay.silvaco.com (sbay.Silvaco.COM [10.1.5.1]) by portal.silvaco.com (8.11.6+Sun/8.11.6) with ESMTP id i0GAZJW06898; Fri, 16 Jan 2004 02:35:19 -0800 (PST) Received: from grenoble.silvaco.com (grenoble [10.66.5.1]) by sbay.silvaco.com (8.9.3+Sun/8.9.3) with ESMTP id CAA19562; Fri, 16 Jan 2004 02:35:18 -0800 (PST) Received: from parrachee (parrachee [10.66.10.32]) by grenoble.silvaco.com (8.9.1b+Sun/8.9.1) with ESMTP id LAA06048; Fri, 16 Jan 2004 11:35:13 +0100 (MET) From: "Frederic Prin" To: "'Rene Jager'" Date: Fri, 16 Jan 2004 11:33:27 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <1074248135.2785.40.camel@fnsnb40.jati.lan> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: omniorb-list@omniorb-support.com, omninotify-list@omniorb-support.com Subject: [omniNotify] RE: [omniORB] Which omniORB works well with omniNotify ? X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 10:35:22 -0000 Do it work for windows too ? For windows, do you used precompiled version or do you recompile all ? What is your windows compiler: (mine is MSVC++6.0) Thanks Rene for replying. -----Original Message----- From: omniorb-list-bounces@omniorb-support.com [mailto:omniorb-list-bounces@omniorb-support.com] On Behalf Of Rene Jager Sent: vendredi 16 janvier 2004 11:16 To: Frederic Prin Cc: omniorb-list@omniorb-support.com; omninotify-list@omniorb-support.com Subject: Re: [omniORB] Which omniORB works well with omniNotify ? On Fri, 2004-01-16 at 10:56, Frederic Prin wrote: > Hello all, > > I was using omniORB-4.0.1 on (Linux RH7.1, RH9, Solaris 5.8- 32 and 64 > bits, HPUX11, NT4, W2k) With omniNotify 2.0.ALPHA . > > It works well together for all platforms except for Windows. > Notifd.exe crash when the EventChannel is narrowed. ( > CORBA::Object_var channel_obj = init_naming_context->resolve( > event_channel_name ) ; > event_channel = CosNotifyChannelAdmin::EventChannel::_narrow( > channel_obj ) ;) <<<< throw exception and crash notifd > > ) > > I read on the omniNotify web site that omniNotify 2.0 alpha may not > compile or run properly with omniORB-4.0.1. > > I am in the process of upgrading omniORB to 4.0.3. > > What version of omniNotify do you preconize to use with omniORB-4.0.3. I'm using omniORB 4.0.3 with the latest omniNotify version: http://omniorb.sourceforge.net/snapshots/omniNotify-2-latest.tar.gz at the moment I use the latest of a month ago I guess and that works ok renej _______________________________________________ omniORB-list mailing list omniORB-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omniorb-list From renej.frog@yucom.be Fri Jan 16 10:51:58 2004 Received: from elpis.telenet-ops.be ([195.130.132.40]) by apasphere.com with esmtp (Exim 4.14) id 1AhRa2-0002h4-MR; Fri, 16 Jan 2004 10:51:58 +0000 Received: from localhost (apate.telenet-ops.be [195.130.132.57]) by elpis.telenet-ops.be (Postfix) with SMTP id 77F94381FA; Fri, 16 Jan 2004 11:51:58 +0100 (MET) Received: from fnsnb40.jati.lan (d5153153F.kabel.telenet.be [81.83.21.63]) by apate.telenet-ops.be (Postfix) with ESMTP id E9E4D37EA3; Fri, 16 Jan 2004 11:51:57 +0100 (MET) From: Rene Jager To: Frederic Prin In-Reply-To: References: Content-Type: text/plain Message-Id: <1074250317.2785.62.camel@fnsnb40.jati.lan> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 16 Jan 2004 11:51:57 +0100 Content-Transfer-Encoding: 7bit Cc: omniorb-list@omniorb-support.com, omninotify-list@omniorb-support.com Subject: [omniNotify] RE: [omniORB] Which omniORB works well with omniNotify ? X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 10:51:58 -0000 On Fri, 2004-01-16 at 11:33, Frederic Prin wrote: > Do it work for windows too ? sorry, I should have paid more attention; I'm so into linux... ;-) so I don't know actually... > > For windows, do you used precompiled version or do you recompile all ? > What is your windows compiler: (mine is MSVC++6.0) > > Thanks Rene for replying. but it didn't was of any help, sorry again hwoever, the good news is in the file update.log: ------------------------------------------------- Thu Jun 19 17:23:28 BST 2003 dgrisby ==================================== - Windows port. ------------------------------------------------- which is after the alpha release, so I would give it a try renej > On Fri, 2004-01-16 at 10:56, Frederic Prin wrote: > > Hello all, > > > > I was using omniORB-4.0.1 on (Linux RH7.1, RH9, Solaris 5.8- 32 and 64 > > > bits, HPUX11, NT4, W2k) With omniNotify 2.0.ALPHA . > > > > It works well together for all platforms except for Windows. > > Notifd.exe crash when the EventChannel is narrowed. ( > > CORBA::Object_var channel_obj = init_naming_context->resolve( > > event_channel_name ) ; > > event_channel = CosNotifyChannelAdmin::EventChannel::_narrow( > > channel_obj ) ;) <<<< throw exception and crash notifd > > > > ) > > > > I read on the omniNotify web site that omniNotify 2.0 alpha may not > > compile or run properly with omniORB-4.0.1. > > > > I am in the process of upgrading omniORB to 4.0.3. > > > > What version of omniNotify do you preconize to use with omniORB-4.0.3. > > I'm using omniORB 4.0.3 with the latest omniNotify version: > http://omniorb.sourceforge.net/snapshots/omniNotify-2-latest.tar.gz > > at the moment I use the latest of a month ago I guess and that works ok > > renej From duncan@grisby.org Fri Jan 16 11:12:40 2004 Received: from cpc1-cmbg4-5-0-cust104.cmbg.cable.ntl.com ([81.96.72.104] helo=grisby.dyndns.org) by apasphere.com with esmtp (Exim 4.14) id 1AhRu3-0002qS-Mj; Fri, 16 Jan 2004 11:12:39 +0000 Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id i0GBCcH09426; Fri, 16 Jan 2004 11:12:39 GMT Message-Id: <200401161112.i0GBCcH09426@grisby.dyndns.org> X-Authentication-Warning: cpc1-cmbg4-5-0-cust104.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: "Frederic Prin" Subject: Re: [omniNotify] Which omniORB works well with omniNotify ? In-Reply-To: Message from "Frederic Prin" of "Fri, 16 Jan 2004 10:56:12 +0100." From: Duncan Grisby Date: Fri, 16 Jan 2004 11:12:38 +0000 Cc: omniorb-list@omniorb-support.com, omninotify-list@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 11:12:40 -0000 On Friday 16 January, "Frederic Prin" wrote: > I read on the omniNotify web site that omniNotify 2.0 alpha may not > compile or run properly with omniORB-4.0.1. For Windows, you need at least omniORB 4.0.2, since there were some fixes to DLL issues that omniNotify required. > I am in the process of upgrading omniORB to 4.0.3. Once you have, it should work fine. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From sturm@rtfs.org Sat Jan 17 05:54:48 2004 Received: from [141.39.181.136] (helo=xenon.rtfs.org ident=postfix) by apasphere.com with esmtp (Exim 4.14) id 1AhjQ0-0003Xy-A6 for omninotify-list@omniorb-support.com; Sat, 17 Jan 2004 05:54:48 +0000 Received: by xenon.rtfs.org (Postfix, from userid 1000) id 5BADCCADD0; Sat, 17 Jan 2004 06:55:23 +0100 (CET) Date: Sat, 17 Jan 2004 06:55:23 +0100 From: Fabian Sturm To: omninotify-list@omniorb-support.com Message-ID: <20040117055523.GA4162@xenon.rtfs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Subject: [omniNotify] compile problem of omninotify X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2004 05:54:48 -0000 Hi! I have a small compile problem for omninotify-2-latest. The situation is that I have omniORB installen in /use but want to install omniNotify in /usr/local. (Btw. this is on a gentoo linux x86 box) Therefore I do a mkdir build cd build ../configure --with-omniorb=/usr make Then I get: /usr/bin/omniidl -bcxx -Wba -Wbuse_quotes -I. -I../idl/COS -I../../idl/COS -I/usr/idl/COS -I. -I../src/services/omniNotify/idl -I../../src/services/omniNotify/idl -I/usr/src/services/omniNotify/idl -I /usr/local/share/idl/omniORB/COS ../../idl/AttNotification.idl ../../idl/AttNotification.idl:23: CosEventChannelAdmin.idl: No such file or directory . Obviously this fails because it has -I /usr/local/share/idl/omniORB/COS with the local part in it. So I tried to give it additional -I parameters but couldn't get it work. What is teh proper fix for this? Thanksa lot, Fabian P.s. i am not subscribed to this list so please cc me From frederic.prin@silvaco.com Mon Jan 19 14:07:07 2004 Received: from portal.silvaco.com ([192.73.228.4]) by apasphere.com with esmtp (Exim 4.14) id 1Aia3W-00073y-N5; Mon, 19 Jan 2004 14:07:06 +0000 Received: from sbay.silvaco.com (sbay.Silvaco.COM [10.1.5.1]) by portal.silvaco.com (8.11.6+Sun/8.11.6) with ESMTP id i0JE74W29846; Mon, 19 Jan 2004 06:07:04 -0800 (PST) Received: from grenoble.silvaco.com (grenoble [10.66.5.1]) by sbay.silvaco.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08615; Mon, 19 Jan 2004 06:07:03 -0800 (PST) Received: from parrachee (parrachee [10.66.10.32]) by grenoble.silvaco.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA18587; Mon, 19 Jan 2004 15:07:01 +0100 (MET) From: "Frederic Prin" To: , Date: Mon, 19 Jan 2004 15:05:19 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <200401161112.i0GBCcH09426@grisby.dyndns.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: Subject: [omniNotify] OmniORB 4.0.3 and Solaris SC6 64bits X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2004 14:07:07 -0000 Hi all, Is someone try to build omniORB-4.0.3 on Solaris 8 with SC6-64 bits compiler ? >CC -V CC: Sun WorkShop 6 update 1 C++ 5.2 2000/09/11 I get a core dump when compiling: gnumake[3]: Entering directory `/export/home/fredp_local/MyOmniORBBuilds/omniORB-4.0.3/omniORB-4.0.3/bu ild_SolarisSC6-64/src/lib/omniORB' ../../../bin/omniidl -bcxx -Wba -p../../../../src/lib/omniORB -Wbdebug -v -ComniORB4 ../../../../idl/Naming.idl omniidl: Importing back-end 'cxx' omniidl: 'cxx' imported from '../../../../src/lib/omniORB/omniidl_be/cxx/__init__.pyc' omniidl: Preprocessing '../../../../idl/Naming.idl' with '/export/home/fredp_local/MyOmniORBBuilds/omniORB-4.0.3/omniORB-4.0.3/bu ild_SolarisSC6-64/lib/omnicpp -lang-c++ -undef -D__OMNIIDL__=0x2420 -D__OMNIIDL_CXX__ "../../../../idl/Naming.idl"' omniidl: Running front end Segmentation Fault - core dumped omniidl: Error running preprocessor My configure commande line I use is: ../configure CC="cc -g -xtarget=ultra -xarch=v9 -DSOLARISSPARC64" CXX="CC -g -xtarget=ultra -xarch=v9 -DSOLARISSPARC64" LD="CC -g -xtarget=ultra -xarch=v9 -DSOLARISSPARC64" PYTHON=/site/local/programs/python-2.2.3/sparc-solaris2-64/bin/python --prefix=/export/home/fredp_local/MyOmniORBBuilds/omniORB-4.0.3/omniORB- 4.0.3/build_SolarisSC6-64/installDir --disable-thread-tracing It works with the default autoconf (32bits). Thanks for your help. -----Original Message----- From: omniorb-list-bounces@omniorb-support.com [mailto:omniorb-list-bounces@omniorb-support.com] On Behalf Of Duncan Grisby Sent: vendredi 16 janvier 2004 12:13 To: Frederic Prin Cc: omniorb-list@omniorb-support.com; omninotify-list@omniorb-support.com Subject: [omniORB] Re: [omniNotify] Which omniORB works well with omniNotify? On Friday 16 January, "Frederic Prin" wrote: > I read on the omniNotify web site that omniNotify 2.0 alpha may not > compile or run properly with omniORB-4.0.1. For Windows, you need at least omniORB 4.0.2, since there were some fixes to DLL issues that omniNotify required. > I am in the process of upgrading omniORB to 4.0.3. Once you have, it should work fine. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- _______________________________________________ omniORB-list mailing list omniORB-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omniorb-list From frederic.prin@silvaco.com Mon Jan 19 14:59:12 2004 Received: from portal.silvaco.com ([192.73.228.4]) by apasphere.com with esmtp (Exim 4.14) id 1Aiarw-0007Dd-2G; Mon, 19 Jan 2004 14:59:12 +0000 Received: from sbay.silvaco.com (sbay.Silvaco.COM [10.1.5.1]) by portal.silvaco.com (8.11.6+Sun/8.11.6) with ESMTP id i0JExAW00673; Mon, 19 Jan 2004 06:59:10 -0800 (PST) Received: from grenoble.silvaco.com (grenoble [10.66.5.1]) by sbay.silvaco.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11906; Mon, 19 Jan 2004 06:59:08 -0800 (PST) Received: from parrachee (parrachee [10.66.10.32]) by grenoble.silvaco.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA04000; Mon, 19 Jan 2004 15:59:07 +0100 (MET) From: "Frederic Prin" To: , Date: Mon, 19 Jan 2004 15:57:25 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: Subject: [omniNotify] OmniORB 4.0.3 and Solaris SC6 64bits (oops) X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2004 14:59:12 -0000 I forgot to tell that to achieve a successful build under Solaris 8 SC6 (32bits) I need to add CXX=CC on the configure commande line. -----Original Message----- From: omniorb-list-bounces@omniorb-support.com [mailto:omniorb-list-bounces@omniorb-support.com] On Behalf Of Frederic Prin Sent: lundi 19 janvier 2004 15:05 To: omniorb-list@omniorb-support.com; omninotify-list@omniorb-support.com Subject: [omniORB] OmniORB 4.0.3 and Solaris SC6 64bits Hi all, Is someone try to build omniORB-4.0.3 on Solaris 8 with SC6-64 bits compiler ? >CC -V CC: Sun WorkShop 6 update 1 C++ 5.2 2000/09/11 I get a core dump when compiling: gnumake[3]: Entering directory `/export/home/fredp_local/MyOmniORBBuilds/omniORB-4.0.3/omniORB-4.0.3/bu ild_SolarisSC6-64/src/lib/omniORB' ../../../bin/omniidl -bcxx -Wba -p../../../../src/lib/omniORB -Wbdebug -v -ComniORB4 ../../../../idl/Naming.idl omniidl: Importing back-end 'cxx' omniidl: 'cxx' imported from '../../../../src/lib/omniORB/omniidl_be/cxx/__init__.pyc' omniidl: Preprocessing '../../../../idl/Naming.idl' with '/export/home/fredp_local/MyOmniORBBuilds/omniORB-4.0.3/omniORB-4.0.3/bu ild_SolarisSC6-64/lib/omnicpp -lang-c++ -undef -D__OMNIIDL__=0x2420 -D__OMNIIDL_CXX__ "../../../../idl/Naming.idl"' omniidl: Running front end Segmentation Fault - core dumped omniidl: Error running preprocessor My configure commande line I use is: ../configure CC="cc -g -xtarget=ultra -xarch=v9 -DSOLARISSPARC64" CXX="CC -g -xtarget=ultra -xarch=v9 -DSOLARISSPARC64" LD="CC -g -xtarget=ultra -xarch=v9 -DSOLARISSPARC64" PYTHON=/site/local/programs/python-2.2.3/sparc-solaris2-64/bin/python --prefix=/export/home/fredp_local/MyOmniORBBuilds/omniORB-4.0.3/omniORB- 4.0.3/build_SolarisSC6-64/installDir --disable-thread-tracing It works with the default autoconf (32bits). Thanks for your help. -----Original Message----- From: omniorb-list-bounces@omniorb-support.com [mailto:omniorb-list-bounces@omniorb-support.com] On Behalf Of Duncan Grisby Sent: vendredi 16 janvier 2004 12:13 To: Frederic Prin Cc: omniorb-list@omniorb-support.com; omninotify-list@omniorb-support.com Subject: [omniORB] Re: [omniNotify] Which omniORB works well with omniNotify? On Friday 16 January, "Frederic Prin" wrote: > I read on the omniNotify web site that omniNotify 2.0 alpha may not > compile or run properly with omniORB-4.0.1. For Windows, you need at least omniORB 4.0.2, since there were some fixes to DLL issues that omniNotify required. > I am in the process of upgrading omniORB to 4.0.3. Once you have, it should work fine. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- _______________________________________________ omniORB-list mailing list omniORB-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omniorb-list _______________________________________________ omniORB-list mailing list omniORB-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omniorb-list From duncan@grisby.org Wed Jan 21 17:09:09 2004 Received: from cpc1-cmbg4-5-0-cust104.cmbg.cable.ntl.com ([81.96.72.104] helo=grisby.dyndns.org) by apasphere.com with esmtp (Exim 4.14) id 1AjLqn-00046D-2b; Wed, 21 Jan 2004 17:09:09 +0000 Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id i0LH98V10649; Wed, 21 Jan 2004 17:09:08 GMT Message-Id: <200401211709.i0LH98V10649@grisby.dyndns.org> X-Authentication-Warning: cpc1-cmbg4-5-0-cust104.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: "Frederic Prin" In-Reply-To: Message from "Frederic Prin" of "Mon, 19 Jan 2004 15:05:19 +0100." From: Duncan Grisby Date: Wed, 21 Jan 2004 17:09:07 +0000 Cc: omniorb-list@omniorb-support.com, omninotify-list@omniorb-support.com Subject: [omniNotify] Re: [omniORB] OmniORB 4.0.3 and Solaris SC6 64bits X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2004 17:09:09 -0000 On Monday 19 January, "Frederic Prin" wrote: > Is someone try to build omniORB-4.0.3 on Solaris 8 with SC6-64 bits > compiler ? [...] > omniidl: Running front end > Segmentation Fault - core dumped > omniidl: Error running preprocessor That looks like the GNU C preprocessor died. I don't know why, since it should work fine on a 64-bit machine, as long as the configure script correctly identified the word size. As a (horrible) work-around, you could build the preprocessor (and omniidl, for that matter) in 32 bit mode, and just the omniORB libraries and tools in 64 bit mode. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From taurel@esrf.fr Mon Jan 26 16:41:22 2004 Received: from firewall.esrf.fr ([193.49.43.1] helo=out.esrf.fr) by apasphere.com with esmtp (Exim 4.14) id 1Al9ne-0004hz-A2 for omninotify-list@omniorb-support.com; Mon, 26 Jan 2004 16:41:22 +0000 Received: (from uucp@localhost) by out.esrf.fr (1.0.0) id i0QGepM19867 for ; Mon, 26 Jan 2004 17:40:51 +0100 (MET) Received: from esrf.esrf.fr(160.103.2.9) by firewall via smap (V1.3) id tmp019857; Mon Jan 26 17:40:46 2004 Received: from esrf.fr (localhost [127.0.0.1]) by esrf.esrf.fr (8.9.0/8.9.0) with ESMTP id RAA26049 for ; Mon, 26 Jan 2004 17:40:45 +0100 (MET) Message-ID: <4015431C.593B6D6A@esrf.fr> Date: Mon, 26 Jan 2004 17:41:00 +0100 From: Emmanuel Taurel X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: omninotify-list@omniorb-support.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [omniNotify] Modulo in filetring constraint language X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2004 16:41:22 -0000 Hi all, I am using omniNotify and I want to filter some events. In my structured event, I have a filterable field in which I have a counter. This counter is incremented (by one) by the supplier each times it pushes the event to the notification service. My question is simple. How can I program the filter to receive the event only if "counter modulo n" is zero Thank's for your help Emmanuel Taurel (taurel@esrf.fr) From Cameron.Rochester@Ripple-Systems.com Wed Jan 28 09:22:02 2004 Received: from webmailme.motherwell.com.au ([203.17.161.11]) by apasphere.com with smtp (Exim 4.14) id 1Allta-00076Q-0G for omninotify-list@omniorb-support.com; Wed, 28 Jan 2004 09:22:02 +0000 Received: (qmail 2130 invoked by uid 1010); 28 Jan 2004 09:21:29 -0000 Received: from Cameron.Rochester@Ripple-Systems.com by webmailme by uid 1004 with qmail-scanner-1.20 (uvscan: v4.1.60/v4319. Clear:RC:1(192.168.70.14):. Processed in 0.0661929999999999 secs); 28 Jan 2004 09:21:29 -0000 Received: from unknown (HELO envelope.pth.motherwell.com.au) (192.168.70.14) by webmailme.motherwell.com.au with SMTP; 28 Jan 2004 09:21:28 -0000 Received: by ENVELOPE with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Jan 2004 17:21:28 +0800 Message-ID: From: Cameron Rochester To: "'omninotify-list@omniorb-support.com'" Subject: [omniNotify] Possible bug in event ordering when using EventBatch Date: Wed, 28 Jan 2004 17:21:24 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2004 09:22:02 -0000 Hi all, Just wondering if anyone has experienced events arriving out-of-sequence when using SequencePushConsumers/Suppliers Configuration: The OrderPolicy for the NotificationService is set to FifoOrder ( 1 ) in the channel.cfg file, this value is not overridden when creating proxies. I have a SequencePushSupplier supplying EventBatches of size 4 to the NotificationService. I have a SequencePushConsumer consuming EventBatches of size 4 from the NotificationService (pacing interval of 1000ms). The consumer & supplier are using the same channel, obviously. 100 StructuredEvents are sent at a time. Scenario: On the supplier side I add a sequence number to the variable_header field of each StructuredEvent. The sequence number is incremented as each StructuredEvent is added to the EventBatch. To verify the order of the EventBatch I iterate through the batch just before sending. When the SequencePushConsumer receives a batch I iterate through the EventBatch and print out the sequence numbers. 50% of the time the sequence numbers are jumbled in the received EventBatch. Most often the first two StructuredEvents are in order, but the last two are reversed, but often the Events will be 4 or 5 positions out of place. Now, If I limit the SequencePushSupplier to send EventBatches of size 1, and still have EventBatches of size 4 being pushed to the SequencePushConsumer, the order is correct. I realise that this points towards the SequencePushSupplier sending jumbled batches, but I have checked, double checked, printed, and verified the order of the batch just before calling push_structured_events() on the ProxyConsumer and it all seems fine. Can anyone else verify this behaviour? If so, this is a nasty bug when you are relying on the FifoOrder being correct. Regards Cameron Rochester From gruber@research.att.com Thu Jan 29 17:26:27 2004 Received: from mail-dark.research.att.com ([192.20.225.112]) by apasphere.com with esmtp (Exim 4.14) id 1AmFvv-0001Vw-Jq for omninotify-list@omniorb-support.com; Thu, 29 Jan 2004 17:26:27 +0000 Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by mail-dark.research.att.com (Postfix) with ESMTP id 6E571E816D; Thu, 29 Jan 2004 12:27:31 -0500 (EST) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id A9AB1F3AB0; Thu, 29 Jan 2004 12:21:45 -0500 (EST) Received: from pcgruber (pc-gruber.research.att.com [135.207.23.156]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id i0THQOZ08888; Thu, 29 Jan 2004 12:26:26 -0500 (EST) From: "Robert E. Gruber" To: "'Cameron Rochester'" , Subject: RE: [omniNotify] Possible bug in event ordering when using EventBatch Date: Thu, 29 Jan 2004 12:26:45 -0500 Message-ID: <016f01c3e68d$125a9790$9c17cf87@pcgruber> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Cc: gruber@research.att.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2004 17:26:27 -0000 I will take a look at this over the weekend. -- Bob -----Original Message----- From: omninotify-list-bounces@omniorb-support.com [mailto:omninotify-list-bounces@omniorb-support.com] On Behalf Of Cameron Rochester Sent: Wednesday, January 28, 2004 4:21 AM To: 'omninotify-list@omniorb-support.com' Subject: [omniNotify] Possible bug in event ordering when using EventBatch Hi all, Just wondering if anyone has experienced events arriving out-of-sequence when using SequencePushConsumers/Suppliers Configuration: The OrderPolicy for the NotificationService is set to FifoOrder ( 1 ) in the channel.cfg file, this value is not overridden when creating proxies. I have a SequencePushSupplier supplying EventBatches of size 4 to the NotificationService. I have a SequencePushConsumer consuming EventBatches of size 4 from the NotificationService (pacing interval of 1000ms). The consumer & supplier are using the same channel, obviously. 100 StructuredEvents are sent at a time. Scenario: On the supplier side I add a sequence number to the variable_header field of each StructuredEvent. The sequence number is incremented as each StructuredEvent is added to the EventBatch. To verify the order of the EventBatch I iterate through the batch just before sending. When the SequencePushConsumer receives a batch I iterate through the EventBatch and print out the sequence numbers. 50% of the time the sequence numbers are jumbled in the received EventBatch. Most often the first two StructuredEvents are in order, but the last two are reversed, but often the Events will be 4 or 5 positions out of place. Now, If I limit the SequencePushSupplier to send EventBatches of size 1, and still have EventBatches of size 4 being pushed to the SequencePushConsumer, the order is correct. I realise that this points towards the SequencePushSupplier sending jumbled batches, but I have checked, double checked, printed, and verified the order of the batch just before calling push_structured_events() on the ProxyConsumer and it all seems fine. Can anyone else verify this behaviour? If so, this is a nasty bug when you are relying on the FifoOrder being correct. Regards Cameron Rochester _______________________________________________ omninotify-list mailing list omninotify-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omninotify-list From gruber@research.att.com Thu Jan 29 17:32:45 2004 Received: from mail-dark.research.att.com ([192.20.225.112]) by apasphere.com with esmtp (Exim 4.14) id 1AmG21-0001YM-Bx for omninotify-list@omniorb-support.com; Thu, 29 Jan 2004 17:32:45 +0000 Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by mail-dark.research.att.com (Postfix) with ESMTP id 765DDE816E; Thu, 29 Jan 2004 12:33:49 -0500 (EST) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-green.research.att.com (Postfix) with ESMTP id CD474F3A91; Thu, 29 Jan 2004 12:30:09 -0500 (EST) Received: from pcgruber (pc-gruber.research.att.com [135.207.23.156]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id i0THWiZ10322; Thu, 29 Jan 2004 12:32:44 -0500 (EST) From: "Robert E. Gruber" To: "'Emmanuel Taurel'" , Subject: RE: [omniNotify] Modulo in filetring constraint language Date: Thu, 29 Jan 2004 12:33:04 -0500 Message-ID: <017101c3e68d$f37ba610$9c17cf87@pcgruber> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4015431C.593B6D6A@esrf.fr> Importance: Normal Cc: gruber@research.att.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2004 17:32:45 -0000 Although it is not part of the standard, I believe that I put a modulo (%) operator into omniNotify's filter evaluation code. So you could write it directly, but it would not port to other implementations of the notification service. -- Bob -----Original Message----- From: omninotify-list-bounces@omniorb-support.com [mailto:omninotify-list-bounces@omniorb-support.com] On Behalf Of Emmanuel Taurel Sent: Monday, January 26, 2004 11:41 AM To: omninotify-list@omniorb-support.com Subject: [omniNotify] Modulo in filetring constraint language Hi all, I am using omniNotify and I want to filter some events. In my structured event, I have a filterable field in which I have a counter. This counter is incremented (by one) by the supplier each times it pushes the event to the notification service. My question is simple. How can I program the filter to receive the event only if "counter modulo n" is zero Thank's for your help Emmanuel Taurel (taurel@esrf.fr) _______________________________________________ omninotify-list mailing list omninotify-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omninotify-list From worldnetlotto@netscape.net Fri Feb 06 14:03:48 2004 Received: from realvnc.com ([213.239.45.162]) by apasphere.com with esmtp (Exim 4.14) id 1Ap6aC-0001Ir-4Y for omninotify-list@www.omniorb-support.com; Fri, 06 Feb 2004 14:03:48 +0000 Received: from netscape774.com (82-168-100-42-bbxl.xdsl.tiscali.nl [82.168.100.42]) by realvnc.com (8.11.6/8.11.6) with SMTP id i16E3Zf09173 for ; Fri, 6 Feb 2004 14:03:36 GMT Message-Id: <200402061403.i16E3Zf09173@realvnc.com> From: MRS CAROL HINGES To: omninotify-list@realvnc.com Date: Fri, 06 Feb 2004 14:57:13 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="bc8a22d5-a35e-4d8d-b64b-8545e3ec4602" Cc: Subject: [omniNotify] CONGRATULATION / YOU HAVE WON. X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list Reply-To: worldnetlotto@netscape.net List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2004 14:03:48 -0000 This is a multi-part message in MIME format --bc8a22d5-a35e-4d8d-b64b-8545e3ec4602 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Ref. Nnumbe: YK-958/756/0486 Batch Number: 79VD-381527-59 Sir/Madam We are pleased to inform you of the result of the Lottery Winners International programs held on the 5th of feb, 2004. Your e-mail address attached to ticket number 8224765896-642 with serial number 2917-477 = drew lucky numbers 66-14-08-23-33-33 which consequently won in the 2nd = category, you have therefore been approved for a lump sum pay out of US$ 500,000.00 = (Five Hundred Thousand United States Dollars) CONGRATULATIONS!!! Due to mix up of some numbers and names, we ask that you keep your winning information confidential until your claims has been processed and = your money. Remitted to you. This is part of our security protocol to avoid double claiming and unwarranted abuse of this program by some participants. All participants were selected through a computer ballot system drawn from over 19,000 company and 28,000,000 individual email addresses and names = from all over the world. This promotional program takes place every three = year. This lottery was promoted and sponsored by Bill Gates, President of the World Largest software, we hope with part of your winning you will take part in our next year USD50 million international lottery. To file for your claim, please contact our finacial agent. MR.JONSE BENSON of the,GOLD SMITH FINANCE AGENCY BV. NETHERLAND. TEL:0031-627-201-143. FAX:0031-624-433-548. goldsmithfinance@netscape.net Remember, all winning must be claimed not later than 24th of feb. 2004. After this date all unclaimed funds will be included in the next stake. = Please note in order to avoid unnecessary delays and complications please remember to quote your reference number and batch numbers in all correspondence. Furthermore, should there be any change of address do inform our agent as soon as possible. Congratulations once more from our members of staff and thank you for being part of our promotional program. Note: Anybody under the age of 18 is automatically disqualified. Sincerely yours, Mrs Carol Hinges Lottery Coordinator. --bc8a22d5-a35e-4d8d-b64b-8545e3ec4602-- From skmrao@yahoo.com Mon Feb 09 18:57:11 2004 Received: from web13425.mail.yahoo.com ([216.136.175.156]) by apasphere.com with smtp (Exim 4.14) id 1AqGak-0005ta-Qu for omninotify-list@omniorb-support.com; Mon, 09 Feb 2004 18:57:10 +0000 Message-ID: <20040209185709.19210.qmail@web13425.mail.yahoo.com> Received: from [207.126.237.151] by web13425.mail.yahoo.com via HTTP; Mon, 09 Feb 2004 10:57:09 PST Date: Mon, 9 Feb 2004 10:57:09 -0800 (PST) From: "M. Sanjay Kumar" To: omninotify-list@omniorb-support.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [omniNotify] notifd and TAG_ALTERNATE_IIOP_ADDRESS! X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2004 18:57:11 -0000 Hi All, I am using omniORB4.0.2 and omniNotify2.0_alpha. My client's address is not reachable(192... address and then VPN address) directly so I am adding TAG_ALTERNATE_IIOP_ADDRESS to it's IOR through interceptors and I am using push consumers. notifd generates an error saying comsumer not reachable and looks like it is not trying the other addresses provided by TAG_ALTERNATE_IIOP_ADDRESS. My other servers written using omniORB4.0.2 had no problem with callbacks. Are there any settings I should modify for this? Thanks, Sanjay __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html From markzimm@frii.com Thu Mar 18 18:28:48 2004 Received: from io.frii.com ([216.17.222.1]) by apasphere.com with esmtp (Exim 4.14) id 1B42G8-0007k2-Lh for omninotify-list@omniorb-support.com; Thu, 18 Mar 2004 18:28:48 +0000 Received: from io.frii.com (localhost.frii.com [127.0.0.1]) by io.frii.com (8.12.10/8.12.10) with ESMTP id i2IISleQ035421 for ; Thu, 18 Mar 2004 11:28:47 -0700 (MST) Received: (from markzimm@localhost) by io.frii.com (8.12.10/8.12.10/Submit) id i2IISlG6035420 for omninotify-list@omniorb-support.com; Thu, 18 Mar 2004 11:28:47 -0700 (MST) X-Authentication-Warning: io.frii.com: markzimm set sender to markzimm@frii.com using -f Date: Thu, 18 Mar 2004 11:28:47 -0700 From: Mark Zimmerman To: omninotify-list@omniorb-support.com Message-ID: <20040318182847.GA35300@io.frii.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i Subject: [omniNotify] 2.0 release (?) X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 18:28:49 -0000 Greetings: What is the likelihood of a 2.0 release? Yes, I know I keep asking this... -- Mark From garybusani6@netscape.net Wed Apr 14 21:18:33 2004 Received: from realvnc.com ([213.239.45.162]) by apasphere.com with esmtp (Exim 4.14) id 1BDqq9-0004ov-Jc for omninotify-list@www.omniorb-support.com; Wed, 14 Apr 2004 21:18:33 +0100 Received: from netscape952.com (c53755a67.cable.wanadoo.nl [83.117.90.103]) by realvnc.com (8.11.6/8.11.6) with SMTP id i3EKITf25432 for ; Wed, 14 Apr 2004 21:18:30 +0100 Message-Id: <200404142018.i3EKITf25432@realvnc.com> From: "Mr.Gary Busani" To: omninotify-list@realvnc.com Date: Wed, 14 Apr 2004 22:18:31 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="7903762b-9bab-4994-a924-6e43f9f50ba2" Cc: Subject: [omniNotify] Request From South Africa Student X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list Reply-To: garybusani6@netscape.net List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2004 20:18:33 -0000 This is a multi-part message in MIME format --7903762b-9bab-4994-a924-6e43f9f50ba2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I am interested in your partnership in business dealing. This business = proposal I wish to intimate you with is of mutual benefit and it's success is = entirely based on mutual trust, cooperation and a high level of = confidentiality as regard this transaction. I am pleased to introduce myself = to you. My name is Gary Busani a native of South Africa currently here in = Rotterdam on a training course. I am writing this letter to request your assistance in order to redeem an = investment with the then South African Mining Cooperation now the Ministry of = Natural Resources. The said investment, now valued at US$25.5 (Twenty-Five = Million Five Hundred Thousand) was purchased by Mr.Lucio Campagna and = contracted out of South African Mining Co-operation in 1977.The redeemable = investment interest, has now matured since march last year. Since march last year, several attempted have been made to contact Mr. Lucio = Campagna without success and there is no way to contact any of his close = relatives in whose favor the investment cash value can be paid. Since we have asses to all Mr. Lucios information=92s, we can claim this = money with the help of my partner in the ministry of natural resources. All = we have to do is to file claims using you as Mr. Lucios relative. I would like to assure you that there is absolutely nothing to worry about, = because it is perfectly safe and risk free. Please ensure to keep this matter = strictly confidential. My partner will file for claims for the money on your = behalf in south African Mining Co-operation. When the claim is approved, you = will now be paid the sum US$25.5 Million Dollars as the beneficiary Since the money will be paid directly into any bank account of your choice, = your responsibility is to assure us that me and partners will receive 65% = of the total sum. while you keep 25% for your assistance and the balance 10% = would be set aside for any expenses that maybe incurred in the course of this = transaction. I would appreciate if you can give your assurance and guarantee that our = share would be secured. Please for the sake of confidentiality, reach me via = email (garybusani6@netscape.net ) and let me know if this proposal is acceptable = by you. Truly Yours Mr.Gary Busani --7903762b-9bab-4994-a924-6e43f9f50ba2-- From thomud@netscape.net Thu Apr 15 00:46:36 2004 Received: from realvnc.com ([213.239.45.162]) by apasphere.com with esmtp (Exim 4.14) id 1BDu5U-0004wV-1f for omninotify-list@www.omniorb-support.com; Thu, 15 Apr 2004 00:46:36 +0100 Received: from netscape1200.com (c53755a67.cable.wanadoo.nl [83.117.90.103]) by realvnc.com (8.11.6/8.11.6) with SMTP id i3ENkXf01563 for ; Thu, 15 Apr 2004 00:46:33 +0100 Message-Id: <200404142346.i3ENkXf01563@realvnc.com> From: "Mr.Thomas Magura" To: omninotify-list@realvnc.com Date: Thu, 15 Apr 2004 01:46:34 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="d7b80f5d-e77f-43c0-bdf5-345b90d1cc2d" Cc: Subject: [omniNotify] URGENT BUSINESS ASSISTANCE NEEDED. X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list Reply-To: thomud@netscape.net List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2004 23:46:36 -0000 This is a multi-part message in MIME format --d7b80f5d-e77f-43c0-bdf5-345b90d1cc2d Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Good day, You may be surprised to receive this letter from me since you do not know me = personally. The purpose of my introduction is that I am Thomas Magura, the = first son of kamara Magura one of the most popular black farmers in Zimbabwe = who was recently murdered in the land dispute in my country. I got your = contact through personal search in the internet hence decided to write you. Before the death of my father, he had taken me to Johannesburg to deposit the = sum of USD$15.5 million (Fifteen million, Five Hundred thousand United States = dollars), in one of the private security and finance company, as he foresaw = the looming danger in Zimbabwe this funds was deposited in a box as gem = stones to avoid much demurrage from the security and finance company. This = amount was meant for the purchase of new machines and chemicals for the Farms = and establishment of new farms in swaziland. This land problem came when Zimbabwean President Mr. Robert Mugabe introduced a new Land Act Reform wholly affecting the rich white farmers and = some few black farmers, and this resulted to the killing and mob action by = Zimbabwean war veterans and some lunatics in the society. In fact a lot of = people were killed because of this Land reform Act for which my father was = one of the victims. It is against this background that, I and my family fled Zimbabwe for fear of = our lives and are currently staying in the Netherlands where we are seeking = political asylum and moreso have decided to transfer my fathers money to a = more reliable foreign account. since the law of Netherlands prohibits a = refugee (asylum seeker) to open any bank account or to be involved in any = financial transaction throughout the territorial zone of Netherlands, As the = eldest son of my father, I am saddled with the responsibility of seeking a = genuine foreign account where these funds could be transferred without the knowledge of my government who = are bent on taking everything we have got. The South African government seems = to be playing along with them. I am faced with the dilemma of moving this amount of money out of South Africa for fear of going through the same experience in future, both countries have similar political history. As a businessman,I am seeking for a = partner who I have to entrust my future and that of my family in his hands, I must let you know that this transaction is risk free. If you accept = to assist me and my family, all I want you to do for me, is to make an = arrangements with the security and finance company to clear the consignment(funds) from their affiliate office here in the Netherlands as i = have already given directives for the consignment to be brought to the Netherlands from South Africa.But before then all modalities will have to be = put in place like change of ownership to the consignment and more importantly = this money I intend to use for investment. I have two options for you. Firstly you can choose to have certain percentage = of the funds for nominating your account for this transaction. Or you can go = into partnership with me for the proper profitable investment of the funds in = your country. Whichever the option you want, feel free to notify me. I have = also mapped out 5% of this money for all kinds of expenses incurred in the = process of this transaction.If you do not prefer a partnership I am willing = to give you 10% of the money while the remaining 85% will be for my = investment in your country. Contact me with the above E-mail address,while I = implore you to maintain the absolute secrecy required in this transaction. = Thanks and God bless you. Yours Faithfully, Mr.Thomas Magura. --d7b80f5d-e77f-43c0-bdf5-345b90d1cc2d-- From markzimm@frii.com Mon Apr 19 16:04:23 2004 Received: from io.frii.com ([216.17.222.1]) by apasphere.com with esmtp (Exim 4.14) id 1BFaJq-0003PC-Tf for omninotify-list@omniorb-support.com; Mon, 19 Apr 2004 16:04:23 +0100 Received: from io.frii.com (localhost.frii.com [127.0.0.1]) by io.frii.com (8.12.10/8.12.10) with ESMTP id i3JF4Lrc093325 for ; Mon, 19 Apr 2004 09:04:21 -0600 (MDT) Received: (from markzimm@localhost) by io.frii.com (8.12.10/8.12.10/Submit) id i3JF4KWB093324 for omninotify-list@omniorb-support.com; Mon, 19 Apr 2004 09:04:20 -0600 (MDT) X-Authentication-Warning: io.frii.com: markzimm set sender to markzimm@frii.com using -f Date: Mon, 19 Apr 2004 09:04:20 -0600 From: Mark Zimmerman To: omninotify-list@omniorb-support.com Message-ID: <20040419150420.GA93075@io.frii.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: [omniNotify] Core dump of notifd X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 15:04:23 -0000 Greetings: notifd crashed for me last weekend; I am running a very recent snapshot of omniORB and omniNotify built with gcc-3.3.3 in a Solaris 8 Sun Ultra 60. A traceback is appended below. Since it is not obvious to me how StructuredProxyPushSupplier_i::has_events calls RDI_VoidRank, I am posting this while I keep looking at it. Any insights would be appreciated. -- Mark #0 0xff2d0964 in RDI_VoidRank () from /opt/omni-040413/lib/libCOSNotify4.so.0 (gdb) where #0 0xff2d0964 in RDI_VoidRank () from /opt/omni-040413/lib/libCOSNotify4.so.0 #1 0xff299014 in StructuredProxyPushSupplier_i::has_events () from /opt/omni-040413/lib/libCOSNotify4.so.0 #2 0xff2a5858 in virtual thunk to StructuredProxyPushSupplier_i::has_events(unsigned long*, unsigned long*) () from /opt/omni-040413/lib/libCOSNotify4.so.0 #3 0xff2b01cc in RDI_NotifyConsumer::_next_available () from /opt/omni-040413/lib/libCOSNotify4.so.0 #4 0xff2afee4 in RDI_NotifyConsumer::notify () from /opt/omni-040413/lib/libCOSNotify4.so.0 #5 0xff2aee1c in RDI_NotifyBoundWorker::run_undetached () from /opt/omni-040413/lib/libCOSNotify4.so.0 #6 0xff0e2d84 in omni_thread_wrapper () from /opt/omni-040413/lib/libomnithread.so.3 #7 0xfe5e58c8 in _lwp_start () from /usr/lib/lwp/libthread.so.1 From gruber@research.att.com Mon Apr 19 16:34:05 2004 Received: from mail-dark.research.att.com ([192.20.225.112]) by apasphere.com with esmtp (Exim 4.14) id 1BFamb-0003RS-Mo for omninotify-list@omniorb-support.com; Mon, 19 Apr 2004 16:34:05 +0100 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by mail-dark.research.att.com (Postfix) with ESMTP id 444C0E8118; Mon, 19 Apr 2004 11:34:05 -0400 (EDT) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 354C0F3AB3; Mon, 19 Apr 2004 11:34:05 -0400 (EDT) Received: from pcgruber (pc-gruber.research.att.com [135.207.23.156]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id i3JFY4Z25405; Mon, 19 Apr 2004 11:34:04 -0400 (EDT) From: "Robert E. Gruber" To: "'Mark Zimmerman'" , Subject: RE: [omniNotify] Core dump of notifd Date: Mon, 19 Apr 2004 11:32:54 -0400 Message-ID: <002901c42623$95539450$9c17cf87@pcgruber> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: <20040419150420.GA93075@io.frii.com> Cc: "Robert E. Gruber" X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 15:34:05 -0000 I think you found a bug in the RDI_OplockEntry debugging code: it (incorrectly) assumes it never sees a null pointer. I will test a fix, check it in, and then retag. (I was just tagging 2.0 today!) -- Bob -----Original Message----- From: omninotify-list-bounces@omniorb-support.com [mailto:omninotify-list-bounces@omniorb-support.com] On Behalf Of Mark Zimmerman Sent: Monday, April 19, 2004 11:04 AM To: omninotify-list@omniorb-support.com Subject: [omniNotify] Core dump of notifd Greetings: notifd crashed for me last weekend; I am running a very recent snapshot of omniORB and omniNotify built with gcc-3.3.3 in a Solaris 8 Sun Ultra 60. A traceback is appended below. Since it is not obvious to me how StructuredProxyPushSupplier_i::has_events calls RDI_VoidRank, I am posting this while I keep looking at it. Any insights would be appreciated. -- Mark #0 0xff2d0964 in RDI_VoidRank () from /opt/omni-040413/lib/libCOSNotify4.so.0 (gdb) where #0 0xff2d0964 in RDI_VoidRank () from /opt/omni-040413/lib/libCOSNotify4.so.0 #1 0xff299014 in StructuredProxyPushSupplier_i::has_events () from /opt/omni-040413/lib/libCOSNotify4.so.0 #2 0xff2a5858 in virtual thunk to StructuredProxyPushSupplier_i::has_events(unsigned long*, unsigned long*) () from /opt/omni-040413/lib/libCOSNotify4.so.0 #3 0xff2b01cc in RDI_NotifyConsumer::_next_available () from /opt/omni-040413/lib/libCOSNotify4.so.0 #4 0xff2afee4 in RDI_NotifyConsumer::notify () from /opt/omni-040413/lib/libCOSNotify4.so.0 #5 0xff2aee1c in RDI_NotifyBoundWorker::run_undetached () from /opt/omni-040413/lib/libCOSNotify4.so.0 #6 0xff0e2d84 in omni_thread_wrapper () from /opt/omni-040413/lib/libomnithread.so.3 #7 0xfe5e58c8 in _lwp_start () from /usr/lib/lwp/libthread.so.1 _______________________________________________ omninotify-list mailing list omninotify-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omninotify-list From markzimm@frii.com Tue Apr 20 15:06:27 2004 Received: from io.frii.com ([216.17.222.1]) by apasphere.com with esmtp (Exim 4.14) id 1BFvtL-0005AS-7G for omninotify-list@omniorb-support.com; Tue, 20 Apr 2004 15:06:27 +0100 Received: from io.frii.com (localhost.frii.com [127.0.0.1]) by io.frii.com (8.12.10/8.12.10) with ESMTP id i3KE6Qrc061640; Tue, 20 Apr 2004 08:06:26 -0600 (MDT) Received: (from markzimm@localhost) by io.frii.com (8.12.10/8.12.10/Submit) id i3KE6PNG061639; Tue, 20 Apr 2004 08:06:25 -0600 (MDT) X-Authentication-Warning: io.frii.com: markzimm set sender to markzimm@frii.com using -f Date: Tue, 20 Apr 2004 08:06:25 -0600 From: "'Mark Zimmerman'" To: "Robert E. Gruber" Subject: Re: [omniNotify] Core dump of notifd Message-ID: <20040420140625.GA61514@io.frii.com> References: <20040419150420.GA93075@io.frii.com> <002901c42623$95539450$9c17cf87@pcgruber> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002901c42623$95539450$9c17cf87@pcgruber> User-Agent: Mutt/1.4.2.1i Cc: omninotify-list@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 14:06:27 -0000 Ah, the old "bug in the debug code" problem. In the formal release, will NDEBUG be set by default or should I consider setting it explicitly. It appears that if I had set it then there would not have been a crash. -- Mark On Mon, Apr 19, 2004 at 11:32:54AM -0400, Robert E. Gruber wrote: > I think you found a bug in the RDI_OplockEntry debugging code: it (incorrectly) assumes it > never sees a null pointer. I will test a fix, check it in, and then retag. (I was just > tagging 2.0 today!) > > -- Bob > > > -----Original Message----- > From: omninotify-list-bounces@omniorb-support.com > [mailto:omninotify-list-bounces@omniorb-support.com] On Behalf Of Mark Zimmerman > Sent: Monday, April 19, 2004 11:04 AM > To: omninotify-list@omniorb-support.com > Subject: [omniNotify] Core dump of notifd > > Greetings: > > notifd crashed for me last weekend; I am running a very recent > snapshot of omniORB and omniNotify built with gcc-3.3.3 in a Solaris 8 > Sun Ultra 60. A traceback is appended below. > > Since it is not obvious to me how StructuredProxyPushSupplier_i::has_events > calls RDI_VoidRank, I am posting this while I keep looking at it. Any > insights would be appreciated. > > -- Mark > > #0 0xff2d0964 in RDI_VoidRank () from /opt/omni-040413/lib/libCOSNotify4.so.0 > (gdb) where > #0 0xff2d0964 in RDI_VoidRank () from /opt/omni-040413/lib/libCOSNotify4.so.0 > #1 0xff299014 in StructuredProxyPushSupplier_i::has_events () > from /opt/omni-040413/lib/libCOSNotify4.so.0 > #2 0xff2a5858 in virtual thunk to StructuredProxyPushSupplier_i::has_events(unsigned > long*, unsigned long*) () from /opt/omni-040413/lib/libCOSNotify4.so.0 > #3 0xff2b01cc in RDI_NotifyConsumer::_next_available () > from /opt/omni-040413/lib/libCOSNotify4.so.0 > #4 0xff2afee4 in RDI_NotifyConsumer::notify () > from /opt/omni-040413/lib/libCOSNotify4.so.0 > #5 0xff2aee1c in RDI_NotifyBoundWorker::run_undetached () > from /opt/omni-040413/lib/libCOSNotify4.so.0 > #6 0xff0e2d84 in omni_thread_wrapper () > from /opt/omni-040413/lib/libomnithread.so.3 > #7 0xfe5e58c8 in _lwp_start () from /usr/lib/lwp/libthread.so.1 > > > _______________________________________________ > omninotify-list mailing list > omninotify-list@omniorb-support.com > http://www.omniorb-support.com/mailman/listinfo/omninotify-list > From gruber@research.att.com Tue Apr 20 16:34:58 2004 Received: from mail-dark.research.att.com ([192.20.225.112]) by apasphere.com with esmtp (Exim 4.14) id 1BFxH0-0005SR-O0 for omninotify-list@omniorb-support.com; Tue, 20 Apr 2004 16:34:58 +0100 Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by mail-dark.research.att.com (Postfix) with ESMTP id 355BDE813A; Tue, 20 Apr 2004 11:34:58 -0400 (EDT) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 26300F3AB3; Tue, 20 Apr 2004 11:34:58 -0400 (EDT) Received: from pcgruber (pc-gruber.research.att.com [135.207.23.156]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id i3KFYvZ14822; Tue, 20 Apr 2004 11:34:57 -0400 (EDT) From: "Robert E. Gruber" To: "'Mark Zimmerman'" Subject: RE: [omniNotify] Core dump of notifd Date: Tue, 20 Apr 2004 11:33:45 -0400 Message-ID: <004a01c426ec$dea8d380$9c17cf87@pcgruber> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: <20040420140625.GA61514@io.frii.com> Cc: omninotify-list@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 15:34:59 -0000 Up until now I have not wanted NDEBUG to be the default, since it = disables a lot of things, including the debug log, which gives clues as to anything that = is going wrong. So NDEBUG has not really been thoroughly tested, though it does appear to = work fine on the costnotify_tests.=20 If Mark (and anyone else!) could try building with all three things = commented out in DEBUG.mk, as in: # (1) Uncomment the following to enable use of the debug log. #EnableDebugLog =3D 1 # (2) Uncomment the following to disable object garbage collection #DisableObjGC =3D 1 # (3) Uncomment the following to compile with extended debugging info = (-g compile option) # Only works for Unix platforms. #EnableDashG =3D 1 and use the resulting notifd it in your system, that would give me more = confidence that NDEBUG does not break anything. =20 BTW I would do a 'gmake veryclean' after the DEBUG.mk change just to = make sure everything is rebuilt. -- Bob -----Original Message----- From: omninotify-list-bounces@omniorb-support.com [mailto:omninotify-list-bounces@omniorb-support.com] On Behalf Of 'Mark = Zimmerman' Sent: Tuesday, April 20, 2004 10:06 AM To: Robert E. Gruber Cc: omninotify-list@omniorb-support.com Subject: Re: [omniNotify] Core dump of notifd Ah, the old "bug in the debug code" problem.=20 In the formal release, will NDEBUG be set by default or should I consider setting it explicitly. It appears that if I had set it then there would not have been a crash. -- Mark On Mon, Apr 19, 2004 at 11:32:54AM -0400, Robert E. Gruber wrote: > I think you found a bug in the RDI_OplockEntry debugging code: it = (incorrectly) assumes it > never sees a null pointer. I will test a fix, check it in, and then = retag. (I was just > tagging 2.0 today!) >=20 > -- Bob >=20 >=20 > -----Original Message----- > From: omninotify-list-bounces@omniorb-support.com > [mailto:omninotify-list-bounces@omniorb-support.com] On Behalf Of Mark = Zimmerman > Sent: Monday, April 19, 2004 11:04 AM > To: omninotify-list@omniorb-support.com > Subject: [omniNotify] Core dump of notifd >=20 > Greetings: >=20 > notifd crashed for me last weekend; I am running a very recent > snapshot of omniORB and omniNotify built with gcc-3.3.3 in a Solaris 8 > Sun Ultra 60. A traceback is appended below. >=20 > Since it is not obvious to me how = StructuredProxyPushSupplier_i::has_events > calls RDI_VoidRank, I am posting this while I keep looking at it. Any > insights would be appreciated. >=20 > -- Mark >=20 > #0 0xff2d0964 in RDI_VoidRank () from = /opt/omni-040413/lib/libCOSNotify4.so.0 > (gdb) where > #0 0xff2d0964 in RDI_VoidRank () from = /opt/omni-040413/lib/libCOSNotify4.so.0 > #1 0xff299014 in StructuredProxyPushSupplier_i::has_events () > from /opt/omni-040413/lib/libCOSNotify4.so.0 > #2 0xff2a5858 in virtual thunk to = StructuredProxyPushSupplier_i::has_events(unsigned > long*, unsigned long*) () from /opt/omni-040413/lib/libCOSNotify4.so.0 > #3 0xff2b01cc in RDI_NotifyConsumer::_next_available () > from /opt/omni-040413/lib/libCOSNotify4.so.0 > #4 0xff2afee4 in RDI_NotifyConsumer::notify () > from /opt/omni-040413/lib/libCOSNotify4.so.0 > #5 0xff2aee1c in RDI_NotifyBoundWorker::run_undetached () > from /opt/omni-040413/lib/libCOSNotify4.so.0 > #6 0xff0e2d84 in omni_thread_wrapper () > from /opt/omni-040413/lib/libomnithread.so.3 > #7 0xfe5e58c8 in _lwp_start () from /usr/lib/lwp/libthread.so.1 >=20 >=20 > _______________________________________________ > omninotify-list mailing list > omninotify-list@omniorb-support.com > http://www.omniorb-support.com/mailman/listinfo/omninotify-list >=20 _______________________________________________ omninotify-list mailing list omninotify-list@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omninotify-list From markzimm@frii.com Tue Apr 20 17:28:05 2004 Received: from io.frii.com ([216.17.222.1]) by apasphere.com with esmtp (Exim 4.14) id 1BFy6O-0005fF-Uj for omninotify-list@omniorb-support.com; Tue, 20 Apr 2004 17:28:05 +0100 Received: from io.frii.com (localhost.frii.com [127.0.0.1]) by io.frii.com (8.12.10/8.12.10) with ESMTP id i3KGS3rc068921; Tue, 20 Apr 2004 10:28:03 -0600 (MDT) Received: (from markzimm@localhost) by io.frii.com (8.12.10/8.12.10/Submit) id i3KGS3nq068920; Tue, 20 Apr 2004 10:28:03 -0600 (MDT) X-Authentication-Warning: io.frii.com: markzimm set sender to markzimm@frii.com using -f Date: Tue, 20 Apr 2004 10:28:03 -0600 From: "'Mark Zimmerman'" To: "Robert E. Gruber" Subject: Re: [omniNotify] Core dump of notifd Message-ID: <20040420162803.GA67930@io.frii.com> References: <20040420140625.GA61514@io.frii.com> <004a01c426ec$dea8d380$9c17cf87@pcgruber> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004a01c426ec$dea8d380$9c17cf87@pcgruber> User-Agent: Mutt/1.4.2.1i Cc: omninotify-list@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 16:28:05 -0000 I rebuilt it (from the April 13 snapshot) this way on a linux intel box and I am running it there under valgrind. If all goes well I will let you know tomorrow morning. If things go badly I might let you know sooner. My application uses structured push suppliers and consumers so I cannot comment on how anything else works. Here is a typical 5 minute report: ====================================================================== The following report generated by Report thread 13 (last ReportingInterval = 300 secs) ====================================================================== omniNotify delta stats report for Channel 0 ====================================================================== queue sizes: global 127 proxy 0 notif 0 DELTA: #announ 206 #notifs 978 #rdi_match 978 #rvm_evals 978 time 300543 msecs : 0.685426 a/sec 3.25411 n/sec 3.93954 a+n/sec CUM: #announ 797 #notifs 2633 #rdi_match 2762 #rvm_evals 2762 time 902087 msecs : 0.883507 a/sec 2.91879 n/sec 3.80229 a+n/sec NUM_THREAD_ID_BUCKETS for_announ 21 for_notif 4 rdi_match 2 rvm_evals 2 SAMPLED_QUEUE_SIZES glob_arriv_Q 127 proxy_work_Q 0 avg_notif_Q 0 -- Mark On Tue, Apr 20, 2004 at 11:33:45AM -0400, Robert E. Gruber wrote: > Up until now I have not wanted NDEBUG to be the default, since it disables a lot of > things, including the debug log, which gives clues as to anything that is going wrong. So > NDEBUG has not really been thoroughly tested, though it does appear to work fine on the > costnotify_tests. > > If Mark (and anyone else!) could try building with all three things commented out in > DEBUG.mk, as in: > > # (1) Uncomment the following to enable use of the debug log. > #EnableDebugLog = 1 > > # (2) Uncomment the following to disable object garbage collection > #DisableObjGC = 1 > > # (3) Uncomment the following to compile with extended debugging info (-g compile option) > # Only works for Unix platforms. > #EnableDashG = 1 > > and use the resulting notifd it in your system, that would give me more confidence that > NDEBUG does not break anything. > > BTW I would do a 'gmake veryclean' after the DEBUG.mk change just to make sure everything > is rebuilt. > > -- Bob > > > > -----Original Message----- > From: omninotify-list-bounces@omniorb-support.com > [mailto:omninotify-list-bounces@omniorb-support.com] On Behalf Of 'Mark Zimmerman' > Sent: Tuesday, April 20, 2004 10:06 AM > To: Robert E. Gruber > Cc: omninotify-list@omniorb-support.com > Subject: Re: [omniNotify] Core dump of notifd > > Ah, the old "bug in the debug code" problem. > > In the formal release, will NDEBUG be set by default or should I > consider setting it explicitly. It appears that if I had set it then > there would not have been a crash. > > -- Mark > > On Mon, Apr 19, 2004 at 11:32:54AM -0400, Robert E. Gruber wrote: > > I think you found a bug in the RDI_OplockEntry debugging code: it (incorrectly) assumes > it > > never sees a null pointer. I will test a fix, check it in, and then retag. (I was just > > tagging 2.0 today!) > > > > -- Bob > > > > > > -----Original Message----- > > From: omninotify-list-bounces@omniorb-support.com > > [mailto:omninotify-list-bounces@omniorb-support.com] On Behalf Of Mark Zimmerman > > Sent: Monday, April 19, 2004 11:04 AM > > To: omninotify-list@omniorb-support.com > > Subject: [omniNotify] Core dump of notifd > > > > Greetings: > > > > notifd crashed for me last weekend; I am running a very recent > > snapshot of omniORB and omniNotify built with gcc-3.3.3 in a Solaris 8 > > Sun Ultra 60. A traceback is appended below. > > > > Since it is not obvious to me how StructuredProxyPushSupplier_i::has_events > > calls RDI_VoidRank, I am posting this while I keep looking at it. Any > > insights would be appreciated. > > > > -- Mark > > > > #0 0xff2d0964 in RDI_VoidRank () from /opt/omni-040413/lib/libCOSNotify4.so.0 > > (gdb) where > > #0 0xff2d0964 in RDI_VoidRank () from /opt/omni-040413/lib/libCOSNotify4.so.0 > > #1 0xff299014 in StructuredProxyPushSupplier_i::has_events () > > from /opt/omni-040413/lib/libCOSNotify4.so.0 > > #2 0xff2a5858 in virtual thunk to StructuredProxyPushSupplier_i::has_events(unsigned > > long*, unsigned long*) () from /opt/omni-040413/lib/libCOSNotify4.so.0 > > #3 0xff2b01cc in RDI_NotifyConsumer::_next_available () > > from /opt/omni-040413/lib/libCOSNotify4.so.0 > > #4 0xff2afee4 in RDI_NotifyConsumer::notify () > > from /opt/omni-040413/lib/libCOSNotify4.so.0 > > #5 0xff2aee1c in RDI_NotifyBoundWorker::run_undetached () > > from /opt/omni-040413/lib/libCOSNotify4.so.0 > > #6 0xff0e2d84 in omni_thread_wrapper () > > from /opt/omni-040413/lib/libomnithread.so.3 > > #7 0xfe5e58c8 in _lwp_start () from /usr/lib/lwp/libthread.so.1 > > > > > > _______________________________________________ > > omninotify-list mailing list > > omninotify-list@omniorb-support.com > > http://www.omniorb-support.com/mailman/listinfo/omninotify-list > > > > _______________________________________________ > omninotify-list mailing list > omninotify-list@omniorb-support.com > http://www.omniorb-support.com/mailman/listinfo/omninotify-list > From markzimm@frii.com Wed Apr 21 19:43:55 2004 Received: from io.frii.com ([216.17.222.1]) by apasphere.com with esmtp (Exim 4.14) id 1BGMhO-0007Uc-TM for omninotify-list@omniorb-support.com; Wed, 21 Apr 2004 19:43:55 +0100 Received: from io.frii.com (localhost.frii.com [127.0.0.1]) by io.frii.com (8.12.10/8.12.10) with ESMTP id i3LIhrrc044311 for ; Wed, 21 Apr 2004 12:43:53 -0600 (MDT) Received: (from markzimm@localhost) by io.frii.com (8.12.10/8.12.10/Submit) id i3LIhrvs044310 for omninotify-list@omniorb-support.com; Wed, 21 Apr 2004 12:43:53 -0600 (MDT) Resent-Message-Id: <200404211843.i3LIhrvs044310@io.frii.com> X-Authentication-Warning: io.frii.com: markzimm set sender to markzimm@frii.com using -f Date: Wed, 21 Apr 2004 10:43:42 -0600 From: "'Mark Zimmerman'" To: "Robert E. Gruber" Message-ID: <20040421164342.GA37658@io.frii.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Resent-From: markzimm@frii.com Resent-Date: Wed, 21 Apr 2004 12:43:53 -0600 Resent-To: omninotify-list@omniorb-support.com Cc: Subject: [omniNotify] Test of notifd with NDEBUG X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 18:43:55 -0000 Greetings: I built the 13 April snapshot of omniNotify with NDEBUG defined and ran the resulting notifd under valgrind for 24 hours in the context of my applications (structured push suppliers and consumers). Also, during the last 10 minutes I tried to flood it with lots of additional traffic. Everything worked fine and valgrind was happy. There were some leaks reported at termination but nothing that would indicate a consistent hemmorage. This backs up my experience of running notifd for weeks at a time without noticeable size increase. Here is the final report from omniNotify: ====================================================================== The following report generated by Report thread 13 (last ReportingInterval = 300 secs) ====================================================================== omniNotify delta stats report for Channel 0 ====================================================================== queue sizes: global 1638.26 proxy 0 notif 0.0429448 DELTA: #announ 3265 #notifs 16221 #rdi_match 19495 #rvm_evals 19495 time 300828 msecs : 10.8534 a/sec 53.9212 n/sec 64.7746 a+n/sec CUM: #announ 59035 #notifs 231974 #rdi_match 242870 #rvm_evals 242870 time 86845938 msecs : 0.679767 a/sec 2.6711 n/sec 3.35086 a+n/sec NUM_THREAD_ID_BUCKETS for_announ 32 for_notif 4 rdi_match 2 rvm_evals 2 SAMPLED_QUEUE_SIZES glob_arriv_Q 1638.26 proxy_work_Q 0 avg_notif_Q 0.0429448 If you want the detailed leak report I can send it to you off-list. -- Mark p.s. Your abbreviation for 'cumulative' might trigger a spam filter. From gruber@research.att.com Mon Apr 26 20:41:46 2004 Received: from mail-dark.research.att.com ([192.20.225.112]) by apasphere.com with esmtp (Exim 4.14) id 1BIBz8-0006Xi-9o; Mon, 26 Apr 2004 20:41:46 +0100 Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by mail-dark.research.att.com (Postfix) with ESMTP id C3405E80F6; Mon, 26 Apr 2004 15:41:45 -0400 (EDT) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id B8BC0F3AB3; Mon, 26 Apr 2004 15:41:45 -0400 (EDT) Received: from pcgruber (pc-gruber.research.att.com [135.207.23.156]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id i3QJfjZ20335; Mon, 26 Apr 2004 15:41:45 -0400 (EDT) From: "Robert E. Gruber" To: , Date: Mon, 26 Apr 2004 15:40:27 -0400 Message-ID: <008701c42bc6$532ccb20$9c17cf87@pcgruber> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal Cc: "Robert E. Gruber" Subject: [omniNotify] omniNotify 2.0 released / fully moved to sourceforge X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2004 19:41:46 -0000 I added the tag omniNotify2_0 to the CVS repository and produces a = source tarball. Also, omniNotify is now fully hosted on sourceforge: I moved the web pages = there, and I am using the sourceforge file release process starting with this release. To those who were waiting: thanks for your patience! omniNotify 2.0 is an implementation of the CORBA Notification Service = that works on top of omniORB 4. As far as I know it can be built on all platforms that = omniORB can be built on, including Windows (thanks to Duncan Grisby). Duncan has offered to = do a binary release for Windows -- look for an announcement. You can find the details at http://omninotify.sourceforge.net (see = Download and Release Notes links). -- Bob Gruber From renej.frog@yucom.be Mon Apr 26 23:31:28 2004 Received: from adicia.telenet-ops.be ([195.130.132.56]) by apasphere.com with esmtp (Exim 4.14) id 1BIEdM-0006n0-7M for omninotify-list@omniorb-support.com; Mon, 26 Apr 2004 23:31:28 +0100 Received: from localhost (localhost.localdomain [127.0.0.1]) by adicia.telenet-ops.be (Postfix) with SMTP id DE24B45557 for ; Tue, 27 Apr 2004 00:31:27 +0200 (MEST) Received: from fnsnb40.jati.lan (d51A45A44.kabel.telenet.be [81.164.90.68]) by adicia.telenet-ops.be (Postfix) with ESMTP id 501A345621 for ; Tue, 27 Apr 2004 00:31:27 +0200 (MEST) From: Rene Jager To: omninotify-list@omniorb-support.com Content-Type: multipart/mixed; boundary="=-3zSOKCdM5QAqnscKgX4k" Message-Id: <1083018686.2967.14.camel@fnsnb40.jati.lan> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 27 Apr 2004 00:31:27 +0200 Subject: [omniNotify] rpm spec file and omniNotify bootscript X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2004 22:31:28 -0000 --=-3zSOKCdM5QAqnscKgX4k Content-Type: text/plain Content-Transfer-Encoding: 7bit hi, first of all: thanx for omniNotify ;-) attached a .spec file I use to build [src]rpm's and a bootscript I use on redhat linux may be useful for others wrt distributing omniNotify the release tag now contains "frog" (company I work for) so you'll have to change it to just a number I hope it can be of any use renej --=-3zSOKCdM5QAqnscKgX4k Content-Disposition: attachment; filename=omniNotify.spec Content-Type: text/plain; name=omniNotify.spec; charset=UTF-8 Content-Transfer-Encoding: 7bit Summary: Notification Service implementation for omniORB Name: omniNotify Version: 2.0 Release: 1.frog License: GPL Group: System/Libraries Source0: %{name}-%{version}.tar.gz #Patch0: omniNotify.patches Source1: omniNotify Prefix: /usr Prereq: /sbin/chkconfig /sbin/ldconfig URL: http://omniorb.sourceforge.net/ #Provides: notifd BuildRequires: omniORB >= 4.0.0 glibc-devel Buildroot: %{_tmppath}/%{name}-%{version}-root #BuildArch: i586 %description CORBA Notification Service based on omniORB. # servers %package -n %{name}-bootscripts Summary: Utility programs Group: Development/C++ Requires: %{name} = %{version}-%{release} Provides: %{name}-bootscripts = %{version}-%{release} #BuildArch: noarch %description -n %{name}-bootscripts Automatic starting of a CORBA Naming Service. # utilities %package -n %{name}-utils Summary: Utility programs Group: Development/C++ Requires: %{name} = %{version}-%{release} Provides: %{name}-utils = %{version}-%{release} %description -n %{name}-utils This package includes utility programs which may be useful at runtime. # devel part of the bundle %package -n %{name}-devel Summary: Header files and libraries needed for %{name} development Group: Development/C++ Requires: %{name} = %{version}-%{release} Provides: %{name}-devel = %{version}-%{release} %description -n %{name}-devel This package includes the header files and libraries needed for developing programs using %{name}. # docs and examples are in a separate package %package -n %{name}-doc Summary: Header files and libraries needed for %{name} development Group: Development/C++ #Requires: %{name} = %{version} #BuildArch: noarch %description -n %{name}-doc This package includes developers doc including examples. %prep #%setup -n %{name}-%{version} %setup -n %{name} #%patch0 -p1 ./configure --prefix=%{prefix} %build make CCFLAGS+="$RPM_OPT_FLAGS" all %install make DESTDIR=$RPM_BUILD_ROOT install mkdir -p $RPM_BUILD_ROOT/etc/rc.d/init.d cp %{SOURCE1} $RPM_BUILD_ROOT/etc/rc.d/init.d/ mkdir -p $RPM_BUILD_ROOT/%{prefix}/share cp -a idl $RPM_BUILD_ROOT/%{prefix}/share/ cp -a bin/ndadmin $RPM_BUILD_ROOT/%{prefix}/bin/ %clean rm -rf $RPM_BUILD_ROOT %pre %post -n %{name} -p /sbin/ldconfig %postun -n %{name} -p /sbin/ldconfig # main package includes libraries and copyright info %files %defattr (-,root,root) %doc channel.cfg standard.cfg ReleaseNote_omniNotify_20 COPYING COPYING.LIB %prefix/bin/notifd %prefix/lib/*.so.* %files -n %{name}-bootscripts %defattr (-,root,root) %config(noreplace) %_sysconfdir/rc.d/init.d/* %files -n %{name}-utils %defattr (-,root,root) %prefix/bin/ndadmin %files -n %{name}-devel %defattr(-,root,root) %doc ReleaseNote_omniNotify_20 COPYING COPYING.LIB %prefix/lib/*.a %prefix/lib/*.so %prefix/include/* %prefix/share/idl/* #%files -n %{name}-doc #%defattr(-,root,root) #%doc doc/* %changelog * Mon Apr 26 2004 Rene Jager 2.0.0 - Adapted to fresh 2.0 release of omniNotify * Fri Sep 12 2003 Rene Jager 1.99.0 - Initial version --=-3zSOKCdM5QAqnscKgX4k Content-Disposition: attachment; filename=omniNotify Content-Type: text/x-sh; name=omniNotify; charset=UTF-8 Content-Transfer-Encoding: 7bit #!/bin/sh # # Startup script to start/stop the omniNotify service notifd # # chkconfig: 345 50 50 # description: CORBA Notification Service based on omniORB # # Author: Rene jager # # Based on omniNames service script: # Author: Sander Steffann # Modified: Thomas Lockhart # - Put omniNames log files under /var/log/omniNames # - Adjust start/stop levels # Standard functions . /etc/rc.d/init.d/functions # Program options SYSCFG_FILE=/etc/sysconfig/omniNotify PROG_NAME=notifd PROG_FILE=/usr/bin/$PROG_NAME CFG_FILE=/etc/omniNotify.cfg LOG_FILE=/var/log/omniNotify.log PID_FILE=/var/run/notifd.pid LOCK_FILE=/var/lock/subsys/notifd FACT_IOR_FILE=/tmp/rdifact.ior OMNIMAPPER_DIR=/var/lib/omniMapper TCPPORT=49001 if [ -f $SYSCFG_FILE ];then . $SYSCFG_FILE fi case "$1" in start) # Make sure directories exist [ -d $OMNIMAPPER_DIR ] || mkdir -p $OMNIMAPPER_DIR if [ -x $PROG_FILE ]; then echo -n "Starting omniNotify ($PROG_NAME)" if [ ! -z "`pidofproc $PROG_NAME`" ]; then echo " impossible: already running (pid `pidofproc $PROG_NAME`)" else OPTIONS="-n" if [ -f $CFG_FILE ]; then OPTIONS="$OPTIONS -c $CFG_FILE" fi # Run it LD_LIBRARY_PATH=/usr/local/src/omniNotify/build/lib $PROG_FILE $OPTIONS &> $LOG_FILE & PROG_PID=$! # Sleep a while, and then check if omniNotify is still running sleep 3 if [ ! -z "`pidofproc $PROG_NAME`" ]; then success "Starting omniNotify ($PROG_NAME)" echo $PROG_PID > $PID_FILE if [ -f $CFG_FILE ]; then FACT_IOR_FILE="`grep FactoryIORFileName $CFG_FILE | awk '{print $2}'`" fi /bin/cat $FACT_IOR_FILE > $OMNIMAPPER_DIR/NotificationService else failure "Starting omniNotify ($PROG_NAME)" rm -f $OMNIMAPPER_DIR/NotificationService rm -f $PID_FILE fi echo fi fi if [ ! -z "`pidofproc $PROG_NAME`" ]; then touch $LOCK_FILE fi ;; stop) echo -n "Stopping omniNotify ($PROG_NAME)" killproc $PROG_NAME echo rm -f $OMNIMAPPER_DIR/NotificationService while [ -n "`pidofproc $PROG_NAME`" ]; do sleep 1 done rm -f $LOCK_FILE ;; restart) $0 stop $0 start ;; status) status $PROG_NAME ;; *) echo "Usage: $0 {start|stop|restart|status}" exit 1 esac exit 0 --=-3zSOKCdM5QAqnscKgX4k-- From duncan@grisby.org Fri Apr 30 17:36:17 2004 Received: from cpc1-cmbg4-5-0-cust104.cmbg.cable.ntl.com ([81.96.72.104] helo=grisby.dyndns.org) by apasphere.com with esmtp (Exim 4.14) id 1BJazo-00069f-TR; Fri, 30 Apr 2004 17:36:16 +0100 Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id i3UGaGA12384; Fri, 30 Apr 2004 17:36:16 +0100 Message-Id: <200404301636.i3UGaGA12384@grisby.dyndns.org> X-Authentication-Warning: cpc1-cmbg4-5-0-cust104.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: omninotify-list@omniorb-support.com, omniorb-list@omniorb-support.com Subject: Re: [omniNotify] omniNotify 2.0 released / fully moved to sourceforge In-Reply-To: Message from "Robert E. Gruber" of "Mon, 26 Apr 2004 15:40:27 EDT." <008701c42bc6$532ccb20$9c17cf87@pcgruber> From: Duncan Grisby Date: Fri, 30 Apr 2004 17:36:16 +0100 Cc: X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2004 16:36:17 -0000 On Monday 26 April, "Robert E. Gruber" wrote: > omniNotify 2.0 is an implementation of the CORBA Notification > Service that works on top of omniORB 4. As far as I know it can be > built on all platforms that omniORB can be built on, including > Windows (thanks to Duncan Grisby). Duncan has offered to do a > binary release for Windows -- look for an announcement. Is anyone desperate for a Windows binary very soon? I'm intending to do an omniORB 4.0.4 release quite soon. The Windows binary of omniNotify will be tied to a particular omniORB release, so if I do it now for omniORB 4.0.3, I'll have to do it again when 4.0.4 is released. If people want the binary urgently I'll do it, but I won't bother if nobody cares. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From lockhart@fourpalms.org Fri Apr 30 17:39:32 2004 Received: from h-67-101-182-44.lsanca54.covad.net ([67.101.182.44] helo=wraith.fourpalms.org) by apasphere.com with esmtp (Exim 4.14) id 1BJb2y-0006Ep-Fx; Fri, 30 Apr 2004 17:39:32 +0100 Received: from fourpalms.org (wraith.fourpalms.org [192.168.1.3]) by wraith.fourpalms.org (Postfix) with ESMTP id 70D262BBCD9; Fri, 30 Apr 2004 09:39:01 -0700 (PDT) Message-ID: <40928125.70007@fourpalms.org> Date: Fri, 30 Apr 2004 09:39:01 -0700 From: Thomas Lockhart Organization: Yes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030428 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Duncan Grisby Subject: Re: [omniORB] Re: [omniNotify] omniNotify 2.0 released / fully moved to sourceforge References: <200404301636.i3UGaGA12384@grisby.dyndns.org> In-Reply-To: <200404301636.i3UGaGA12384@grisby.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: omniorb-list@omniorb-support.com, omninotify-list@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2004 16:39:32 -0000 > ... I'm intending to do an omniORB 4.0.4 release quite soon... I've got some updates for the RPM spec files. Shall I send them directly to you or post them to the list? Do you prefer patches or just the full file(s)? - Tom From cj11@cs.waikato.ac.nz Mon May 03 12:01:58 2004 Received: from zombie.scms.waikato.ac.nz ([130.217.241.34]) by apasphere.com with esmtp (Exim 4.14) id 1BKbCv-0005vm-PF for omninotify-list@omniorb-support.com; Mon, 03 May 2004 12:01:58 +0100 Received: from mail.scms.waikato.ac.nz ([130.217.241.36] helo=webmail.scms.waikato.ac.nz) by zombie.scms.waikato.ac.nz with smtp (Exim 4.14) id 1BKbCO-0006JO-T7 for omninotify-list@omniorb-support.com; Mon, 03 May 2004 23:01:24 +1200 Received: from 130.217.224.34 (SquirrelMail authenticated user cj11) by webmail.scms.waikato.ac.nz with HTTP; Mon, 3 May 2004 23:01:24 +1200 (NZST) Message-ID: <33153.130.217.224.34.1083582084.squirrel@webmail.scms.waikato.ac.nz> Date: Mon, 3 May 2004 23:01:24 +1200 (NZST) From: cj11@cs.waikato.ac.nz To: omninotify-list@omniorb-support.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [omniNotify] Help needed to run OmniNotify X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 11:01:58 -0000 Hi there, I'm currently doing a paper project with OmniNotiy and am pretty new to this system. I downloaded and installed the system to my gentoo linux box. With naming service correctly set, I still can't get my server running. While I tried to start a server by a simple >./notifd -i -c /omni/omniORB-4.0.3/src/services/omniNotify/channel.cfg command. it gave me an "Aborted (core dumped)" message, could anybody give me a hand? Cheers, Wayne From bob.gruber@gmail.com Mon May 03 14:01:44 2004 Received: from mproxy.gmail.com ([216.239.56.244]) by apasphere.com with smtp (Exim 4.14) id 1BKd4q-00066Y-JA for omninotify-list@omniorb-support.com; Mon, 03 May 2004 14:01:44 +0100 Received: by mproxy.gmail.com with SMTP id u15so26290cwc for ; Mon, 03 May 2004 06:01:43 -0700 (PDT) Received: by 10.11.100.63 with SMTP id x63mr95358cwb; Mon, 03 May 2004 06:01:42 -0700 (PDT) Message-ID: Date: Mon, 3 May 2004 09:01:42 -0400 From: Bob Gruber To: "cj11@cs.waikato.ac.nz" Subject: Re: [omniNotify] Help needed to run OmniNotify In-Reply-To: <33153.130.217.224.34.1083582084.squirrel@webmail.scms.waikato.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <33153.130.217.224.34.1083582084.squirrel@webmail.scms.waikato.ac.nz> Cc: omninotify-list@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 13:01:45 -0000 Please give more information. 1. What steps did you take to obtain omniORB and omniNotify? 2. How did you configure and build? 3. Can you get the omniORB examples to work (e.g., can you run the pair of programs eg3_impl/eg3_clt successfully)? -- Bob On Mon, 3 May 2004 23:01:24 +1200 (NZST), cj11@cs.waikato.ac.nz wrote: > > Hi there, > > I'm currently doing a paper project with OmniNotiy and am pretty new to > this system. > > I downloaded and installed the system to my gentoo linux box. With naming > service correctly set, I still can't get my server running. > > While I tried to start a server by a simple > > >./notifd -i -c /omni/omniORB-4.0.3/src/services/omniNotify/channel.cfg > > command. it gave me an "Aborted (core dumped)" message, could anybody give > me a hand? > > Cheers, > Wayne > > _______________________________________________ > omninotify-list mailing list > omninotify-list@omniorb-support.com > http://www.omniorb-support.com/mailman/listinfo/omninotify-list > From alex.omniorb@firetree.net Wed May 05 00:19:24 2004 Received: from 213-152-38-2.dsl.eclipse.net.uk ([213.152.38.2] helo=mail.firetree.net ident=foobar) by apasphere.com with esmtp (Exim 4.14) id 1BL9C8-0008KP-61 for omninotify-list@omniorb-support.com; Wed, 05 May 2004 00:19:24 +0100 Received: from quango.local ([192.168.0.5] helo=quango ident=alex) by mail.firetree.net with smtp (Exim 3.35 #1 (Debian)) id 1BL9C7-0004tF-00 for ; Wed, 05 May 2004 00:19:23 +0100 Date: Wed, 5 May 2004 00:19:23 +0100 From: Alex Tingle To: omninotify-list@omniorb-support.com Message-Id: <20040505001923.5e4cab5b.alex.omniorb@firetree.net> In-Reply-To: <33153.130.217.224.34.1083582084.squirrel@webmail.scms.waikato.ac.nz> References: <33153.130.217.224.34.1083582084.squirrel@webmail.scms.waikato.ac.nz> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [omniNotify] Event Service test suite. X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 23:19:24 -0000 Hello, Congratulations on the 2.0 release. I've just run omniNotify through my Event Service (v1.1) spec. compliance test suite. It's just a bunch of Python scripts that I wrote to test omniEvents when I was reimplementing it. The new omniNotify passes all of the compliance tests except the tests for disconnect callbacks. These are a vital part of the Event Service 1.1 spec, and they should be pretty easy to add in. I've attached the complete set of test result below. If you are interested, you can find the tests in omniEvents/test: http://cvs.sf.net/viewcvs.py/omnievents/omniEvents/test/ Look in analysis.txt & tests.txt for analysis of the spec. and test definitions. Hope you find this useful. -Alex -- :: alex tingle :: 58 kings way, harrow, mddx. uk. HA1 1XU :: alex.tingle AT firetree.net +44-7901-552763 -- % python test.py -ORBInitRef 'Channel=corbaname::localhost#EventChannel.EventChannel' passed: PPshC-1 passed: PPshC-3 passed: PshC-1 passed: PshC-2 FAILED: PPshC-2 passed: PshC-5 passed: PPulS-1 passed: PPulS-3 passed: PulS-2 passed: PulS-3 passed: PulS-4 FAILED: PPulS-2 passed: PulS-5: got exception OBJECT_NOT_EXIST passed: PulS-6: got exception OBJECT_NOT_EXIST passed: PPulS-8: got exception OBJECT_NOT_EXIST passed: PPulC-2 passed: PPulC-3 passed: PPulC-works FAILED: PulC-2 passed: PulC-3 passed: PPshS-2: got exception BAD_PARAM passed: PPshS-3: got exception AlreadyConnected passed: PPshS-works FAILED: PPshS-1 passed: PshS-2: got exception OBJECT_NOT_EXIST % From bob.gruber@gmail.com Wed May 05 01:36:08 2004 Received: from rproxy.gmail.com ([64.233.170.201] helo=mproxy.gmail.com) by apasphere.com with smtp (Exim 4.14) id 1BLAOO-0008Px-65 for omninotify-list@omniorb-support.com; Wed, 05 May 2004 01:36:08 +0100 Received: by mproxy.gmail.com with SMTP id 75so37656rnf for ; Tue, 04 May 2004 17:36:07 -0700 (PDT) Received: by 10.11.122.71 with SMTP id u71mr121141cwc; Tue, 04 May 2004 17:36:07 -0700 (PDT) Message-ID: Date: Tue, 4 May 2004 20:36:07 -0400 From: Bob Gruber To: Alex Tingle Subject: Re: [omniNotify] Event Service test suite. In-Reply-To: <20040505001923.5e4cab5b.alex.omniorb@firetree.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <33153.130.217.224.34.1083582084.squirrel@webmail.scms.waikato.ac.nz> <20040505001923.5e4cab5b.alex.omniorb@firetree.net> Cc: omninotify-list@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2004 00:36:08 -0000 Thanks, I will take a look at this soon. -- Bob On Wed, 5 May 2004 00:19:23 +0100, Alex Tingle wrote: > > Hello, > > Congratulations on the 2.0 release. > > I've just run omniNotify through my Event Service (v1.1) spec. > compliance test suite. It's just a bunch of Python scripts that I wrote > to test omniEvents when I was reimplementing it. > > The new omniNotify passes all of the compliance tests except the tests > for disconnect callbacks. These are a vital part of the Event Service > 1.1 spec, and they should be pretty easy to add in. I've attached the > complete set of test result below. > > If you are interested, you can find the tests in omniEvents/test: > http://cvs.sf.net/viewcvs.py/omnievents/omniEvents/test/ > Look in analysis.txt & tests.txt for analysis of the spec. and test > definitions. > > Hope you find this useful. > > -Alex > > -- > :: alex tingle > :: 58 kings way, harrow, mddx. uk. HA1 1XU > :: alex.tingle AT firetree.net +44-7901-552763 > > -- > % python test.py -ORBInitRef > 'Channel=corbaname::localhost#EventChannel.EventChannel' > passed: PPshC-1 > passed: PPshC-3 > passed: PshC-1 > passed: PshC-2 > FAILED: PPshC-2 > passed: PshC-5 > passed: PPulS-1 > passed: PPulS-3 > passed: PulS-2 > passed: PulS-3 > passed: PulS-4 > FAILED: PPulS-2 > passed: PulS-5: got exception OBJECT_NOT_EXIST > passed: PulS-6: got exception OBJECT_NOT_EXIST > passed: PPulS-8: got exception OBJECT_NOT_EXIST > passed: PPulC-2 > passed: PPulC-3 > passed: PPulC-works > FAILED: PulC-2 > passed: PulC-3 > passed: PPshS-2: got exception BAD_PARAM > passed: PPshS-3: got exception AlreadyConnected > passed: PPshS-works > FAILED: PPshS-1 > passed: PshS-2: got exception OBJECT_NOT_EXIST > % > > _______________________________________________ > omninotify-list mailing list > omninotify-list@omniorb-support.com > http://www.omniorb-support.com/mailman/listinfo/omninotify-list > From taurel@esrf.fr Fri May 07 09:25:57 2004 Received: from firewall.esrf.fr ([193.49.43.1] helo=out.esrf.fr) by apasphere.com with esmtp (Exim 4.14) id 1BM0g9-0004cH-PI for omninotify-list@omniorb-support.com; Fri, 07 May 2004 09:25:57 +0100 Received: (from uucp@localhost) by out.esrf.fr (1.0.0) id i478PQl11289 for ; Fri, 7 May 2004 10:25:26 +0200 (MEST) Received: from esrf.esrf.fr(160.103.2.9) by firewall via smap (V1.3) id tmp011253; Fri May 7 10:25:19 2004 Received: from esrf.fr (localhost [127.0.0.1]) by esrf.esrf.fr (8.9.0/8.9.0) with ESMTP id KAA04628 for ; Fri, 7 May 2004 10:25:17 +0200 (MET DST) Message-ID: <409B4809.EC1DD6EC@esrf.fr> Date: Fri, 07 May 2004 10:25:45 +0200 From: Emmanuel Taurel X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: omninotify-list@omniorb-support.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [omniNotify] omninotify 2.0 and modulo X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 08:25:57 -0000 Hello everybody, We are using omniNotify and filtering. In our filter constraints, we sometimes use modulo. We know that it is not part of the CORBA standard but it is very usefull for us. With a omniNotify 2.0 latest release that I downloaded in October 2003, everything worked fine. It does not with the official 2.0 release !! The problem comes from switch default cases added in the DRI_RVM::_widenAndResultKinds() method in the RDIRVM.cc file. If, in the official release 2.0, I remove the two default cases added between the release I downloed in October and the official 2.0 release (line 291/292 and 326/327), everything works fine as before. What are the consequence of removing these two switch default cases ? Do you continue to support "modulo" in filter constraint ? Thank's for your answers Emmanuel Taurel (taurel@esrf.fr) From bob.gruber@gmail.com Fri May 07 14:43:42 2004 Received: from mproxy.gmail.com ([216.239.56.241]) by apasphere.com with smtp (Exim 4.14) id 1BM5de-0005JP-3D for omninotify-list@omniorb-support.com; Fri, 07 May 2004 14:43:42 +0100 Received: by mproxy.gmail.com with SMTP id x17so20475cwb for ; Fri, 07 May 2004 06:43:40 -0700 (PDT) Received: by 10.11.98.60 with SMTP id v60mr164518cwb; Fri, 07 May 2004 06:37:00 -0700 (PDT) Message-ID: Date: Fri, 7 May 2004 09:37:00 -0400 From: Bob Gruber To: Emmanuel Taurel Subject: Re: [omniNotify] omninotify 2.0 and modulo In-Reply-To: <409B4809.EC1DD6EC@esrf.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <409B4809.EC1DD6EC@esrf.fr> Cc: omninotify-list@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 13:43:42 -0000 Oops, those were added to get rid of a compiler warning. The calls to RDI_Fatal should actually just be breaks. 292c292 < RDI_Fatal("should not get here"); --- > break; 327c327 < RDI_Fatal("should not get here"); --- > break; I will check in a fix and also do another release. -- Bob On Fri, 07 May 2004 10:25:45 +0200, Emmanuel Taurel wrote: > > Hello everybody, > > We are using omniNotify and filtering. In our filter constraints, we > sometimes use modulo. We know that it is not part of > the CORBA standard but it is very usefull for us. With a omniNotify 2.0 > latest release that I downloaded in October 2003, everything worked > fine. > It does not with the official 2.0 release !! > > The problem comes from switch default cases added in the > DRI_RVM::_widenAndResultKinds() method in the RDIRVM.cc > file. If, in the official release 2.0, I remove the two default cases > added between the release I downloed in October and the official 2.0 > release (line 291/292 and 326/327), everything works fine as before. > > What are the consequence of removing these two switch default cases ? > Do you continue to support "modulo" in filter constraint ? > > Thank's for your answers > > Emmanuel Taurel (taurel@esrf.fr) > > _______________________________________________ > omninotify-list mailing list > omninotify-list@omniorb-support.com > http://www.omniorb-support.com/mailman/listinfo/omninotify-list > From bob.gruber@gmail.com Fri May 07 15:52:08 2004 Received: from mproxy.gmail.com ([216.239.56.242]) by apasphere.com with smtp (Exim 4.14) id 1BM6hr-0005Nz-Uy for omninotify-list@omniorb-support.com; Fri, 07 May 2004 15:52:08 +0100 Received: by mproxy.gmail.com with SMTP id u22so6082cwc for ; Fri, 07 May 2004 07:52:02 -0700 (PDT) Received: by 10.11.98.44 with SMTP id v44mr22423cwb; Fri, 07 May 2004 07:52:02 -0700 (PDT) Message-ID: Date: Fri, 7 May 2004 10:52:02 -0400 From: Bob Gruber To: omninotify-list@omniorb-support.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [omniNotify] omniNotify 2.1 released (bug fix release) X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 14:52:08 -0000 I decided to adopt the 'release often' philosophy, at least wrt important bug fixes. This release just changes 2 lines of source code in one file, but they are important lines, so you are strongy urged to update. For those using CVS, the change is committed under the omniNotify2_develop branch (and the omniNotify2_1 tag, but you are better off using the omniNotify2_develop tag to track future fixes). For those who like to get tarballs, the 2.1 tarball is here: http://sourceforge.net/project/showfiles.php?group_id=77499 Duncan: I guess you just need to do a windows release for omniNotify 2.1... Thanks! -- Bob From markzimm@frii.com Fri May 14 17:48:37 2004 Received: from io.frii.com ([216.17.222.1]) by apasphere.com with esmtp (Exim 4.14) id 1BOfrQ-0007zY-O0 for omninotify-list@omniorb-support.com; Fri, 14 May 2004 17:48:36 +0100 Received: from io.frii.com (localhost.frii.com [127.0.0.1]) by io.frii.com (8.12.10/8.12.10) with ESMTP id i4EGmZqV034712 for ; Fri, 14 May 2004 10:48:35 -0600 (MDT) Received: (from markzimm@localhost) by io.frii.com (8.12.10/8.12.10/Submit) id i4EGmZHU034711 for omninotify-list@omniorb-support.com; Fri, 14 May 2004 10:48:35 -0600 (MDT) X-Authentication-Warning: io.frii.com: markzimm set sender to markzimm@frii.com using -f Date: Fri, 14 May 2004 10:48:35 -0600 From: Mark Zimmerman To: omninotify-list@omniorb-support.com Message-ID: <20040514164835.GB34360@io.frii.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: [omniNotify] Using omniNotify without creating endpoints X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2004 16:48:37 -0000 Greetings: I have a small program that does nothing but post a single message to the omniNotify notification channel (from a push_supplier) and exit. It works fine with a default configuration but I am trying to understand why it insists on creating and serving incoming endpoints. Unless I misunderstand the meaning of an incoming endpoint, it seems to me that it doesn't need one. However, when I include 'endPointNoListen = giop:tcp::' in the configuration, it fails: omniORB: Initialising incoming endpoints. omniORB: Error: Unable to create an endpoint of this description: giop:tcp:: omniORB: throw INITIALIZE from objectAdapter.cc:245 (NO,INITIALIZE_TransportError) With endPointNoListen excluded, the program works but the endpoints are never used (I think). I have set 'serverTransportRule = * none' which, I believe, will prevent them from accepting connections. Is there something in omniNotify that requires endpoint creation in this context? Is there a way to avoid this? -- Mark From duncan@grisby.org Tue May 18 15:54:57 2004 Received: from cpc1-cmbg4-5-0-cust104.cmbg.cable.ntl.com ([81.96.72.104] helo=grisby.dyndns.org) by apasphere.com with esmtp (Exim 4.14) id 1BQ5zd-0006TA-4w; Tue, 18 May 2004 15:54:57 +0100 Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id i4IEstr22413; Tue, 18 May 2004 15:54:56 +0100 Message-Id: <200405181454.i4IEstr22413@grisby.dyndns.org> X-Authentication-Warning: cpc1-cmbg4-5-0-cust104.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: Mark Zimmerman Subject: Re: [omniNotify] Using omniNotify without creating endpoints In-Reply-To: Message from Mark Zimmerman of "Fri, 14 May 2004 10:48:35 MDT." <20040514164835.GB34360@io.frii.com> From: Duncan Grisby Date: Tue, 18 May 2004 15:54:55 +0100 Cc: omninotify-list@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2004 14:54:57 -0000 On Friday 14 May, Mark Zimmerman wrote: > I have a small program that does nothing but post a single message to > the omniNotify notification channel (from a push_supplier) and exit. > It works fine with a default configuration but I am trying to > understand why it insists on creating and serving incoming endpoints. > Unless I misunderstand the meaning of an incoming endpoint, it seems > to me that it doesn't need one. > > However, when I include 'endPointNoListen = giop:tcp::' in the > configuration, it fails: That doesn't do what you think it does. endPointNoListen asks the ORB to publish the given endpoint in IORs, without listening on it. For that to work, you have to give the full details of the endpoint, since there is no real endpoint to get the details from. Anyway, it's not a way to stop your program from listening. [...] > With endPointNoListen excluded, the program works but the endpoints > are never used (I think). I have set 'serverTransportRule = * none' > which, I believe, will prevent them from accepting connections. > > Is there something in omniNotify that requires endpoint creation in > this context? Is there a way to avoid this? The incoming endpoints are initialised when you resolve the root POA (or get a reference to the BOA). If the code doesn't every get hold of the POA, the endpoints are not initialised. Something in your code, or a library you are using (are you linking with omniNotify?) must be resolving the root POA. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From markzimm@frii.com Fri May 21 16:24:30 2004 Received: from io.frii.com ([216.17.222.1]) by apasphere.com with esmtp (Exim 4.14) id 1BRBss-0003pB-D7 for omninotify-list@omniorb-support.com; Fri, 21 May 2004 16:24:30 +0100 Received: from io.frii.com (localhost.frii.com [127.0.0.1]) by io.frii.com (8.12.10/8.12.10) with ESMTP id i4LFOPqV061405; Fri, 21 May 2004 09:24:25 -0600 (MDT) Received: (from markzimm@localhost) by io.frii.com (8.12.10/8.12.10/Submit) id i4LFOPAN061404; Fri, 21 May 2004 09:24:25 -0600 (MDT) X-Authentication-Warning: io.frii.com: markzimm set sender to markzimm@frii.com using -f Date: Fri, 21 May 2004 09:24:25 -0600 From: Mark Zimmerman To: Duncan Grisby , omninotify-list@omniorb-support.com Subject: Re: [omniNotify] Using omniNotify without creating endpoints Message-ID: <20040521152424.GA60508@io.frii.com> References: <20040514164835.GB34360@io.frii.com> <200405181454.i4IEstr22413@grisby.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200405181454.i4IEstr22413@grisby.dyndns.org> User-Agent: Mutt/1.4.2.1i Cc: X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2004 15:24:30 -0000 On Tue, May 18, 2004 at 03:54:55PM +0100, Duncan Grisby wrote: > On Friday 14 May, Mark Zimmerman wrote: > > > I have a small program that does nothing but post a single message to > > the omniNotify notification channel (from a push_supplier) and exit. > > It works fine with a default configuration but I am trying to > > understand why it insists on creating and serving incoming endpoints. > > Unless I misunderstand the meaning of an incoming endpoint, it seems > > to me that it doesn't need one. > > > > However, when I include 'endPointNoListen = giop:tcp::' in the > > configuration, it fails: > > That doesn't do what you think it does. endPointNoListen asks the ORB > to publish the given endpoint in IORs, without listening on it. For > that to work, you have to give the full details of the endpoint, since > there is no real endpoint to get the details from. Anyway, it's not a > way to stop your program from listening. > > [...] > > With endPointNoListen excluded, the program works but the endpoints > > are never used (I think). I have set 'serverTransportRule = * none' > > which, I believe, will prevent them from accepting connections. > > > > Is there something in omniNotify that requires endpoint creation in > > this context? Is there a way to avoid this? > > The incoming endpoints are initialised when you resolve the root POA > (or get a reference to the BOA). If the code doesn't every get hold of > the POA, the endpoints are not initialised. Something in your code, or > a library you are using (are you linking with omniNotify?) must be > resolving the root POA. > I guess it must be the omniNotify library. The only reference to the POA in my test case was in the destructor. I had forgotten why it was there so I commented it out (see below) and tried again. I got the error shown at the bottom of the trace log (see farther below) since the library apparently resolved the POA and I was now failing to deactivate it. I am now uncertain as to whether I can make omniNotify not resolve the root POA when all I want to do is post a message. // try { // PortableServer::POA_ptr poa = RefUtils::POA(); // PortableServer::Servant serv = poa->reference_to_servant(_this()); // PortableServer::ObjectId_var oid = poa->servant_to_id(serv); // poa->deactivate_object(oid); // } // catch (...) {} // ignore any error during destroy call omniORB: Creating ref to remote: key target id : IDL:omg.org/CORBA/Object:1.0 most derived id: omniORB: Initial reference `NameService' resolved from configuration file. omniORB: AsyncInvoker: thread id = 1 has started. Total threads = 1 omniORB: Creating ref to remote: key target id : IDL:omg.org/CosNaming/NamingContext:1.0 most derived id: omniORB: Creating ref to remote: root<4> target id : IDL:omg.org/CORBA/Object:1.0 most derived id: IDL:att.com/AttNotification/EventChannel:1.0 omniORB: Creating ref to remote: root<4> target id : IDL:omg.org/CosNotifyChannelAdmin/EventChannel:1.0 most derived id: IDL:att.com/AttNotification/EventChannel:1.0 omniORB: Creating ref to remote: root<27425> target id : IDL:omg.org/CosNotifyChannelAdmin/SupplierAdmin:1.0 most derived id: IDL:att.com/AttNotification/SupplierAdmin:1.0 omniORB: Creating ref to remote: root<27426> target id : IDL:omg.org/CosNotifyChannelAdmin/ProxyConsumer:1.0 most derived id: IDL:att.com/AttNotification/StructuredProxyPushConsumer:1.0 omniORB: Creating ref to remote: root<27426> target id : IDL:omg.org/CosNotifyChannelAdmin/StructuredProxyPushConsumer:1.0 most derived id: IDL:att.com/AttNotification/StructuredProxyPushConsumer:1.0 omniORB: Initialising incoming endpoints. omniORB: Starting serving incoming endpoints. omniORB: Adding root<0> (activating) to object table. omniORB: Creating ref to local: root<0> target id : IDL:omg.org/CosNotifyComm/StructuredPushSupplier:1.0 most derived id: IDL:omg.org/CosNotifyComm/StructuredPushSupplier:1.0 omniORB: AsyncInvoker: thread id = 2 has started. Total threads = 2 omniORB: ERROR -- A servant has been deleted that is still activated. id: root<0> (active) From bob.gruber@gmail.com Tue May 25 18:03:55 2004 Received: from mproxy.gmail.com ([216.239.56.247]) by apasphere.com with smtp (Exim 4.14) id 1BSfLH-0003dh-A0 for omninotify-list@omniorb-support.com; Tue, 25 May 2004 18:03:55 +0100 Received: by mproxy.gmail.com with SMTP id x43so69712cwb for ; Tue, 25 May 2004 10:03:50 -0700 (PDT) Received: by 10.11.98.26 with SMTP id v26mr278676cwb; Tue, 25 May 2004 10:03:50 -0700 (PDT) Message-ID: Date: Tue, 25 May 2004 13:03:50 -0400 From: Bob Gruber To: Mark Zimmerman Subject: Re: [omniNotify] Using omniNotify without creating endpoints In-Reply-To: <20040521152424.GA60508@io.frii.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040514164835.GB34360@io.frii.com> <200405181454.i4IEstr22413@grisby.dyndns.org> <20040521152424.GA60508@io.frii.com> Cc: Duncan Grisby , omninotify-list@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2004 17:03:55 -0000 If this is a client, you should not link against the omniNotify library, just the COS library. Or did you mean the COS library? On Fri, 21 May 2004 09:24:25 -0600, Mark Zimmerman wrote: > > On Tue, May 18, 2004 at 03:54:55PM +0100, Duncan Grisby wrote: > > On Friday 14 May, Mark Zimmerman wrote: > > > > > I have a small program that does nothing but post a single message to > > > the omniNotify notification channel (from a push_supplier) and exit. > > > It works fine with a default configuration but I am trying to > > > understand why it insists on creating and serving incoming endpoints. > > > Unless I misunderstand the meaning of an incoming endpoint, it seems > > > to me that it doesn't need one. > > > > > > However, when I include 'endPointNoListen = giop:tcp::' in the > > > configuration, it fails: > > > > That doesn't do what you think it does. endPointNoListen asks the ORB > > to publish the given endpoint in IORs, without listening on it. For > > that to work, you have to give the full details of the endpoint, since > > there is no real endpoint to get the details from. Anyway, it's not a > > way to stop your program from listening. > > > > [...] > > > With endPointNoListen excluded, the program works but the endpoints > > > are never used (I think). I have set 'serverTransportRule = * none' > > > which, I believe, will prevent them from accepting connections. > > > > > > Is there something in omniNotify that requires endpoint creation in > > > this context? Is there a way to avoid this? > > > > The incoming endpoints are initialised when you resolve the root POA > > (or get a reference to the BOA). If the code doesn't every get hold of > > the POA, the endpoints are not initialised. Something in your code, or > > a library you are using (are you linking with omniNotify?) must be > > resolving the root POA. > > > > I guess it must be the omniNotify library. The only reference to the POA > in my test case was in the destructor. I had forgotten why it was there > so I commented it out (see below) and tried again. I got the error shown > at the bottom of the trace log (see farther below) since the library > apparently resolved the POA and I was now failing to deactivate it. > > I am now uncertain as to whether I can make omniNotify not resolve the > root POA when all I want to do is post a message. > > // try { > // PortableServer::POA_ptr poa = RefUtils::POA(); > // PortableServer::Servant serv = poa->reference_to_servant(_this()); > // PortableServer::ObjectId_var oid = poa->servant_to_id(serv); > // poa->deactivate_object(oid); > // } > // catch (...) {} // ignore any error during destroy call > > omniORB: Creating ref to remote: key > target id : IDL:omg.org/CORBA/Object:1.0 > most derived id: > omniORB: Initial reference `NameService' resolved from configuration file. > omniORB: AsyncInvoker: thread id = 1 has started. Total threads = 1 > omniORB: Creating ref to remote: key > target id : IDL:omg.org/CosNaming/NamingContext:1.0 > most derived id: > omniORB: Creating ref to remote: root<4> > target id : IDL:omg.org/CORBA/Object:1.0 > most derived id: IDL:att.com/AttNotification/EventChannel:1.0 > omniORB: Creating ref to remote: root<4> > target id : IDL:omg.org/CosNotifyChannelAdmin/EventChannel:1.0 > most derived id: IDL:att.com/AttNotification/EventChannel:1.0 > omniORB: Creating ref to remote: root<27425> > target id : IDL:omg.org/CosNotifyChannelAdmin/SupplierAdmin:1.0 > most derived id: IDL:att.com/AttNotification/SupplierAdmin:1.0 > omniORB: Creating ref to remote: root<27426> > target id : IDL:omg.org/CosNotifyChannelAdmin/ProxyConsumer:1.0 > most derived id: IDL:att.com/AttNotification/StructuredProxyPushConsumer:1.0 > omniORB: Creating ref to remote: root<27426> > target id : IDL:omg.org/CosNotifyChannelAdmin/StructuredProxyPushConsumer:1.0 > most derived id: IDL:att.com/AttNotification/StructuredProxyPushConsumer:1.0 > omniORB: Initialising incoming endpoints. > omniORB: Starting serving incoming endpoints. > omniORB: Adding root<0> (activating) to object table. > omniORB: Creating ref to local: root<0> > target id : IDL:omg.org/CosNotifyComm/StructuredPushSupplier:1.0 > most derived id: IDL:omg.org/CosNotifyComm/StructuredPushSupplier:1.0 > omniORB: AsyncInvoker: thread id = 2 has started. Total threads = 2 > omniORB: ERROR -- A servant has been deleted that is still activated. > id: root<0> (active) > > > > > _______________________________________________ > omninotify-list mailing list > omninotify-list@omniorb-support.com > http://www.omniorb-support.com/mailman/listinfo/omninotify-list > From markzimm@frii.com Tue May 25 20:33:06 2004 Received: from io.frii.com ([216.17.222.1]) by apasphere.com with esmtp (Exim 4.14) id 1BShfe-0003lr-A5 for omninotify-list@omniorb-support.com; Tue, 25 May 2004 20:33:06 +0100 Received: from io.frii.com (localhost.frii.com [127.0.0.1]) by io.frii.com (8.12.10/8.12.10) with ESMTP id i4PJX3qV012893; Tue, 25 May 2004 13:33:04 -0600 (MDT) Received: (from markzimm@localhost) by io.frii.com (8.12.10/8.12.10/Submit) id i4PJX3B1012892; Tue, 25 May 2004 13:33:03 -0600 (MDT) X-Authentication-Warning: io.frii.com: markzimm set sender to markzimm@frii.com using -f Date: Tue, 25 May 2004 13:33:03 -0600 From: Mark Zimmerman To: Bob Gruber Subject: Re: [omniNotify] Using omniNotify without creating endpoints Message-ID: <20040525193303.GA11197@io.frii.com> References: <20040514164835.GB34360@io.frii.com> <200405181454.i4IEstr22413@grisby.dyndns.org> <20040521152424.GA60508@io.frii.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: omninotify-list@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2004 19:33:06 -0000 Yes, I just meant the COS library. Do you have any idea what might be creating this (these) endpoint(s) and why? On Tue, May 25, 2004 at 01:03:50PM -0400, Bob Gruber wrote: > If this is a client, you should not link against the omniNotify > library, just the COS library. Or did you mean the COS library? > > On Fri, 21 May 2004 09:24:25 -0600, Mark Zimmerman wrote: > > > > On Tue, May 18, 2004 at 03:54:55PM +0100, Duncan Grisby wrote: > > > On Friday 14 May, Mark Zimmerman wrote: > > > > > > > I have a small program that does nothing but post a single message to > > > > the omniNotify notification channel (from a push_supplier) and exit. > > > > It works fine with a default configuration but I am trying to > > > > understand why it insists on creating and serving incoming endpoints. > > > > Unless I misunderstand the meaning of an incoming endpoint, it seems > > > > to me that it doesn't need one. > > > > > > > > However, when I include 'endPointNoListen = giop:tcp::' in the > > > > configuration, it fails: > > > > > > That doesn't do what you think it does. endPointNoListen asks the ORB > > > to publish the given endpoint in IORs, without listening on it. For > > > that to work, you have to give the full details of the endpoint, since > > > there is no real endpoint to get the details from. Anyway, it's not a > > > way to stop your program from listening. > > > > > > [...] > > > > With endPointNoListen excluded, the program works but the endpoints > > > > are never used (I think). I have set 'serverTransportRule = * none' > > > > which, I believe, will prevent them from accepting connections. > > > > > > > > Is there something in omniNotify that requires endpoint creation in > > > > this context? Is there a way to avoid this? > > > > > > The incoming endpoints are initialised when you resolve the root POA > > > (or get a reference to the BOA). If the code doesn't every get hold of > > > the POA, the endpoints are not initialised. Something in your code, or > > > a library you are using (are you linking with omniNotify?) must be > > > resolving the root POA. > > > > > > > I guess it must be the omniNotify library. The only reference to the POA > > in my test case was in the destructor. I had forgotten why it was there > > so I commented it out (see below) and tried again. I got the error shown > > at the bottom of the trace log (see farther below) since the library > > apparently resolved the POA and I was now failing to deactivate it. > > > > I am now uncertain as to whether I can make omniNotify not resolve the > > root POA when all I want to do is post a message. > > > > // try { > > // PortableServer::POA_ptr poa = RefUtils::POA(); > > // PortableServer::Servant serv = poa->reference_to_servant(_this()); > > // PortableServer::ObjectId_var oid = poa->servant_to_id(serv); > > // poa->deactivate_object(oid); > > // } > > // catch (...) {} // ignore any error during destroy call > > > > omniORB: Creating ref to remote: key > > target id : IDL:omg.org/CORBA/Object:1.0 > > most derived id: > > omniORB: Initial reference `NameService' resolved from configuration file. > > omniORB: AsyncInvoker: thread id = 1 has started. Total threads = 1 > > omniORB: Creating ref to remote: key > > target id : IDL:omg.org/CosNaming/NamingContext:1.0 > > most derived id: > > omniORB: Creating ref to remote: root<4> > > target id : IDL:omg.org/CORBA/Object:1.0 > > most derived id: IDL:att.com/AttNotification/EventChannel:1.0 > > omniORB: Creating ref to remote: root<4> > > target id : IDL:omg.org/CosNotifyChannelAdmin/EventChannel:1.0 > > most derived id: IDL:att.com/AttNotification/EventChannel:1.0 > > omniORB: Creating ref to remote: root<27425> > > target id : IDL:omg.org/CosNotifyChannelAdmin/SupplierAdmin:1.0 > > most derived id: IDL:att.com/AttNotification/SupplierAdmin:1.0 > > omniORB: Creating ref to remote: root<27426> > > target id : IDL:omg.org/CosNotifyChannelAdmin/ProxyConsumer:1.0 > > most derived id: IDL:att.com/AttNotification/StructuredProxyPushConsumer:1.0 > > omniORB: Creating ref to remote: root<27426> > > target id : IDL:omg.org/CosNotifyChannelAdmin/StructuredProxyPushConsumer:1.0 > > most derived id: IDL:att.com/AttNotification/StructuredProxyPushConsumer:1.0 > > omniORB: Initialising incoming endpoints. > > omniORB: Starting serving incoming endpoints. > > omniORB: Adding root<0> (activating) to object table. > > omniORB: Creating ref to local: root<0> > > target id : IDL:omg.org/CosNotifyComm/StructuredPushSupplier:1.0 > > most derived id: IDL:omg.org/CosNotifyComm/StructuredPushSupplier:1.0 > > omniORB: AsyncInvoker: thread id = 2 has started. Total threads = 2 > > omniORB: ERROR -- A servant has been deleted that is still activated. > > id: root<0> (active) > > > > > > > > > > _______________________________________________ > > omninotify-list mailing list > > omninotify-list@omniorb-support.com > > http://www.omniorb-support.com/mailman/listinfo/omninotify-list > > From bob.gruber@gmail.com Fri May 28 01:31:46 2004 Received: from mproxy.gmail.com ([216.239.56.246]) by apasphere.com with smtp (Exim 4.14) id 1BTVHl-0007g4-R1 for omninotify-list@omniorb-support.com; Fri, 28 May 2004 01:31:46 +0100 Received: by mproxy.gmail.com with SMTP id u15so79864cwc for ; Thu, 27 May 2004 17:31:38 -0700 (PDT) Received: by 10.11.122.66 with SMTP id u66mr355047cwc; Thu, 27 May 2004 17:31:38 -0700 (PDT) Message-ID: Date: Thu, 27 May 2004 20:31:38 -0400 From: Bob Gruber To: Mark Zimmerman Subject: Re: [omniNotify] Using omniNotify without creating endpoints In-Reply-To: <20040525193303.GA11197@io.frii.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040514164835.GB34360@io.frii.com> <200405181454.i4IEstr22413@grisby.dyndns.org> <20040521152424.GA60508@io.frii.com> <20040525193303.GA11197@io.frii.com> Cc: omninotify-list@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2004 00:31:46 -0000 No, I don't, sorry. You could ask Duncan if you compile omniORB with -g, what function should you set a breakpoint on so that you can figure out where the endpoint creation is occurring. -- Bob On Tue, 25 May 2004 13:33:03 -0600, Mark Zimmerman wrote: > > Yes, I just meant the COS library. Do you have any idea what might be > creating this (these) endpoint(s) and why? > > > On Tue, May 25, 2004 at 01:03:50PM -0400, Bob Gruber wrote: > > If this is a client, you should not link against the omniNotify > > library, just the COS library. Or did you mean the COS library? > > > > On Fri, 21 May 2004 09:24:25 -0600, Mark Zimmerman wrote: > > > > > > On Tue, May 18, 2004 at 03:54:55PM +0100, Duncan Grisby wrote: > > > > On Friday 14 May, Mark Zimmerman wrote: > > > > > > > > > I have a small program that does nothing but post a single message to > > > > > the omniNotify notification channel (from a push_supplier) and exit. > > > > > It works fine with a default configuration but I am trying to > > > > > understand why it insists on creating and serving incoming endpoints. > > > > > Unless I misunderstand the meaning of an incoming endpoint, it seems > > > > > to me that it doesn't need one. > > > > > > > > > > However, when I include 'endPointNoListen = giop:tcp::' in the > > > > > configuration, it fails: > > > > > > > > That doesn't do what you think it does. endPointNoListen asks the ORB > > > > to publish the given endpoint in IORs, without listening on it. For > > > > that to work, you have to give the full details of the endpoint, since > > > > there is no real endpoint to get the details from. Anyway, it's not a > > > > way to stop your program from listening. > > > > > > > > [...] > > > > > With endPointNoListen excluded, the program works but the endpoints > > > > > are never used (I think). I have set 'serverTransportRule = * none' > > > > > which, I believe, will prevent them from accepting connections. > > > > > > > > > > Is there something in omniNotify that requires endpoint creation in > > > > > this context? Is there a way to avoid this? > > > > > > > > The incoming endpoints are initialised when you resolve the root POA > > > > (or get a reference to the BOA). If the code doesn't every get hold of > > > > the POA, the endpoints are not initialised. Something in your code, or > > > > a library you are using (are you linking with omniNotify?) must be > > > > resolving the root POA. > > > > > > > > > > I guess it must be the omniNotify library. The only reference to the POA > > > in my test case was in the destructor. I had forgotten why it was there > > > so I commented it out (see below) and tried again. I got the error shown > > > at the bottom of the trace log (see farther below) since the library > > > apparently resolved the POA and I was now failing to deactivate it. > > > > > > I am now uncertain as to whether I can make omniNotify not resolve the > > > root POA when all I want to do is post a message. > > > > > > // try { > > > // PortableServer::POA_ptr poa = RefUtils::POA(); > > > // PortableServer::Servant serv = poa->reference_to_servant(_this()); > > > // PortableServer::ObjectId_var oid = poa->servant_to_id(serv); > > > // poa->deactivate_object(oid); > > > // } > > > // catch (...) {} // ignore any error during destroy call > > > > > > omniORB: Creating ref to remote: key > > > target id : IDL:omg.org/CORBA/Object:1.0 > > > most derived id: > > > omniORB: Initial reference `NameService' resolved from configuration file. > > > omniORB: AsyncInvoker: thread id = 1 has started. Total threads = 1 > > > omniORB: Creating ref to remote: key > > > target id : IDL:omg.org/CosNaming/NamingContext:1.0 > > > most derived id: > > > omniORB: Creating ref to remote: root<4> > > > target id : IDL:omg.org/CORBA/Object:1.0 > > > most derived id: IDL:att.com/AttNotification/EventChannel:1.0 > > > omniORB: Creating ref to remote: root<4> > > > target id : IDL:omg.org/CosNotifyChannelAdmin/EventChannel:1.0 > > > most derived id: IDL:att.com/AttNotification/EventChannel:1.0 > > > omniORB: Creating ref to remote: root<27425> > > > target id : IDL:omg.org/CosNotifyChannelAdmin/SupplierAdmin:1.0 > > > most derived id: IDL:att.com/AttNotification/SupplierAdmin:1.0 > > > omniORB: Creating ref to remote: root<27426> > > > target id : IDL:omg.org/CosNotifyChannelAdmin/ProxyConsumer:1.0 > > > most derived id: IDL:att.com/AttNotification/StructuredProxyPushConsumer:1.0 > > > omniORB: Creating ref to remote: root<27426> > > > target id : IDL:omg.org/CosNotifyChannelAdmin/StructuredProxyPushConsumer:1.0 > > > most derived id: IDL:att.com/AttNotification/StructuredProxyPushConsumer:1.0 > > > omniORB: Initialising incoming endpoints. > > > omniORB: Starting serving incoming endpoints. > > > omniORB: Adding root<0> (activating) to object table. > > > omniORB: Creating ref to local: root<0> > > > target id : IDL:omg.org/CosNotifyComm/StructuredPushSupplier:1.0 > > > most derived id: IDL:omg.org/CosNotifyComm/StructuredPushSupplier:1.0 > > > omniORB: AsyncInvoker: thread id = 2 has started. Total threads = 2 > > > omniORB: ERROR -- A servant has been deleted that is still activated. > > > id: root<0> (active) > > > > > > > > > > > > > > > _______________________________________________ > > > omninotify-list mailing list > > > omninotify-list@omniorb-support.com > > > http://www.omniorb-support.com/mailman/listinfo/omninotify-list > > > > From frederic.prin@silvaco.com Fri May 28 14:05:09 2004 Received: from portal.silvaco.com ([192.73.228.4]) by apasphere.com with esmtp (Exim 4.14) id 1BTh2q-0000QW-Nw; Fri, 28 May 2004 14:05:09 +0100 Received: from sbay.silvaco.com (sbay.Silvaco.COM [10.1.5.1]) by portal.silvaco.com (8.11.6+Sun/8.11.6) with ESMTP id i4SD53c08049; Fri, 28 May 2004 06:05:03 -0700 (PDT) Received: from grenoble.silvaco.com (grenoble [10.66.5.1]) by sbay.silvaco.com (8.9.3+Sun/8.9.3) with ESMTP id GAA03838; Fri, 28 May 2004 06:05:02 -0700 (PDT) Received: from parrachee (parrachee [10.66.10.32]) by grenoble.silvaco.com (8.12.2+Sun/8.12.2) with ESMTP id i4SD50cc016493; Fri, 28 May 2004 15:05:01 +0200 (CEST) From: "Frederic Prin" To: Date: Fri, 28 May 2004 15:05:04 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <002d01c3be1a$a2e464d0$733acf87@PCSPOO> Importance: Normal Cc: omniorb-list@omniorb-support.com Subject: [omniNotify] Memory Leaks (both omniORB and omniNotify) X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2004 13:05:10 -0000 Hello, While using omniNotify2.0beta with omniORB-4.0.3 on solaris 2.8, I notice that notifd grows each time a push_structured_event is sent. I use sdtprocess to track memory usage. I purify notifd and found some PLK. - Do you experience some memory leaks in notifd ? - Do the latest 2.0 Release fix some memory leaks ? - Do the latest omniORB snapshot fix some memory leaks ? Thank you very much for your help. Fred This is the purify message (I now it's PLK not MLK but I seems to be true) PLK: 11536 bytes potentially leaked in 412 blocks This memory was allocated from: malloc [rtlib.o] c2n6Fi_Pv___1 [libCrun.so.1] void*operator new(unsigned) [rtlib.o] void*operator new[](unsigned) [rtlib.o] IOP::TaggedProfile*_CORBA_Sequence::allocbuf(unsigne d long) [libomniORB4_4_0_3_R.a] void _CORBA_Sequence::copybuffer(unsigned long) [libomniORB4_4_0_3_R.a] Block of 28 bytes (412 times); last block at 0x147c0d0 or PLK: 3592 bytes potentially leaked at 0xed7940 This memory was allocated from: malloc [rtlib.o] c2n6Fi_Pv___1 [libCrun.so.1] void*operator new(unsigned) [rtlib.o] void*operator new[](unsigned) [rtlib.o] EventChannel_i::EventChannel_i(EventChannelFactory_i*,FilterFactory_i*,c onst CosNotification::PropertySeq&,const CosNotification::PropertySeq&,RDI_ServerQoS*,const long&) [EventChannel_i.cc:123] // Initialize all statistics-related structures => _thread_stats = new RDI_ThStat[RDI_TH_ARRAY_SZ]; RDI_AssertAllocThrowNo(_thread_stats, "Memory allocation failed - RDI_ThStat object\n"); for (unsigned int id = 0; id < RDI_TH_ARRAY_SZ; id++) { _thread_stats[id]._num_rdi_match = 0; EventChannel_i*EventChannelFactory_i::_create_channel(long&) [EventChannel_i.cc:1811] From vishwanath@scorpeonet.com Mon May 31 09:26:54 2004 Received: from fci.01.dios.net ([12.183.13.106] helo=mail.lookworld.com ident=FCI) by apasphere.com with smtp (Exim 4.14) id 1BUi8D-00074k-Lh for omninotify-list@omniorb-support.com; Mon, 31 May 2004 09:26:54 +0100 Received: from lookworld (12.183.14.3) by LOOKWORLD (MailMax 4. 8. 3. 0) with ESMTP id 25982324 for omninotify-list@omniorb-support.com; Mon, 31 May 2004 04:36:39 -0400 EDT From: vishwanath@scorpeonet.com To: omninotify-list@omniorb-support.com Date: Mon, 31 May 2004 04:36:39 -0400 X-Mailer: Mailmax Webmail Message-Id: Subject: [omniNotify] Issues with the new VC compiler X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2004 08:26:54 -0000 Hi, I wanted to know what are the issues with the new VC compilers when using omni-orb. If there's some tweaking required to get away with it, please let me know the same. Regards, Vishwanath _______________________________________________________________________________ This E-Mail was sent with WebMail System. From frederic.prin@silvaco.com Tue Jun 01 13:39:37 2004 Received: from portal.silvaco.com ([192.73.228.4]) by apasphere.com with esmtp (Exim 4.14) id 1BV8YL-0001l0-Ci; Tue, 01 Jun 2004 13:39:37 +0100 Received: from sbay.silvaco.com (sbay.Silvaco.COM [10.1.5.1]) by portal.silvaco.com (8.11.6+Sun/8.11.6) with ESMTP id i51CdZc12084; Tue, 1 Jun 2004 05:39:35 -0700 (PDT) Received: from grenoble.silvaco.com (grenoble [10.66.5.1]) by sbay.silvaco.com (8.9.3+Sun/8.9.3) with ESMTP id FAA24116; Tue, 1 Jun 2004 05:39:34 -0700 (PDT) Received: from parrachee (parrachee [10.66.10.32]) by grenoble.silvaco.com (8.12.2+Sun/8.12.2) with ESMTP id i51CdXcc008835; Tue, 1 Jun 2004 14:39:33 +0200 (CEST) From: "Frederic Prin" To: Date: Tue, 1 Jun 2004 14:39:39 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <134a01c3be36$8a6c2340$180a420a@bargy> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: omniorb-list@omniorb-support.com Subject: [omniNotify] notifd supported QoS settings X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2004 12:39:38 -0000 Hi, Do the new omniNotify2.0 release supports more QoS settings than those noted on the config.cfg (see extract below) file for notifd ? In particular, is the "Timeout" supported now ? Thank you Fred ---config.cfg----------------------------------------------------------- ---------- # NOTE: the current notifd implementation does NOT support all QoS # settings. In particular, it only supports the following: # EventReliability 0 # ConnectionReliability 0 # StartTimeSupported 0 # StopTimeSupported 0 # Note -- PacingInterval can be set programmatically to any # TimeBase::TimeT value (units = 100s of nanoseconds). Here you # set number of MILLISECONDS, e.g., a value of 1000 means send a batch # roughly every 1 second (or when MaxBatchSize is reached). ... Timeout 0 From frederic.prin@silvaco.com Wed Jun 02 09:50:16 2004 Received: from portal.silvaco.com ([192.73.228.4]) by apasphere.com with esmtp (Exim 4.14) id 1BVRRw-0004Jl-2f; Wed, 02 Jun 2004 09:50:16 +0100 Received: from sbay.silvaco.com (sbay.Silvaco.COM [10.1.5.1]) by portal.silvaco.com (8.11.6+Sun/8.11.6) with ESMTP id i528oBc29151; Wed, 2 Jun 2004 01:50:11 -0700 (PDT) Received: from grenoble.silvaco.com (grenoble [10.66.5.1]) by sbay.silvaco.com (8.9.3+Sun/8.9.3) with ESMTP id BAA19527; Wed, 2 Jun 2004 01:50:10 -0700 (PDT) Received: from parrachee (parrachee [10.66.10.32]) by grenoble.silvaco.com (8.12.2+Sun/8.12.2) with ESMTP id i528o9cc027176; Wed, 2 Jun 2004 10:50:09 +0200 (CEST) From: "Frederic Prin" To: Date: Wed, 2 Jun 2004 10:50:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <134a01c3be36$8a6c2340$180a420a@bargy> Cc: omniorb-list@omniorb-support.com Subject: [omniNotify] omniNotify cfg file (QoS values) X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2004 08:50:16 -0000 Hi all, Is there someone that uses the omniNotify (notifd) Notification Service ? I'm trying to fine tune the cfg file regarding the notifd memory usage and I need some help! Is anybody knows the maximum values for these QoS: QueueGCPeriod 30 And ObjectGCPeriod 600 DeadChanInterval 0 DeadAdminInterval 0 DeadConProxyInterval 0 DeadOtherProxyInterval 600 DeadFilterInterval 0 Is nobody has the answer, I will really appreciate a global opinion on omniNotify. (In particular the notifd daemon.) Or if you don't use omniNotify, what kind of asynchronous event messaging features do you use instead ? (omniEvents for example or something of your own) Thanks in advance Fred From tvedt@noao.edu Wed Jun 02 16:45:42 2004 Received: from realvnc.com ([213.239.45.162]) by apasphere.com with esmtp (Exim 4.14) id 1BVXvx-0005Pp-PY for omninotify-list@www.omniorb-support.com; Wed, 02 Jun 2004 16:45:42 +0100 Received: from noao.edu (astronomyinspanish.org [140.252.1.54]) by realvnc.com (8.11.6/8.11.6) with ESMTP id i52FjfE22089 for ; Wed, 2 Jun 2004 16:45:41 +0100 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on noao.edu X-Spam-Status: No, hits=-4.9 required=4.5 tests=AWL, BAYES_00 autolearn=ham version=2.61 X-Spam-Level: X-TFF-CGPSA-Version: 1.2.7 X-TFF-CGPSA-Filter: Scanned Received: from dorado.tuc.noao.edu ([140.252.38.7] verified) by noao.edu (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 12241053; Wed, 02 Jun 2004 08:45:39 -0700 Received: from dorado.tuc.noao.edu (localhost [127.0.0.1]) by dorado.tuc.noao.edu (8.12.8/8.12.5) with ESMTP id i52FiJAI007055; Wed, 2 Jun 2004 08:44:19 -0700 Received: (from tvedt@localhost) by dorado.tuc.noao.edu (8.12.8/8.12.8/Submit) id i52FiIDJ007053; Wed, 2 Jun 2004 08:44:18 -0700 X-Authentication-Warning: dorado.tuc.noao.edu: tvedt set sender to tvedt@noao.edu using -f Subject: Re: [omniNotify] omniNotify cfg file (QoS values) From: Janet Tvedt To: Frederic Prin , omniNotify In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: National Solar Observatory Message-Id: <1086191058.16529.391.camel@dorado.tuc.noao.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 02 Jun 2004 08:44:18 -0700 Cc: X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2004 15:45:42 -0000 On Wed, 2004-06-02 at 01:50, Frederic Prin wrote: > Hi all, > > Is there someone that uses the omniNotify (notifd) Notification Service > ? > > I'm trying to fine tune the cfg file regarding the notifd memory usage > and I need some help! > > Is anybody knows the maximum values for these QoS: > QueueGCPeriod 30 > And > ObjectGCPeriod 600 > DeadChanInterval 0 > DeadAdminInterval 0 > DeadConProxyInterval 0 > DeadOtherProxyInterval 600 > DeadFilterInterval 0 > > > > > Is nobody has the answer, I will really appreciate a global opinion on > omniNotify. > (In particular the notifd daemon.) > Or if you don't use omniNotify, what kind of asynchronous event > messaging features do you use instead ? > (omniEvents for example or something of your own) > > Thanks in advance > > Fred > > > > > > > > > _______________________________________________ > omninotify-list mailing list > omninotify-list@omniorb-support.com > http://www.omniorb-support.com/mailman/listinfo/omninotify-list Fred, I have been using notifd for several years now and am quite pleased with the performance. Initially we had problems with memory growth and occasional lockups. Bob Gruber fixed those problems. I am not using the latest version however since I don't recall the Deadxxx QoS parameters. I assume that these specify when notifd should perform some sort of cleanup operation. I would use the default values unless you have a good reason to change them. Several years ago I tried using several event services including omniEvents. None were adequate for my application. The primary problem I had was with scalability. omniNotify was the first notification service I evaluated. It works for us so I have not had a need to investigate others. Hope this helps a little. -- Janet Tvedt National Solar Observatory Tucson, Arizona From bob.gruber@gmail.com Wed Jun 02 17:46:28 2004 Received: from mproxy.gmail.com ([216.239.56.249]) by apasphere.com with smtp (Exim 4.14) id 1BVYsl-0005X2-Rp for omninotify-list@omniorb-support.com; Wed, 02 Jun 2004 17:46:28 +0100 Received: by mproxy.gmail.com with SMTP id u33so3926cwc for ; Wed, 02 Jun 2004 09:46:20 -0700 (PDT) Received: by 10.11.98.15 with SMTP id v15mr501173cwb; Wed, 02 Jun 2004 09:46:20 -0700 (PDT) Message-ID: Date: Wed, 2 Jun 2004 12:46:20 -0400 From: Bob Gruber To: Frederic Prin Subject: Re: [omniNotify] omniNotify cfg file (QoS values) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Cc: omniorb-list@omniorb-support.com, omninotify-list@omniorb-support.com X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2004 16:46:28 -0000 Frederic, you have asked a few questions recently, let me try to answer all of them. The first was about memory leaks, and another question was about object GC config params. As I think you may have figured out, the omniNotify daemon (notifd) has a global event queue that it cleans up based on configuration params. So each additional event will cause some small memory growth, until a GC time interval elapses, at which point it is pruned. You can control the event GC period with QueueGCPeriod, and you can also set MaxQueueLength to a non-zero value if you want to put an upper limit on the queue size. In addition to event garbage collection (GC), there are also some object GC configuration parameters that control how notifd attempts to get rid of 'dead' objects, i.e., objects that appear to no longer be in use. Clients of the notification service cause the service to construct various helper objects: channels, admin objects, proxy objects, and filters, and these clients do not always properly clean up after themselves, which can cause old helper objects to stay around even after they are no longer used. I think I have actually done pretty good job describing the object GC params in the config file. If you have any specific questions about them, please send them to me directly and I will try to clarify. Your final question was about Timeout. Timeout is used in conjunction with the OrderPolicy and DiscardPolicy QoS params. The former controls how events are delivered, while the latter control which event is discarded if the MaxQueueLength limit is hit and RejectNewEvents is 1. QoS properties can be set at the notifd, channel, admin, proxy level. A default Timeout value can be set as a QoS property, while specific Timeouts can ALSO be set on a per-event basis by including a Timeout value in each event. If OrderPolicy is set to DeadlineOrder, then events are 'sorted' for delivery using (arrival_time + Timeout). If OrderPolicy is set to AnyOrder or FifoOrder, they are sorted by arrival time. If set to PriorityOrder, they are sorted by Priority. Note that the timeout sorting is a relative sort. The notification spec includes a way to specify absolute start and stop times for events, but omniNotify does not support this, as indicated by the params StartTimeSupported and StopTimeSupported which are both forced to be 0. When specifying how to do sorting for discard (DiscardPolicy), you can specify any of the OrderPolicy policies above, and also LifoOrder. Note that sorting policies only apply when multiple events destined for a given consumer are queued at a channel. If the channel 'keeps up' with event arrivals such that it has already delivered the Kth event before the (K+1)th event arrives at the channel, then sort policy does not come into play -- events are delivered in arrival order. OrderPolicy only matters if the channel has to decide which event to deliver next. -- Bob Gruber From Hostingweber@eyou.com Sat Jun 05 11:36:42 2004 Received: from [218.6.9.190] (helo=eyou.com) by apasphere.com with smtp (Exim 4.14) id 1BWYXa-0003Ro-6t for omninotify-list@omniorb-support.com; Sat, 05 Jun 2004 11:36:42 +0100 From: "Web" To: Sender: "Web" Mime-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Date: Sat, 5 Jun 2004 06:36:43 +0800 Content-Transfer-Encoding: 8bit Message-Id: Subject: [omniNotify] Re: BP Server X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Web List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2004 10:36:43 -0000 We offer Bullet

We offer Bullet-Proof dedicated servers:

Two IPs
512MB RAM DDR
PIIII
36 GB SCS
Dedicated 100 M fiber
Unlimited Data Transfer
Linux/Windows/FreeBSD
 

Three IPs
1024MB RAM DDR
PIIII / Two CPU
72 GB SCS
Dedicated 100 M fiber
Unlimited Data Transfer
Linux/Windows/FreeBSD
 

Dynamic IP
1024MB RAM DDR
PIIII / Two CPU
72 GB SCS
Dedicated 100 M fiber
Unlimited Data Transfer
Linux/Windows/FreeBSD
 

Price: No setup fee
          US$ 599.00/month

Price: No setup fee
          US$ 799.00/month

Price: No setup fee
          US$ 999.00/month

More Information

We can supply Target Email Addresses according to your requirements, and
send out Target Emails for you (Or Fax Broadcasting). 

For more information, contact us:Support@bbzb.com or Support@bzbb.com

Looking forward to serving you in the near future.

Cheers!

Mr Bell
Sales Support

****************************************************************************************
Receiving this email because you registered to receive special offers from us.
Please click here to off:Bell@aol.com?subject=off
****************************************************************************************

From frederic.prin@silvaco.com Fri Jun 11 14:51:02 2004 Received: from portal.silvaco.com ([192.73.228.4]) by apasphere.com with esmtp (Exim 4.14) id 1BYmQw-0001Oc-BX; Fri, 11 Jun 2004 14:51:02 +0100 Received: from sbay.silvaco.com (sbay.Silvaco.COM [10.1.5.1]) by portal.silvaco.com (8.11.6+Sun/8.11.6) with ESMTP id i5BDoxc02154; Fri, 11 Jun 2004 06:50:59 -0700 (PDT) Received: from grenoble.silvaco.com (grenoble [10.66.5.1]) by sbay.silvaco.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14586; Fri, 11 Jun 2004 06:50:58 -0700 (PDT) Received: from parrachee (parrachee [10.66.10.32]) by grenoble.silvaco.com (8.12.2+Sun/8.12.2) with ESMTP id i5BDov0l008726; Fri, 11 Jun 2004 15:50:57 +0200 (CEST) From: "Frederic Prin" To: Date: Fri, 11 Jun 2004 15:51:13 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EB_01C44FCB.EC848640" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: omniorb-list@omniorb-support.com Subject: [omniNotify] Deleting a StructuredPushConsumer X-BeenThere: omninotify-list@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: The omniNotify Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 13:51:02 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00EB_01C44FCB.EC848640 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I get an error message when deleting a StructuredPushConsumer instance that I create like this: event_observer =3D new MyObserver ; /* My observer inherit from StructuredPushConsumer and overide the push_structured_event method*/ CosNotifyComm::StructuredPushConsumer_var push_consumer ; CosNotifyChannelAdmin::StructuredProxyPushSupplier_var structured_proxy ; push_consumer =3D eventObserver->_this() ; structured_proxy =3D { /* pseudo code */ generic_proxy =3D consumer_admin =09 ->obtain_notification_push_supplier( CosNotifyChannelAdmin::STRUCTURED_EVENT,=20 =09 proxy_id ) ; structured_proxy =3D=20 =09 CosNotifyChannelAdmin::StructuredProxyPushSupplier::_narrow( generic_proxy ) ; =09 structured