From owner-cougaar-developers@cougaar.org Wed Jan 31 01:43:00 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id BAA08453 for cougaar-developers-outgoing; Wed, 31 Jan 2001 01:43:00 -0500 Received: from x_serv_2.dsta.gov.sg ([202.42.198.37]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id BAA08450 for ; Wed, 31 Jan 2001 01:42:57 -0500 Received: from xpress.dsta.gov.sg (XPRESS [202.42.198.52]) by x_serv_2.dsta.gov.sg with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id DDZR1FYA; Wed, 31 Jan 2001 14:42:17 +0800 Received: by XPRESS with Internet Mail Service (5.5.2650.21) id ; Wed, 31 Jan 2001 14:29:19 +0800 Message-ID: <9F70B25D4804D411ACF300508B08F126142D85@XPRESS> From: Lee Chew Hung To: "'cougaar-developers@cougaar.org'" Subject: Standards Date: Wed, 31 Jan 2001 14:29:18 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08B4F.23DCB81E" Sender: owner-cougaar-developers@cougaar.org Precedence: bulk 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_01C08B4F.23DCB81E Content-Type: text/plain Hello, Does anyone know if cougaar follows any standards like the FIPA specifications? Are there plans for cougaar to conform to any standards? Thanks and regards. ------_=_NextPart_001_01C08B4F.23DCB81E Content-Type: text/html Content-Transfer-Encoding: quoted-printable Standards

Hello,

Does anyone know if cougaar follows any standards = like the FIPA specifications?  Are there plans for cougaar to = conform to any standards?

Thanks and regards.

------_=_NextPart_001_01C08B4F.23DCB81E-- --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Wed Jan 31 18:47:59 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id SAA09060 for cougaar-developers-outgoing; Wed, 31 Jan 2001 18:47:59 -0500 Received: from mailgate1.darpa.mil (mailgate1.darpa.mil [192.5.18.61]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id SAA09057 for ; Wed, 31 Jan 2001 18:47:57 -0500 Received: from mailhub1.darpa.mil (mailhub1.darpa.mil [158.63.2.41]) by mailgate1.darpa.mil (8.10.1/8.10.1) with ESMTP id f0VNhjY24464; Wed, 31 Jan 2001 18:43:45 -0500 (EST) Received: from MSX-SMTP2.darpa.mil (msx-smtp2.darpa.mil [158.63.1.61]) by mailhub1.darpa.mil (8.9.1/8.9.1) with SMTP id SAA22356; Wed, 31 Jan 2001 18:43:53 -0500 (EST) Received: from 158.63.1.61 by MSX-SMTP2.darpa.mil (InterScan E-Mail VirusWall NT); Wed, 31 Jan 2001 18:47:25 -0500 (Eastern Standard Time) Received: by MSX-SMTP2.darpa.mil with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Jan 2001 18:47:25 -0500 Message-ID: From: tcarrico To: Lee Chew Hung Cc: "'cougaar-developers@cougaar.org'" Subject: RE: Standards Date: Wed, 31 Jan 2001 18:47:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08BE0.25C27510" Sender: owner-cougaar-developers@cougaar.org Precedence: bulk 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_01C08BE0.25C27510 Content-Type: text/plain; charset="iso-8859-1" Lee: Cougaar is not currently FIPA compliant. We have been watching the evolution of the FIPA standards and know what it will take to make it compliant, but due to other schedule constraints and the continued evolution of the FIPA definition, we have elected to hold off on any such move for the time being. We have not set a date, but I would look at Summer 2002 at the earliest. It would be about a months worth of work to achieve compliancy according to our estimates. In addition to tracking FIPA compliancy, we are also monitoring the progress of the DAML activities and expect we will incorporate DAML compatibility at that time as well. Todd -----Original Message----- From: Lee Chew Hung [mailto:LEE_Chew_Hung@DSTA.GOV.SG] Sent: Wednesday, January 31, 2001 1:29 AM To: 'cougaar-developers@cougaar.org' Subject: Standards Hello, Does anyone know if cougaar follows any standards like the FIPA specifications? Are there plans for cougaar to conform to any standards? Thanks and regards. ------_=_NextPart_001_01C08BE0.25C27510 Content-Type: text/html; charset="iso-8859-1" Standards
Lee:
 
Cougaar is not currently FIPA compliant.  We have been watching the evolution of the FIPA standards
and know what it will take to make it compliant, but due to other schedule constraints and the continued
evolution of the FIPA definition, we have elected to hold off on any such move for the time being.  We
have not set a date, but I would look at Summer 2002 at the earliest.  It would be about a months worth of
work to achieve compliancy according to our estimates.
 
In addition to tracking FIPA compliancy, we are also monitoring the progress of the DAML activities
and expect we will incorporate DAML compatibility at that time as well.
 
Todd
-----Original Message-----
From: Lee Chew Hung [mailto:LEE_Chew_Hung@DSTA.GOV.SG]
Sent: Wednesday, January 31, 2001 1:29 AM
To: 'cougaar-developers@cougaar.org'
Subject: Standards

Hello,

Does anyone know if cougaar follows any standards like the FIPA specifications?  Are there plans for cougaar to conform to any standards?

Thanks and regards.

------_=_NextPart_001_01C08BE0.25C27510-- --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Thu Feb 8 10:18:36 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id KAA15634 for cougaar-developers-outgoing; Thu, 8 Feb 2001 10:18:36 -0500 Received: from portal.east.saic.com (portal.east.saic.com [198.151.13.15]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with SMTP id KAA15631 for ; Thu, 8 Feb 2001 10:18:35 -0500 Received: from mclmx.saic.com by portal.east.saic.com via smtpd (for alp-61.alp.isotic.org [4.22.165.61]) with SMTP; 8 Feb 2001 15:18:35 UT Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com; Thu, 8 Feb 2001 10:18:10 -0500 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVIEG 2.1 bld 63) with SMTP id M2001020810135203005 for ; Thu, 08 Feb 2001 10:13:52 -0500 Received: by mcl-its-exbh01.saic.com with Internet Mail Service (5.5.2650.21) id <1GC47GDG>; Thu, 8 Feb 2001 10:18:18 -0500 Message-Id: From: "Coleman, Paul" To: "'cougaar-developers@cougaar.org'" Subject: cougaar and Visual J++ Date: Thu, 8 Feb 2001 10:09:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-cougaar-developers@cougaar.org Precedence: bulk My name is Paul Coleman and I am possibly interested in using COUGAAR with Microsoft Visual J++. Do you know of any incompatibilities between Visual J++ / Microsoft JVM and COUGAAR? Thanks in advance. - Paul Coleman colemanp@saic.com --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Thu Feb 8 10:30:08 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id KAA15649 for cougaar-developers-outgoing; Thu, 8 Feb 2001 10:30:08 -0500 Received: from zima.bbn.com (ZIMA.BBN.COM [128.89.8.110]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id KAA15646 for ; Thu, 8 Feb 2001 10:30:08 -0500 Received: from ncombs (NCOMBS.BBN.COM [128.89.27.170]) by zima.bbn.com (8.9.3/8.9.3) with SMTP id KAA22873; Thu, 8 Feb 2001 10:30:03 -0500 (EST) Message-Id: <4.1.20010208102457.00d29c70@zima.bbn.com> X-Sender: ncombs@zima.bbn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 08 Feb 2001 10:30:47 -0500 To: "Coleman, Paul" , "'cougaar-developers@cougaar.org'" From: Nathan Combs Subject: Re: cougaar and Visual J++ In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-cougaar-developers@cougaar.org Precedence: bulk At 10:09 AM 2/8/01 -0500, Coleman, Paul wrote: > >My name is Paul Coleman and I am possibly interested in using COUGAAR with >Microsoft Visual J++. Do you know of any incompatibilities between Visual >J++ / Microsoft JVM and COUGAAR? > i don't believe microsoft JVM supports more recent JDK versions (e.g. > 1.2) which would be required. http://support.microsoft.com/support/kb/articles/Q243/0/22.ASP > NOTE: The Microsoft virtual machine (Microsoft VM), does not support JDK versions later than JDK 1.1.4. Packages must be found within or be > compatible with the JDK version 1.1.4. Nathan Combs ncombs@bbn.com BBN Technologies (617) 873-4495 10 Moulton Street (617) 873-2794 (fax) Cambridge, MA 02138 --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Fri Feb 9 10:49:08 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id KAA16641 for cougaar-developers-outgoing; Fri, 9 Feb 2001 10:49:08 -0500 Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id KAA16638 for ; Fri, 9 Feb 2001 10:48:37 -0500 X-Envelope-Sender-Is: Martin.Schneider@mchp.siemens.de (at relayer david.siemens.de) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.0/8.11.0) with ESMTP id f19FcMu09397 for ; Fri, 9 Feb 2001 16:38:22 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.1/8.11.1) with ESMTP id f19FcM724962462 for ; Fri, 9 Feb 2001 16:38:22 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2448.0) id <1K5R49AJ>; Fri, 9 Feb 2001 16:39:04 +0100 Message-ID: <12D31B803B18D4119958009027FD42B8148365@mchp952a.mch.sbs.de> From: Schneider Martin To: "'cougaar-developers@cougaar.org'" Subject: Question about Message Transport Date: Fri, 9 Feb 2001 16:38:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-cougaar-developers@cougaar.org Precedence: bulk Hello there! I'm a newbie to Cougaar and in the moment I'm reading a lot and trying to understand it. Since there are some pages under construction (for instance the search page) I don't find everything I need to know. And so I have a question about message transport in CougaarSE: default is RMIMessageTransport. OK. What other MessageTransports are already realized and which will be supported in the future? (e.g. http) thanks! Martin Schneider ================================================= Siemens AG CT IC 6 Intelligent Autonomous Systems tel.: +49 89 636-44257 fax.: +49 89 636-41423 e-mail: Martin.Schneider@mchp.siemens.de --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Fri Feb 9 14:33:09 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id OAA16859 for cougaar-developers-outgoing; Fri, 9 Feb 2001 14:33:09 -0500 Received: from mail.graphtronics.net (mail.graphtronics.net [216.28.32.93]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with SMTP id OAA16856 for ; Fri, 9 Feb 2001 14:33:08 -0500 Received: (qmail 5049 invoked from network); 9 Feb 2001 19:09:17 -0000 Received: from 209-164-211-83.telares.com (HELO regulusnt) (@209.164.211.83) by mail.graphtronics.net with SMTP; 9 Feb 2001 19:09:17 -0000 Message-ID: <005401c092cf$1bb92d20$3700000a@clarksweng.com> From: "Pat Clark" To: References: <12D31B803B18D4119958009027FD42B8148365@mchp952a.mch.sbs.de> Subject: Re: Question about Message Transport Date: Fri, 9 Feb 2001 14:32:57 -0500 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-cougaar-developers@cougaar.org Precedence: bulk Martin, My name is Pat Clark, I led the team developing the BooksOnLine advanced tutorial and some military applications of Cougaar. Cougaar started out using Voyager, a proprietary product, and moved to RMI in the last two years. There has been some talk of supporting CORBA, and the architecture leaves a nice slot to slip that in (and pulling RMI out), but I don't believe anyone's actually implemented it as a replacement transport. RMI will work transparently for you, as long as you're not required to communicate bidirectionally with masqueraded IP addresses. As long as all your agent machines have ip addresses that are accessible "outside" any firewalls, you don't even see RMI. All the plugin interfaces handle the inter-cluster communication transparently, you don't have to create remote objects, bind them to a registry name, or anything like that. The exception is if you have agents that are not visible to the net on which other agents communicate with them (i.e. they have private IP addresses, like 10.0.0.1, etc.). If Cluster A has a visible IP and Cluster B is masqueraded, normal communication (meaning task allocation, result propagation, etc.) can't occur, because A cannot initiate contact with B when he has something to communicate. In this case, B must poll A occasionally to see if there is anything available. He does this by tapping into A's http server, which Cougaar calls a PlanServerPlugin. Cluster A must have PlanServerProviders (PSPs) written which B can connect to via http protocol - PSPs are essentially Cougaar equivalent of servlets which the PlanServerPlugin (aka web server) administers. PSPs use the port 5555 by default, so B might connect to A.com:5555/Status.PSP, for example. If you download the BooksOnLine tutorial, you'll see examples of PSPs that both do read only actions on another cluster, and ones that send control input in to another cluster. If you download lesson 4, it'll give examples of all kinds, including end user PSPs and cluster-to-cluster PSPs (see ui.PSP_BolUI.java for the former and warehouse.PSP_CatalogSearch.java for the latter). Pat Clark Clark Software Engineering, Ltd. 5100 Springfield St. Suite 308 Dayton, OH 45431 937.256.7794 fax: 937.256.7842 patkclark@earthlink.net pkclark@clarksweng.com --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Thu Mar 8 08:27:24 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id IAA11079 for cougaar-developers-outgoing; Thu, 8 Mar 2001 08:27:24 -0500 Received: from ss3000e.cselt.it (ss3000e.cselt.it [163.162.41.5]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id IAA11076 for ; Thu, 8 Mar 2001 08:27:13 -0500 Received: from rabadan.cselt.it (rabadan.cselt.it [163.162.4.12]) by ss3000e.cselt.it (PMDF V5.2-31 #43137) with ESMTP id <0G9V004E1FPRL7@ss3000e.cselt.it> for cougaar-developers@cougaar.org; Thu, 8 Mar 2001 10:01:03 +0100 (MET) Received: by rabadan.cselt.it with Internet Mail Service (5.5.2650.21) id ; Thu, 08 Mar 2001 10:01:26 +0100 Received: from ibm9151.cs.columbia.edu (ibm9151.cselt.it [163.162.96.29]) by EXC2K01.cselt.it with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id F3BC0BS3; Thu, 08 Mar 2001 10:01:21 +0100 Content-return: allowed Date: Thu, 08 Mar 2001 10:01:20 +0100 From: Peppo Valetto Subject: constraining tasks wrt parent X-Sender: valetto@canal.psl.cs.columbia.edu (Unverified) To: cougaar-developers@cougaar.org Cc: valetto@cs.columbia.edu, ncombs@bbn.com Message-id: <5.0.2.1.0.20010308092649.02589148@EXC2K01.cselt.it> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Content-type: text/plain; charset="us-ascii"; format=flowed Sender: owner-cougaar-developers@cougaar.org Precedence: bulk Hi all, as a newbie to COUGAAR programming, I've gone through the basic tutorial exercises and I have now a couple of issues for which I need some "higher wisdom" First of all a preliminary question: in class SettableConstraintEvent the method setValue() takes 3 parameters from javadocs: setValue(double value, int constraintOrder, double slope) I do not understand how the "slope" parameter works and javadocs do not help me much (see below) slope - specifies the rate at which the score function degrades on the allowed side of the constraint. The disallowed side always has a failing score. Can you shed some light? How does the slope work here? Second: I have a trouble in setting correctly a constraint in the followign scenario Task T has preferences (start=0, end=12) and expands into T1, T2, T3, Constraint c1: T1 must end before T2 begins Constraint c2: T2 must end before T3 begins Constraint c3: T3 must end before T (its parent) ends (i.e. in my intention before 12) The purpose of Constraint c3 is as follows: say, the allocation of T2, T3, T4 and their duration cause T4 to end after 12. I would like the expander to reschedule the expansion of T1 among available assets to try to finish with T1 (and its expansion) before 12. Of course, in case instead T4 ends before 12, nothing should happen and everybody should be happy. This is my code for defining those constraints: // End(t1) must be before Start(t2) NewConstraint c1 = theLDMF.newConstraint(); c1.setConstrainingTask(t1); c1.setConstrainingAspect(AspectType.END_TIME); c1.setConstrainedTask(t2); c1.setConstrainedAspect(AspectType.START_TIME); c1.setConstraintOrder(Constraint.BEFORE); constraints.addElement(c1); // End(t2) must be before Start(t3) NewConstraint c2 = theLDMF.newConstraint(); c2.setConstrainingTask(t2); c2.setConstrainingAspect(AspectType.END_TIME); c2.setConstrainedTask(t3); c2.setConstrainedAspect(AspectType.START_TIME); c2.setConstraintOrder(Constraint.BEFORE); constraints.addElement(c2); // End(t3) must be before End(parent task) NewConstraint c3 = theLDMF.newConstraint(); c3.setConstrainingTask(new_wf.getParentTask()); c3.setConstrainingAspect(AspectType.END_TIME); c3.setConstrainedTask(t3); c3.setConstrainedAspect(AspectType.END_TIME); c3.setConstraintOrder(Constraint.AFTER); constraints.addElement(c3); I had a case running my code that T3 ends at 8 (so should not violate c3) but it seemingly does according to COUGAAR since T (its parent) takes the value 8 of T3 as its own end somehow (I guess because it is after all the end time of the whole of its expansion) and therefore I end up with a situation like 8 AFTER 8 which is false. Can you help? Peppo --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Thu Mar 8 14:41:40 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id OAA11402 for cougaar-developers-outgoing; Thu, 8 Mar 2001 14:41:40 -0500 Received: from zima.bbn.com (ZIMA.BBN.COM [128.89.8.110]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id OAA11399 for ; Thu, 8 Mar 2001 14:41:35 -0500 Received: from ncombs (NCOMBS.BBN.COM [128.89.27.170]) by zima.bbn.com (8.9.3/8.9.3) with SMTP id OAA09774; Thu, 8 Mar 2001 14:41:31 -0500 (EST) Message-Id: <4.1.20010308141124.00cdbd90@zima.bbn.com> X-Sender: ncombs@zima.bbn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 08 Mar 2001 14:42:36 -0500 To: Peppo Valetto From: Nathan Combs Subject: Re: threading in plugins Cc: cougaar-developers@cougaar.org In-Reply-To: <5.0.2.1.0.20010308180238.02589148@EXC2K01.cselt.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-cougaar-developers@cougaar.org Precedence: bulk hi peppo -- At 06:24 PM 3/8/01 +0100, Peppo Valetto wrote: >Hi Nathan, >I know that, normally, plugins are not allocated a Java thread each, for >economy reasons I guess, >but they are scheduled by the PlugInScheduler of the cluster. >I am starting to write generic plugins that can be worklet-ized on the fly: >I've figured out a number of things about how to inject worklet code in a >plugin already. >However, the main worklet transport and mgmt class which I need to instantiate >to allow Cougaar plugins to send/receive/execute worklets (named WVM) >extends Thread. >In my early experiments I chose to instantiate a WorkletPlugIn as an >extension of SimplePlugIn and >the first thing I do in setupSubscriptions() is instantiating and starting >a WVM >but when I invoke start() on the WVM I get the following > >java.lang.IllegalThreadStateException > at java.lang.Thread.start(Native Method) > at coolets.WorkletPlugIn.setupSubscriptions(WorkletPlugIn.java:38) > >I strongly suspect this has to do with the threading model of SimplePlugIn >If so, am I forced to use the more heavyweight SINGLE_THREAD model? if i understand you -- i think u're right. i don't think you should be "starting" your WVM Plugin Thread. Load the plugin via Clsuter and let Clsuter manage start. >With what drawbacks? >What is your advice on these threading matters? > i believe all simpleplugins are executed round-robin (ala plugin scheduler) re-using single thread, this is adequate for most cases. its an efficiency to minimize cluster cpu footprint for most use cases. plugins which can't live with this threading model are free to run in their own private thread (as u point out, i think its SINGLE_THREAD). turns out must plugins can live in shared world well enough can't really think of many cases where this would be a liability 'cept where perhaps if you had a lot of plugins and had a steady stream of subsription items which you wanted to be processed to as close to the rate of publish as possible (vs. having them bunched up too much). my advice is always to start simple unless u know its not good enough ;-) thread model applies to the "execute()" execution of plugin (stimulated by incoming subscription) and not "background threads" which a plugin may launch and be running in background. >Another question is about when I can set or change subscriptions in a plugin. >setupSubscriptions() is executed once and for all at init time, right? >What if I later on I use subscribe() and/or unsubscribe()? I mean what is >the mechanism with which >a later subscription is accepted and processed in the cluster? When exactly >does the change >take effect? setupsubscription called once. you can dynamically set up subscriptions subscribe()/ unsubscribe() later, however, as the subscription setup is fairly expensive -- try to do it in setup once. turns out most plugins are comfortable with this. ie. they know a priori what they are interested in subscribing and are interested in it for the duration. an example exception might be some ui plugins which may need to handle ad hoc queries. -n. Nathan Combs ncombs@bbn.com BBN Technologies (617) 873-4495 10 Moulton Street (617) 873-2794 (fax) Cambridge, MA 02138 --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Sun Mar 18 22:46:24 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id WAA09417 for cougaar-developers-outgoing; Sun, 18 Mar 2001 22:46:24 -0500 Received: from x_serv_2.dsta.gov.sg ([202.42.198.37]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id WAA09414 for ; Sun, 18 Mar 2001 22:46:14 -0500 Received: from xpress.dsta.gov.sg (mail.dsta.gov.sg [202.42.198.52]) by x_serv_2.dsta.gov.sg with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FZ9NKPG0; Mon, 19 Mar 2001 11:45:32 +0800 Received: by XPRESS with Internet Mail Service (5.5.2650.21) id ; Mon, 19 Mar 2001 11:31:15 +0800 Message-ID: <9F70B25D4804D411ACF300508B08F126142D87@XPRESS> From: Lee Chew Hung To: "'cougaar-developers@cougaar.org'" Subject: Sending objects between clusters. Date: Mon, 19 Mar 2001 11:31:11 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B025.0D572A8E" Sender: owner-cougaar-developers@cougaar.org Precedence: bulk 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_01C0B025.0D572A8E Content-Type: text/plain; charset="iso-8859-1" Hello, I'm trying to write a simple cougaar society consisting of two clusters. How do I send my own object (eg. class Foo) between these two clusters without making Foo a task or an asset? Thanks in advance ------_=_NextPart_001_01C0B025.0D572A8E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sending objects between clusters.

Hello,

I'm trying to write a simple cougaar society = consisting of two clusters.  How do I send my own object (eg. = class Foo) between these two clusters without making Foo a task or an = asset?

Thanks in advance


------_=_NextPart_001_01C0B025.0D572A8E-- --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Mon Mar 19 10:45:09 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id KAA10045 for cougaar-developers-outgoing; Mon, 19 Mar 2001 10:45:09 -0500 Received: from zima.bbn.com (ZIMA.BBN.COM [128.89.8.110]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id KAA10042 for ; Mon, 19 Mar 2001 10:45:08 -0500 Received: from ncombs (NCOMBS.BBN.COM [128.89.27.170]) by zima.bbn.com (8.9.3/8.9.3) with SMTP id KAA03980; Mon, 19 Mar 2001 10:44:54 -0500 (EST) Message-Id: <4.1.20010319102720.00cee380@zima.bbn.com> X-Sender: ncombs@zima.bbn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 19 Mar 2001 10:46:12 -0500 To: Lee Chew Hung , "'cougaar-developers@cougaar.org'" From: Nathan Combs Subject: Re: Sending objects between clusters. In-Reply-To: <9F70B25D4804D411ACF300508B08F126142D87@XPRESS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-cougaar-developers@cougaar.org Precedence: bulk At 11:31 AM 3/19/01 +0800, Lee Chew Hung wrote: > > Hello, > > I'm trying to write a simple cougaar society consisting of two clusters. How > do I send my own object (eg. class Foo) between these two clusters without > making Foo a task or an asset? > > Thanks in advance you can write a "logic provider" plugin which will route objects published on Blackboard to remote clusters (ref. PDG for details on logic provider plugins). If you write/load your own logic providers, may want to provide your own implementation of: org.cougaar.domain.planning.ldm.Domain (again, consult PDG for how to do this). In terms of a minimalistic LP example, something like below can route a Foo instance to Cluster named "cid_MyFavoriteCluster" -n. public class SendRemoteRequestEnvelopeLogicProvider implements EnvelopeLogicProvider { private ALPPlanServesLogicProvider myPlan; private ClusterServesLogicProvider myCluster; public SendRemoteRequestEnvelopeLogicProvider( ALPPlanServesLogicProvider alpplan, ClusterServesLogicProvider cluster ) { myPlan = alpplan; myCluster = cluster; } public void execute(EnvelopeTuple m, Collection changeReports) { ClusterIdentifier source = myCluster.getUIDServer().getClusterIdentifier(); ClusterIdentifier dest = ClusterIdentifier.getClusterIdentifier("cid_MyFavoriteCluster"); // AAIDirective is an implementation of org.cougaar.domain.planning.ldm.plan.Directive // straightforward wrapper. // AAIDirective aaid = new AAIDirective( new Foo(), // Send Foo source, dest ); myPlan.sendDirective(aaid); } } } } } Nathan Combs ncombs@bbn.com BBN Technologies (617) 873-4495 10 Moulton Street (617) 873-2794 (fax) Cambridge, MA 02138 --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Thu Mar 22 14:45:23 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id OAA02764 for cougaar-developers-outgoing; Thu, 22 Mar 2001 14:45:23 -0500 Received: from zima.bbn.com (ZIMA.BBN.COM [128.89.8.110]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id OAA02761 for ; Thu, 22 Mar 2001 14:45:23 -0500 Received: from ncombs (NCOMBS.BBN.COM [128.89.27.170]) by zima.bbn.com (8.9.3/8.9.3) with SMTP id PAA08262; Thu, 22 Mar 2001 15:17:38 -0500 (EST) Message-Id: <4.1.20010322150540.00ce8170@zima.bbn.com> X-Sender: ncombs@zima.bbn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 22 Mar 2001 15:17:59 -0500 To: cougaar-developers@cougaar.org From: Nathan Combs Subject: Re: Sending objects between clusters. In-Reply-To: <4.1.20010319102720.00cee380@zima.bbn.com> References: <9F70B25D4804D411ACF300508B08F126142D87@XPRESS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-cougaar-developers@cougaar.org Precedence: bulk At 10:46 AM 3/19/01 -0500, Nathan Combs wrote: > > >you can write a "logic provider" plugin which will route objects published on >Blackboard to remote clusters (ref. PDG for details on logic provider >plugins). Hi - received some mail on my previous post, some public clarification. Previous msg presented a basic pattern for augmenting "Cluster messaging infrastructure" by adding logic providers to send arbitrary blackboard objects between clusters. An alternative pattern/possibilty would be to use the alternative "UI infrastructure" to communicate serialized objects between clusters. Consult PDG about the HTTP "LogPlanServers" and PSPs (servlets) and how they work, but the gist is that if you wanted to communicate objects between clusters WITHOUT modifying the cluster messaging mechanism, you could write a PlugIn which could open a URL conneciton to a receiving PSP at a remote cluster and either PUSHED or PULLED serialized objects over that connection. In the PULL case you'd need to have the receiving cluster open a connection back to the origin Cluster (to PSP) and either POLL, or WAIT on a Keep-Alive connection (see PDG for description of how keep-alives work). In the PUSH case, the origin Clsuter would open a connection to the target cluster and POST serialized object into PSP which can then add it to remote blackboard. Crudely, the trade-off is likely that the UI infrastructure may be easier to implmeent (esp if already familiar with writing plugins and psps) but will entail more connection overhead, and is likely a tad less efficient. The one trick is that the plugin will need to access the URL of the remote cluster (given its String name). This can be "looked-up" per snip below. import org.cougaar.lib.planserver.server.FDSProxy; import org.cougaar.lib.planserver.server.NameService; import org.cougaar.lib.planserver.server.ProxyMapAdapter; FDSProxy fds = new FDSProxy(); NameService myNameServiceProvider = new ProxyMapAdapter( fds ); // // base_url is URL to cluster LogPlanServer... need to append your target PSP and path // URL base_url = base_url = myNameServiceProvider.lookupURL(name); -n. Nathan Combs ncombs@bbn.com BBN Technologies (617) 873-4495 10 Moulton Street (617) 873-2794 (fax) Cambridge, MA 02138 --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Mon Mar 26 09:45:01 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id JAA00603 for cougaar-developers-outgoing; Mon, 26 Mar 2001 09:45:01 -0500 Received: from mailgate1.darpa.mil (mailgate1.darpa.mil [192.5.18.61]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id JAA00594; Mon, 26 Mar 2001 09:44:55 -0500 Received: from mailhub1.darpa.mil (mailhub1.darpa.mil [158.63.2.41]) by mailgate1.darpa.mil (8.10.1/8.10.1) with ESMTP id f2QFFAo21597; Mon, 26 Mar 2001 10:15:10 -0500 (EST) Received: from MSX-SMTP2.darpa.mil (msx-smtp2.darpa.mil [158.63.1.61]) by mailhub1.darpa.mil (8.9.1/8.9.1) with SMTP id KAA25771; Mon, 26 Mar 2001 10:15:37 -0500 (EST) Received: from 158.63.1.61 by MSX-SMTP2.darpa.mil (InterScan E-Mail VirusWall NT); Mon, 26 Mar 2001 10:19:11 -0500 (Eastern Standard Time) Received: by MSX-SMTP2.darpa.mil with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Mar 2001 10:19:11 -0500 Message-ID: From: tcarrico To: "'cougaar-information@cougaar.org'" , "'cougaar-developers@cougaar.org'" Subject: FW: Next Cougaar Plug-In Developer training April 10-12 Date: Mon, 26 Mar 2001 10:19:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-cougaar-developers@cougaar.org Precedence: bulk Reminder: Cougaar Training News The next Cougaar Plug-In Developer training course will be held April 10-12, 2001 at the DARPA TIC (Technology Integration Center) in Arlington, VA. Each session will run from 9:00AM to 5:00PM. The course is intended to train developers for writing Cougaar PlugIns and developing Cougaar clusters and societies. The course takes a experiential approach to training, mixing some presentation material with 'hands-on' programming work in the lab. We expect that each participant will, on completion of the training, have written and run a moderately complex Cougaar society of clusters and PlugIns that represent many of the key Cougaar architecture concepts and programming constructs. The following is the URL with directions and more information about the TIC : If you have a clearance, please forward your clearance to TIC security so that you can be unescorted during the course of the training. The DARPA Director requires all Foreign Nationals visiting DARPA facilities, which includes the TIC, to complete and submit a DARPA Foreign National Visit Request Information Form at least seven days before the visit date. For more information or to receive a copy of this form, please contact Charlotte Young at either (703) 526-6620 or cyoung@snap.org. In terms of prerequisites for the course, we expect that participants will be comfortable with programming and debugging in the Java programming language, and be familiar with standard Java packages (java.io, java.util, etc.). Further, we expect that participants will be comfortable with the Windows NT environment, including executing of batch files and editing text documents. Finally, and probably most significantly, we expect all participants in the course to have downloaded and familiarized themselves with the Cougaar PlugIn Developer's Guide (PDG), which is available at the Cougaar Open Source WebSite : . Breakfast and lunch will be provided. A small registration fee will be collected at the first session. No credit cards will be accepted. The fee will be determined and everyone who has signed up for the course will be notified of the amount via email several days in advance of the course. Please contact Steve Summers (ssummers@bbn.com) or Todd Carrico (tcarrico@darpa.mil) to register for the Cougaar training session. We look forward to seeing the participants at the Cougaar Training at the TIC on April 10 at 9:00 AM. ---------------------- -Michael E. Dyson -Schafer Corporation -4310 N. Fairfax Dr. -Suite 700 -Arlington, VA 22203 -(703) 516-6009 ---------------------- -Michael E. Dyson -Schafer Corporation -4310 N. Fairfax Dr. -Suite 700 -Arlington, VA 22203 -(703) 516-6009 --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@ultralog.net with the line "unsubscribe ul-everyone" in the BODY of the message. --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Sun Apr 22 20:44:34 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id UAA18583 for cougaar-developers-outgoing; Sun, 22 Apr 2001 20:44:34 -0400 Received: from pisces.starnet.gov.sg ([203.116.59.242]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with SMTP id UAA18580 for ; Sun, 22 Apr 2001 20:44:32 -0400 From: nkiabee@starnet.gov.sg Received: (from nobody@localhost) by pisces.starnet.gov.sg (8.10.1/8.10.1) id f3N0o5Q32697; Mon, 23 Apr 2001 08:50:05 +0800 X-Authentication-Warning: pisces.starnet.gov.sg: nobody set sender to nkiabee@starnet.gov.sg using -f To: Subject: Re: How to send messages to other clusters Message-ID: <987987005.3ae37c3d5692c@www.starnet.gov.sg> Date: Mon, 23 Apr 2001 08:50:05 +0800 Cc: References: <200104210519.BAA17232@alp-61.alp.isotic.org> In-Reply-To: <200104210519.BAA17232@alp-61.alp.isotic.org> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: StarNet Mail System (SMS) Sender: owner-cougaar-developers@cougaar.org Precedence: bulk Hi, I'm new to Cougaar and I have a question regarding sending messages to other clusters. Besides sending Task to other clusters. Is there other ways to send message to other clusters, something like a boardcast/multicast? Thanks. --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Mon Apr 23 07:20:13 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id HAA18867 for cougaar-developers-outgoing; Mon, 23 Apr 2001 07:20:13 -0400 Received: from zima.bbn.com (ZIMA.BBN.COM [128.89.8.110]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id HAA18864 for ; Mon, 23 Apr 2001 07:20:12 -0400 Received: from dslloaner (TC016.BBN.COM [128.33.238.16]) by zima.bbn.com (8.9.3/8.9.3) with SMTP id HAA05437; Mon, 23 Apr 2001 07:26:21 -0400 (EDT) Message-Id: <4.1.20010423064307.00be33f0@zima.bbn.com> X-Sender: ncombs@zima.bbn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 23 Apr 2001 07:06:28 -0400 To: nkiabee@starnet.gov.sg, From: nathan combs Subject: Re: How to send messages to other clusters Cc: In-Reply-To: <987987005.3ae37c3d5692c@www.starnet.gov.sg> References: <200104210519.BAA17232@alp-61.alp.isotic.org> <200104210519.BAA17232@alp-61.alp.isotic.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-cougaar-developers@cougaar.org Precedence: bulk At 08:50 AM 04/23/2001 +0800, nkiabee@starnet.gov.sg wrote: >Hi, >I'm new to Cougaar and I have a question regarding sending messages to >other clusters. >Besides sending Task to other clusters. Is there other ways to send >message to other clusters, something like a boardcast/multicast? > You can send messages via HTTP (from PlugIns to PSPs or vice versa). if you look at previous email in this archive (go to cougaar website / mail archive), more detail. should u need it, u can also use plugins to integrate other transport - example: experimentation underway using multicast from PlugIn (Sender) to Plugin (Receiver) for the fan-out (using cougaar normal message channel for the pt-2-pt return reply). A placeholder shingle can be seen at http://aai.bbn.com/cougaar/multicast.html -n --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Mon Apr 23 09:09:07 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id JAA18951 for cougaar-developers-outgoing; Mon, 23 Apr 2001 09:09:07 -0400 Received: from coopers.dsl.net (coopers.dsl.net [65.84.81.5]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id JAA18948 for ; Mon, 23 Apr 2001 09:09:07 -0400 Received: from regulus (65-84-104-66.client.dsl.net [65.84.104.66]) by coopers.dsl.net (Postfix) with SMTP id 6C63C1FD0A for ; Mon, 23 Apr 2001 09:10:15 -0400 (EDT) Message-ID: <008a01c0cbf7$9fa07e70$3700000a@regulus> From: "Pat Clark" To: References: <200104210519.BAA17232@alp-61.alp.isotic.org> <987987005.3ae37c3d5692c@www.starnet.gov.sg> Subject: Re: How to send messages to other clusters Date: Mon, 23 Apr 2001 09:16:35 -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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-cougaar-developers@cougaar.org Precedence: bulk Hi! Although the nomenclature is not real great (it's not really a TASK as you'd think of one), you can use a task pretty easily to do what you want. Make a task, maybe call it MessageTask, you can attach any kind of object you want as the indirect object of a preposition. Just make sure everyone you want to broadcast this to will have the class of this type in its class path, or some clusters won't be able to deserialize it. If you want to have a broadcast mechanism, you could make an expander that would generate a bunch of child tasks and allocate them to each of the clusters he knows about (from his assets list, where asset is instanceof organization and is not self). PSP method will work well, just might take you a little longer to do if you're just starting out with cougaar. Writing your own logic provider might be the most efficient, but is also going to be the most painful - you will have to learn a lot about the nitty-gritty internals of Cougaar, and could make your society not able to play with others who aren't using those logic providers. Pat Clark Clark Software Engineering, Ltd. 5100 Springfield St. Suite 308 Dayton, OH 45431 patkclark@earthlink.net 937.256.7794 Fax: 937.256.7842 --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Mon Apr 23 15:45:01 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id PAA19126 for cougaar-developers-outgoing; Mon, 23 Apr 2001 15:45:01 -0400 Received: from mail1.dh.trw.com (mail1.dh.trw.com [129.193.109.1]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id PAA19123 for ; Mon, 23 Apr 2001 15:45:00 -0400 Received: from trw.com ([129.193.108.38]) by mail1.dh.trw.com (Netscape Messaging Server 3.6) with ESMTP id AAA2DF8 for ; Mon, 23 Apr 2001 12:50:42 -0700 Message-ID: <3AE48791.82E1D17B@trw.com> Date: Mon, 23 Apr 2001 12:50:41 -0700 From: "Robert Manning" X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: cougaar-developers@cougaar.org Subject: Possible cluster initialization bug in Cougaar 7.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cougaar-developers@cougaar.org Precedence: bulk Hi All, I seem to have found a scenario where a cluster doesn't get loaded. On the day this occurred, I was able to repeat this several times. However, the next day I was not able to replicate the problem, so I'm not sure how real this problem is. I'd appreciate any comments, help, confirmation, etc. Here's the scenario: Consider a single node with 3 clusters, call them cluster A, B, and C. They are listed in that order in my node initialization file (call it TestNode.ini). At initialization time (in setupSubscriptions) in cluster B, the cluster opens a JDBC connection to a remote Oracle database to fetch some data. Suppose that for some reason, the machine with the Oracle db on it is down. Eventually the connection attempt times out, and this java.sql.SQLException is thrown: "java.sql.SQLException: Io exception: The Network Adapter could not establish the connection" After this exception is printed to the console, Cougaar reports that it has loaded cluster C, and finally reports "Plugins Loaded." Upon opening TASKS.PSP, cluster C cannot be found in the list of loaded clusters - even though Cougaar reports that it has been loaded. Cluster B is loaded. If I rearrange the clusters so that cluster B is *last* in my TestNode.ini file, then cluster C gets loaded, and cluster B throws the same exception noted above. Has anyone else ever observed a similar error? Robert -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Robert Manning TRW S&ITG - TS Sr. P/A, Engineer 310.764.9059 mailto:Robert.Manning@trw.com http://www.trw.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Wed May 2 14:38:21 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id OAA24718 for cougaar-developers-outgoing; Wed, 2 May 2001 14:38:21 -0400 Received: from mail1.dh.trw.com (mail1.dh.trw.com [129.193.109.1]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id OAA24715 for ; Wed, 2 May 2001 14:38:20 -0400 Received: from trw.com ([129.193.108.38]) by mail1.dh.trw.com (Netscape Messaging Server 3.6) with ESMTP id AAA25D for ; Wed, 2 May 2001 11:43:49 -0700 Message-ID: <3AF05563.D9165BD6@trw.com> Date: Wed, 02 May 2001 11:43:47 -0700 From: "Robert Manning" X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: cougaar-developers@cougaar.org Subject: Predicate question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cougaar-developers@cougaar.org Precedence: bulk Hi all, What could make a unary predicate-type class stop matching correctly? For example, consider this predicate from Cougaar exercise 4: class myProgrammersPredicate implements UnaryPredicate{ public boolean execute(Object o) { boolean ret = false; if (o instanceof Organization) { Organization org = (Organization)o; OrganizationPG orgPG = org.getOrganizationPG(); ret = orgPG.inRoles(Role.getRole("SoftwareDevelopment")); } return ret; } } Say you've put this class into it's own file and made it a public class within the same package you're working on. Say also that you're no longer looking for SoftwareDevelopment organizations that exist within your own cluster - they're coming from another cluster within the same node. For some reason, even though the subscription using this predicate is firing, it is not correctly matching the role of SoftwareDevelopment to the organization. Any ideas? Thanks :) -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Robert Manning TRW S&ITG - TS Sr. P/A, Engineer 310.764.9059 mailto:Robert.Manning@trw.com http://www.trw.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Wed May 2 15:21:11 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id PAA24749 for cougaar-developers-outgoing; Wed, 2 May 2001 15:21:11 -0400 Received: from mail1.dh.trw.com (mail1.dh.trw.com [129.193.109.1]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id PAA24746 for ; Wed, 2 May 2001 15:21:10 -0400 Received: from trw.com ([129.193.108.38]) by mail1.dh.trw.com (Netscape Messaging Server 3.6) with ESMTP id AAA40DE for ; Wed, 2 May 2001 12:26:55 -0700 Message-ID: <3AF05F7E.4D141AFF@trw.com> Date: Wed, 02 May 2001 12:26:54 -0700 From: "Robert Manning" X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "cougaar-developers@cougaar.org" Subject: Predicate question, clarified Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cougaar-developers@cougaar.org Precedence: bulk Hi, Thought I'd make this a bit clearer... what is happening, is that my subscription to this unary predicate is firing, the unary predicate is returning true, but when my execute() method fires in the plugin owning the subscription, the Organization that matched the predicate isn't in the list of elements (e.g. the java.util.Enumeration class contained in IncrementalSubscription). Either I'm doing something terribly wrong, or something is broken. Any Ideas? -------- Original Message -------- Subject: Predicate question Date: Wed, 02 May 2001 11:43:47 -0700 From: "Robert Manning" To: cougaar-developers@cougaar.org Hi all, What could make a unary predicate-type class stop matching correctly? For example, consider this predicate from Cougaar exercise 4: class myProgrammersPredicate implements UnaryPredicate{ public boolean execute(Object o) { boolean ret = false; if (o instanceof Organization) { Organization org = (Organization)o; OrganizationPG orgPG = org.getOrganizationPG(); ret = orgPG.inRoles(Role.getRole("SoftwareDevelopment")); } return ret; } } Say you've put this class into it's own file and made it a public class within the same package you're working on. Say also that you're no longer looking for SoftwareDevelopment organizations that exist within your own cluster - they're coming from another cluster within the same node. For some reason, even though the subscription using this predicate is firing, it is not correctly matching the role of SoftwareDevelopment to the organization. Any ideas? Thanks :) -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Robert Manning TRW S&ITG - TS Sr. P/A, Engineer 310.764.9059 mailto:Robert.Manning@trw.com http://www.trw.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Wed May 2 18:46:54 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id SAA24847 for cougaar-developers-outgoing; Wed, 2 May 2001 18:46:54 -0400 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id SAA24844 for ; Wed, 2 May 2001 18:46:50 -0400 Received: from bbn.com (ros-dun052-048.bbn.com [192.233.52.48]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA01042; Wed, 2 May 2001 18:47:48 -0400 (EDT) Message-ID: <3AF08ECC.E5905B49@bbn.com> Date: Wed, 02 May 2001 18:48:44 -0400 From: Bill Wright X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Robert Manning CC: "cougaar-developers@cougaar.org" Subject: Re: Predicate question, clarified References: <3AF05F7E.4D141AFF@trw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cougaar-developers@cougaar.org Precedence: bulk Sometimes you can get this behavior if you predicate tests an attribute that changes. In your example, it may be that the OrganizationPG changes, making the subscriptions behave in the way you notice. You might try making your predicate a DynamicUnaryPredicate instead of a UnaryPredicate and see if it makes a difference. Robert Manning wrote: > Hi, > > Thought I'd make this a bit clearer... what is happening, is that > my subscription to this unary predicate is firing, the unary predicate > is returning true, but when my execute() method fires in the plugin > owning the subscription, the Organization that matched the predicate > isn't in the list of elements (e.g. the java.util.Enumeration class > contained in IncrementalSubscription). Either I'm doing something > terribly wrong, or something is broken. Any Ideas? > > -------- Original Message -------- > Subject: Predicate question > Date: Wed, 02 May 2001 11:43:47 -0700 > From: "Robert Manning" > To: cougaar-developers@cougaar.org > > Hi all, > > What could make a unary predicate-type class stop matching correctly? > For example, consider this predicate from Cougaar exercise 4: > > class myProgrammersPredicate implements UnaryPredicate{ > public boolean execute(Object o) { > boolean ret = false; > if (o instanceof Organization) { > Organization org = (Organization)o; > OrganizationPG orgPG = org.getOrganizationPG(); > ret = orgPG.inRoles(Role.getRole("SoftwareDevelopment")); > } > return ret; > } > } > > Say you've put this class into it's own file and made it a public class > within the same package you're working on. Say also that you're no longer > looking for SoftwareDevelopment organizations that exist within your own > cluster - they're coming from another cluster within the same node. For > some reason, even though the subscription using this predicate is firing, > it is not correctly matching the role of SoftwareDevelopment to the > organization. Any ideas? Thanks :) > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Robert Manning TRW S&ITG - TS > Sr. P/A, Engineer 310.764.9059 > mailto:Robert.Manning@trw.com http://www.trw.com > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > --------------------------------------------------------------------------- > To unsubscribe from this list please send a message to majordomo@cougaar.org > with the line "unsubscribe cougaar-developers" in the BODY of the message. > --------------------------------------------------------------------------- > To unsubscribe from this list please send a message to majordomo@cougaar.org > with the line "unsubscribe cougaar-developers" in the BODY of the message. --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Thu May 3 07:51:38 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id HAA25198 for cougaar-developers-outgoing; Thu, 3 May 2001 07:51:38 -0400 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id HAA25195 for ; Thu, 3 May 2001 07:51:37 -0400 Received: from bbn.com (ros-dhcp051-176.bbn.com [192.233.51.176]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id HAA06991; Thu, 3 May 2001 07:54:36 -0400 (EDT) Message-ID: <3AF14735.6FAC7B2@bbn.com> Date: Thu, 03 May 2001 07:55:33 -0400 From: Bill Wright X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Robert Manning CC: cougaar-developers@cougaar.org Subject: Re: [Fwd: Re: Predicate question, clarified] References: <3AF0A792.A81A6065@trw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cougaar-developers@cougaar.org Precedence: bulk Robert, The workaround you describe is consistent with what I guessed might be the problem. I'm confident that using a DynamicUnaryPredicate would fix the problem, too. And I don't think it would be any less efficient than what you're doing. It's basically the same amount of work, the only difference is whether you do it in execute() or the predicate. Bill Robert Manning wrote: > Hi Bill, > > Thanks for replying. I will try the Dynamic version tomorrow. While musing > on this problem, I came up with a different workaround... > > The different workaround was this: instead of my UnaryPredicate checking for > the role "SoftwareDevelopment" in objects of type Organization, I wrote the > predicate to simply check for objects of type Organization. That means I'm > getting a lot of extra traffic entering my plugin's execute() method. I tried > this since it seemed (at the time) that subscriptions to "SoftwareDevelopment" > weren't firing. Now, in my plugin's execute() method, I have to perform a > test on the IncrementalSubscription's elements to see if the OrganizationPG > contains the role "SoftwareDevelopment" (I actually iterate through the whole > list of roles, looking for this role). > > I'm sure this is a much less efficient way to find organizations that fulfill > the role of SoftwareDevelopment, but it seems to be working. > > Also, an additional error message is coming from somewhere in Cougaar, that I > don't understand: > > "DeferredRescind failed [task not found in logplan]: ClusterName/UID" > > I suppose it would be difficult to know why that happened offhand, but if by > some slim chance there is an easy answer to that (and if by chance it has > something to do with these other difficulties), I'd love to hear what I'm > doing wrong :) > > Thanks Bill! > -Robert > > -------- Original Message -------- > Subject: Re: Predicate question, clarified > Date: Wed, 02 May 2001 18:48:44 -0400 > From: Bill Wright > To: Robert Manning > CC: "cougaar-developers@cougaar.org" > References: <3AF05F7E.4D141AFF@trw.com> > > Sometimes you can get this behavior if you predicate tests an attribute that > changes. In your example, it may be that the OrganizationPG changes, making the > subscriptions behave in the way you notice. You might try making your predicate > a DynamicUnaryPredicate instead of a UnaryPredicate and see if it makes a > difference. > > Robert Manning wrote: > > > Hi, > > > > Thought I'd make this a bit clearer... what is happening, is that > > my subscription to this unary predicate is firing, the unary predicate > > is returning true, but when my execute() method fires in the plugin > > owning the subscription, the Organization that matched the predicate > > isn't in the list of elements (e.g. the java.util.Enumeration class > > contained in IncrementalSubscription). Either I'm doing something > > terribly wrong, or something is broken. Any Ideas? > > > > -------- Original Message -------- > > Subject: Predicate question > > Date: Wed, 02 May 2001 11:43:47 -0700 > > From: "Robert Manning" > > To: cougaar-developers@cougaar.org > > > > Hi all, > > > > What could make a unary predicate-type class stop matching correctly? > > For example, consider this predicate from Cougaar exercise 4: > > > > class myProgrammersPredicate implements UnaryPredicate{ > > public boolean execute(Object o) { > > boolean ret = false; > > if (o instanceof Organization) { > > Organization org = (Organization)o; > > OrganizationPG orgPG = org.getOrganizationPG(); > > ret = orgPG.inRoles(Role.getRole("SoftwareDevelopment")); > > } > > return ret; > > } > > } > > > > Say you've put this class into it's own file and made it a public class > > within the same package you're working on. Say also that you're no longer > > looking for SoftwareDevelopment organizations that exist within your own > > cluster - they're coming from another cluster within the same node. For > > some reason, even though the subscription using this predicate is firing, > > it is not correctly matching the role of SoftwareDevelopment to the > > organization. Any ideas? Thanks :) > > > > -- > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > Robert Manning TRW S&ITG - TS > > Sr. P/A, Engineer 310.764.9059 > > mailto:Robert.Manning@trw.com http://www.trw.com > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > --------------------------------------------------------------------------- > > To unsubscribe from this list please send a message to majordomo@cougaar.org > > with the line "unsubscribe cougaar-developers" in the BODY of the message. > > --------------------------------------------------------------------------- > > To unsubscribe from this list please send a message to majordomo@cougaar.org > > with the line "unsubscribe cougaar-developers" in the BODY of the message. --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Thu May 3 23:53:50 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id XAA25599 for cougaar-developers-outgoing; Thu, 3 May 2001 23:53:50 -0400 Received: from pisces.starnet.gov.sg ([203.116.59.242]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with SMTP id XAA25596 for ; Thu, 3 May 2001 23:53:46 -0400 From: nkiabee@starnet.gov.sg Received: (from nobody@localhost) by pisces.starnet.gov.sg (8.10.1/8.10.1) id f443whB02335 for cougaar-developers@cougaar.org; Fri, 4 May 2001 11:58:43 +0800 X-Authentication-Warning: pisces.starnet.gov.sg: nobody set sender to nkiabee@starnet.gov.sg using -f To: Subject: Re: Allocating a task to multiple supporting clusters? Message-ID: <988948723.3af228f342b30@www.starnet.gov.sg> Date: Fri, 04 May 2001 11:58:43 +0800 References: <3AF0A792.A81A6065@trw.com> <3AF14735.6FAC7B2@bbn.com> In-Reply-To: <3AF14735.6FAC7B2@bbn.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: StarNet Mail System (SMS) Sender: owner-cougaar-developers@cougaar.org Precedence: bulk Hi all, I tried with some codes for Cougaar and realised that in order to send a task to multiple supporting clusters, I need to create a separate instance of task for each cluster. Is this the behaviour of Cougaar? I want to send a task to multiple supporting clusters to see who can perform that task best before I assign the task to it. Are there any sample codes/implementations for me to better understand it? Thanks. --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Fri May 4 14:45:23 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id OAA26017 for cougaar-developers-outgoing; Fri, 4 May 2001 14:45:23 -0400 Received: from mail1.dh.trw.com (mail1.dh.trw.com [129.193.109.1]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id OAA26014 for ; Fri, 4 May 2001 14:45:22 -0400 Received: from trw.com ([129.193.108.38]) by mail1.dh.trw.com (Netscape Messaging Server 3.6) with ESMTP id AAA4EBB for ; Fri, 4 May 2001 11:51:05 -0700 Message-ID: <3AF2FA19.91370BF8@trw.com> Date: Fri, 04 May 2001 11:51:05 -0700 From: "Robert Manning" X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "cougaar-developers@cougaar.org" Subject: publishAdd outside of execute() Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cougaar-developers@cougaar.org Precedence: bulk Hi All, Does anyone know if calling SimplePlugIn.publishAdd() outside of its execute() method will cause an error? I'm doing this inside of an event handler (actionPerformed), and I'm getting a java.lang.NullPointerException as a result. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Robert Manning TRW S&ITG - TS Software Engineer 310.764.9059 mailto:Robert.Manning@trw.com http://www.trw.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Wed May 9 13:03:39 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id NAA29182 for cougaar-developers-outgoing; Wed, 9 May 2001 13:03:39 -0400 Received: from mail1.dh.trw.com (mail1.dh.trw.com [129.193.109.1]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id NAA29179 for ; Wed, 9 May 2001 13:03:37 -0400 Received: from trw.com ([129.193.108.38]) by mail1.dh.trw.com (Netscape Messaging Server 3.6) with ESMTP id AAA241; Wed, 9 May 2001 10:09:14 -0700 Message-ID: <3AF979BA.6D0599B3@trw.com> Date: Wed, 09 May 2001 10:09:14 -0700 From: "Robert Manning" X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "cougaar-developers@cougaar.org" Subject: Bug or feature? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cougaar-developers@cougaar.org Precedence: bulk Hi all, It seems to be the case that tracking of changes in logplan asset properties does not take place in an expected way, when the same assets' property(ies) is(are) modified repeatedly in the same execute cycle. IncrementalSubscription.getChangedList() seems to return a list containing the same asset, with the number of instances of the asset equal to the number of times the asset was modified and publishChange'd back to the plan. If a property in some property group of the asset is changed each time, and represents different values at each publishChange, these changes are not stored (or propagated to the IncrementalSubscription); only the *final* value of the property is returned along with the N-instances of the asset in IncrementalSubscription.getChangedList(). Example: Say you have a cluster with two plugins. Both plugins are subscribed to the same kind of asset. The first plugin is simply watching for additions, changes, and removals of this object and displaying such events. The second plugin fetches the asset from the plan, changes something in a property group, and finally does a publishChange on the asset. This second plugin might modify this property and publishChange the asset repeatedly in the same execute cycle. For the sake of example, say this second plugin modifies and publishChanges the asset 3 times. After the second plugin finishes executing, the execute cycle of the first plugin runs. The first plugin calls the getChangedList() method of its subscription, and is returned a list with three assets. As it turns out, this is the same asset repeated three times. I can understand why that happens. However, the property which was modified has the same value in all three instances! That is, a value in a property group for this asset has taken on the *LAST* value that it had, in the "second" plugin. This is simply not accurate; this property should contain the value it was assigned before each publishChange. If the infrastructure is going to give me three identical instances of the same asset from IncrementalSubscription.getChangedList, what's the point? I *would* expect each instance to hold the correct value of the assets' property at the time it was modified - not simply the LAST value that it was given before the last publishChange. Can anyone confirm for me that this is as-designed behavior? If so, it would seem to me that the infrastructure should return a single instance of the changed asset, representing its final state, along with a count of the number of times it was changed. Returning a list of N-assets of the same type implies that they should each be a snapshot of what this asset looked like each time it was publishChange'd. Since that isn't the case, the ability to track the changes from another plugin doesn't exist, and results in extra code to discard the identical duplicates. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Robert Manning TRW S&ITG - TS Software Engineer 310.764.9059 mailto:Robert.Manning@trw.com http://www.trw.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Sat May 26 17:10:44 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id RAA07129 for cougaar-developers-outgoing; Sat, 26 May 2001 17:10:44 -0400 Received: from trafficmagnet.net (IDENT:root@[211.101.236.27]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id RAA07122 for ; Sat, 26 May 2001 17:10:41 -0400 Received: from screencapture1 ([211.101.236.29]) by trafficmagnet.net (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f4R6H5Wh014308 for ; Sun, 27 May 2001 01:17:05 -0500 Message-Id: <200105270617.f4R6H5Wh014308@trafficmagnet.net> From: "Christine Hall" Subject: WWW.COUGAAR.ORG To: cougaar-developers@cougaar.org Content-Type: text/html; Reply-To: "Christine Hall" Date: Sun, 27 May 2001 05:29:12 +0800 X-Priority: 3 X-Library: Trafficmagnet 8.0 Sender: owner-cougaar-developers@cougaar.org Precedence: bulk

Hello,

I visited www.cougaar.org and I noticed that you are not listed on some search engines. I am sure you can increase the number of people who visit www.cougaar.org . Do you know TrafficMagnet? TrafficMagnet is a unique technology that instantly submits your web site to over 300,000+ search engines and directories every month. This is a very low-cost and effective way of advertising your site.

To check our prices and submit www.cougaar.org to 300,000+ search engines, go to TrafficMagnet.net

I would love to hear from you.

Best Regards,
Christine Hall
Sales & Marketing
www.TrafficMagnet.net

   

--------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Fri Jun 1 15:43:46 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id PAA10932 for cougaar-developers-outgoing; Fri, 1 Jun 2001 15:43:46 -0400 Received: from mail1.dh.trw.com (mail1.dh.trw.com [129.193.109.1]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id PAA10929 for ; Fri, 1 Jun 2001 15:43:45 -0400 Received: from trw.com ([129.193.108.38]) by mail1.dh.trw.com (Netscape Messaging Server 3.6) with ESMTP id AAA3F6C for ; Fri, 1 Jun 2001 12:49:29 -0700 Message-ID: <3B17F1C6.327EEC46@trw.com> Date: Fri, 01 Jun 2001 12:49:28 -0700 From: "Robert Manning" X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "cougaar-developers@cougaar.org" Subject: Error message Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cougaar-developers@cougaar.org Precedence: bulk Hi all, Can anyone give me an idea of what this error message means: Plugins Loaded. ....(65)........+-....(126).Asset is not bound to an LDM instance! -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Robert Manning TRW S&ITG - TS Software Engineer 310.764.9059 mailto:Robert.Manning@trw.com http://www.trw.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Fri Jun 1 16:01:09 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id QAA10951 for cougaar-developers-outgoing; Fri, 1 Jun 2001 16:01:09 -0400 Received: from draught.bbn.com (DRAUGHT.BBN.COM [128.89.28.26]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id QAA10948 for ; Fri, 1 Jun 2001 16:01:08 -0400 Received: (from mthome@localhost) by draught.bbn.com (8.11.0/8.11.0) id f51K1UR06826; Fri, 1 Jun 2001 16:01:30 -0400 From: Michael Thome MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15127.62617.964170.584031@draught.bbn.com> Date: Fri, 1 Jun 2001 16:01:29 -0400 To: "Robert Manning" Cc: "cougaar-developers@cougaar.org" Subject: Re: Error message In-Reply-To: <3B17F1C6.327EEC46@trw.com> References: <3B17F1C6.327EEC46@trw.com> X-Mailer: VM 6.90 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: mthome@bbn.com Sender: owner-cougaar-developers@cougaar.org Precedence: bulk >>>>> "Robert" == Robert Manning writes: > Hi all, > Can anyone give me an idea of what this error message means: > Plugins Loaded. > ....(65)........+-....(126).Asset is not bound to an > LDM instance! This generally means that someone has created the Asset instance without the assistance of the asset factory, or is doing something like trying to actually use (in a log plan, for instance) an asset which was deserialized from some non-standard form (http, file, xml). -- Michael Thome (mthome@bbn.com) --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Fri Jun 1 16:32:21 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id QAA10970 for cougaar-developers-outgoing; Fri, 1 Jun 2001 16:32:21 -0400 Received: from mail1.dh.trw.com (mail1.dh.trw.com [129.193.109.1]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id QAA10967 for ; Fri, 1 Jun 2001 16:32:21 -0400 Received: from trw.com ([129.193.108.38]) by mail1.dh.trw.com (Netscape Messaging Server 3.6) with ESMTP id AAAD22 for ; Fri, 1 Jun 2001 13:38:17 -0700 Message-ID: <3B17FD37.F8690F48@trw.com> Date: Fri, 01 Jun 2001 13:38:15 -0700 From: "Robert Manning" X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "cougaar-developers@cougaar.org" Subject: Identical subscriptions from multiple plugins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cougaar-developers@cougaar.org Precedence: bulk Hi all, Suppose I have a cluster with two plugins, where both of these plugins have identical IncrementalSubscription's to the cougaar AllocationPredicate(). When the IncrementalSubscription fires for some Allocation in this cluster, one or the other of these two plugins will catch the event, but they *will not both* get the event. There seems to be no way to tell which plugin will get the event in what order; if there are multiple Allocations, any number of them may go to either plugin in any order. Apparently Cougaar will give the IncrementalSubscription event to any plugin in any random order. May I assume from this behavior that if I put two plugins into a cluster, that the two plugins should not have identical subscriptions to any plan objects? Thanks! -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Robert Manning TRW S&ITG - TS Software Engineer 310.764.9059 mailto:Robert.Manning@trw.com http://www.trw.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Mon Jun 4 09:00:16 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id JAA12589 for cougaar-developers-outgoing; Mon, 4 Jun 2001 09:00:16 -0400 Received: from draught.bbn.com (DRAUGHT.BBN.COM [128.89.28.26]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id JAA12586 for ; Mon, 4 Jun 2001 09:00:15 -0400 Received: (from mthome@localhost) by draught.bbn.com (8.11.0/8.11.0) id f54D5hc31463; Mon, 4 Jun 2001 09:05:43 -0400 From: Michael Thome MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15131.34727.228282.179574@draught.bbn.com> Date: Mon, 4 Jun 2001 09:05:43 -0400 To: "Robert Manning" Cc: "cougaar-developers@cougaar.org" Subject: Re: Identical subscriptions from multiple plugins In-Reply-To: <3B17FD37.F8690F48@trw.com> References: <3B17FD37.F8690F48@trw.com> X-Mailer: VM 6.90 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: mthome@bbn.com Sender: owner-cougaar-developers@cougaar.org Precedence: bulk It is difficult to tell without more details (your code, cougaar/alp version, etc), but: >>>>> "Robert" == Robert Manning writes: > Hi all, > Suppose I have a cluster with two plugins, where both of these plugins > have identical IncrementalSubscription's to the cougaar > AllocationPredicate(). First, define "identical". If the two subscriptions are somehow ==, then the rest of this makes sense - you've done something that the infrastructure has not expected... Essentially, you've got *one* subscription. If the infrastructure has allowed you to do this, we need to add some more error checking. If this isn't the situation, I'm at a loss, as there are *many* examples of plugins with subscriptions to the same objects which work perfectly fine - none of the demonstrations would have worked if this did not function correctly. > When the IncrementalSubscription fires for some > Allocation in this cluster, one or the other of these two plugins will > catch the event, but they *will not both* get the event. There seems to > be no way to tell which plugin will get the event in what order; if there > are multiple Allocations, any number of them may go to either plugin in > any order. Apparently Cougaar will give the IncrementalSubscription > event to any plugin in any random order. > May I assume from this behavior that if I put two plugins into a > cluster, that the two plugins should not have identical subscriptions > to any plan objects? Thanks! Two plugins may subscribe to the same objects, but may not usefully share a subscription object. The subscription object maintains the transactional state with respect to the plugin it serves, so the behavior of two plugins attempting to share state is undefined. -- Michael Thome (mthome@bbn.com) --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Mon Jun 4 17:20:46 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id RAA12804 for cougaar-developers-outgoing; Mon, 4 Jun 2001 17:20:46 -0400 Received: from mail1.dh.trw.com (mail1.dh.trw.com [129.193.109.1]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id RAA12801 for ; Mon, 4 Jun 2001 17:20:45 -0400 Received: from trw.com ([129.193.108.38]) by mail1.dh.trw.com (Netscape Messaging Server 3.6) with ESMTP id AAA4104 for ; Mon, 4 Jun 2001 14:26:40 -0700 Message-ID: <3B1BFD0F.524C428A@trw.com> Date: Mon, 04 Jun 2001 14:26:39 -0700 From: "Robert Manning" X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "cougaar-developers@cougaar.org" Subject: Re: Identical subscriptions from multiple plugins References: <3B17FD37.F8690F48@trw.com> <15131.34727.228282.179574@draught.bbn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cougaar-developers@cougaar.org Precedence: bulk Hi Michael, Thanks for responding. I didn't mean to imply that I had a reference to the same subscription from two different plugins; simply that each plugin had an IncrementalSubscription that used the same predicate (org.cougaar.domain.planning.ldm.predicate.AllocationPredicate). AFAIK, your infrastructure is intact; I wouldn't know how to get a pointer to the same subscription from within two different plugins :) Actually, it appears this is a case of brain-fade on my part. Remind me not to send such emails on a Friday afternoon! My thanks go to another list member (name withheld because he emailed me privately) for pointing out that if one of the plugins were to modify the Allocation, then the other plugin might not see it because of that change. In my case, both plugins are changing the EstimatedResult to equal the ReportedResult, iff the EstimatedReport is null and the ReportedResult is not null. The clue I overlooked was always seeing exactly the right total number of Allocations between the two plugins. Consider the effect of the following code snippet, found in both of the plugins: //myAllocations is an IncrementalSubscription to AllocationPredicate Enumeration alloc_enum = myAllocations.getChangedList(); while (alloc_enum.hasMoreElements()) { Allocation alloc = (Allocation) alloc_enum.nextElement(); if ((alloc.getReportedResult() != null) && (alloc.getEstimatedResult() == null)) { if (alloc.getReportedResult().isSuccess() == true) System.out.println("Task Successfully Completed."); else System.out.println("Task Failed, Not Completed."); alloc.setEstimatedResult(alloc.getReportedResult()); //there's the change publishChange(alloc); } } I solved my problem by creating two different predicates, one for each plugin. Since the task verbs being looked for were different, the new predicates extract the Task from the Allocation and test for the appropriate Verb (I should have done that in the first place). It now works as expected. Thanks for the assistance! -Robert Michael Thome wrote: > > It is difficult to tell without more details (your code, cougaar/alp > version, etc), but: > > >>>>> "Robert" == Robert Manning writes: > > Hi all, > > Suppose I have a cluster with two plugins, where both of these plugins > > have identical IncrementalSubscription's to the cougaar > > AllocationPredicate(). > First, define "identical". If the two subscriptions are somehow ==, > then the rest of this makes sense - you've done something that the > infrastructure has not expected... Essentially, you've got *one* > subscription. If the infrastructure has allowed you to do this, we > need to add some more error checking. If this isn't the situation, > I'm at a loss, as there are *many* examples of plugins with > subscriptions to the same objects which work perfectly fine - none of > the demonstrations would have worked if this did not function correctly. > > > When the IncrementalSubscription fires for some > > Allocation in this cluster, one or the other of these two plugins will > > catch the event, but they *will not both* get the event. There seems to > > be no way to tell which plugin will get the event in what order; if there > > are multiple Allocations, any number of them may go to either plugin in > > any order. Apparently Cougaar will give the IncrementalSubscription > > event to any plugin in any random order. > > > May I assume from this behavior that if I put two plugins into a > > cluster, that the two plugins should not have identical subscriptions > > to any plan objects? Thanks! > > Two plugins may subscribe to the same objects, but may not usefully > share a subscription object. The subscription object maintains > the transactional state with respect to the plugin it serves, so the > behavior of two plugins attempting to share state is undefined. > > -- > Michael Thome (mthome@bbn.com) -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Robert Manning TRW S&ITG - TS Software Engineer 310.764.9059 mailto:Robert.Manning@trw.com http://www.trw.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Mon Jun 4 19:22:43 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id TAA12856 for cougaar-developers-outgoing; Mon, 4 Jun 2001 19:22:43 -0400 Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.121.50]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id TAA12853 for ; Mon, 4 Jun 2001 19:22:42 -0400 Received: from patdesktop (ip251.dayton11.oh.pub-ip.psi.net [38.31.203.251]) by avocet.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id QAA12313 for ; Mon, 4 Jun 2001 16:28:59 -0700 (PDT) Message-ID: <001f01c0ee17$8ecf9080$3800000a@patdesktop> From: "Pat Clark" To: Subject: Fw: Identical subscriptions from multiple plugins Date: Tue, 5 Jun 2001 19:30: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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-cougaar-developers@cougaar.org Precedence: bulk Robert, Sorry for the double copy of this. If my response was the one that helped, I figured I better correct MY Friday night brain-dead mistake of sending this to you privately instead of to the group (another group I belong to automatically puts the group name in the "to" field when I reply). Maybe it'll help someone else, I know a lot of this is tricky to think through the first couple times through it. Pat Clark ----- Original Message ----- From: "Pat Clark" To: "Robert Manning" Sent: Saturday, June 02, 2001 10:38 PM Subject: Re: Identical subscriptions from multiple plugins > Robert, > > Pretty sure if you have two plugins with identical subscriptions (but > different instances -- they don't point to the same subscription object, but > you're subscribing to the same conditions), they will both be woken up and > their execute methods will be run. We have done this only by accident, but > spent hours finding out that in our case it was a problem. But I can > envision where you would actually want to do this. As a contrived example, > in our BooksOnLine society, here's what we could have done. We could have > had two plugins in the Warehouse, each subscribing to the BooksFromWarehouse > task sent by the OrderManager cluster. Each has subscribes to the same > condition (tasks where verb = BooksFromWarehouse), but a different execute > method. One plugin would do the logic of allocating the packer for the > books, the other would examine the inventory in light of the current order > and recent orders, and determine whether the publisher should be sent a task > to order more books. > > If you're not seeing this behavior, it's possible that once the servicing > is done with the first plugin, the second one "falls through" because you're > testing for a condition you've already serviced. Put a println at the > beginning of the execute method and I'm pretty sure you'll see it print > twice for each item. > > Pat Clark > Clark Software Engineering,Ltd. > 5100 Springfield St. Suite 308 > Dayton, OH 45431 > 937.256.7794 > fax: 937.256.7842 > patkclark@earthlink.net > > ----- Original Message ----- > From: "Robert Manning" > To: > Sent: Friday, June 01, 2001 4:38 PM > Subject: Identical subscriptions from multiple plugins > > > > Hi all, > > > > Suppose I have a cluster with two plugins, where both of these plugins > > have identical IncrementalSubscription's to the cougaar > > AllocationPredicate(). When the IncrementalSubscription fires for some > > Allocation in this cluster, one or the other of these two plugins will > > catch the event, but they *will not both* get the event. There seems to > > be no way to tell which plugin will get the event in what order; if there > > are multiple Allocations, any number of them may go to either plugin in > > any order. Apparently Cougaar will give the IncrementalSubscription > > event to any plugin in any random order. > > > > May I assume from this behavior that if I put two plugins into a > > cluster, that the two plugins should not have identical subscriptions > > to any plan objects? Thanks! > > > > -- > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > Robert Manning TRW S&ITG - TS > > Software Engineer 310.764.9059 > > mailto:Robert.Manning@trw.com http://www.trw.com > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > -------------------------------------------------------------------------- > - > > To unsubscribe from this list please send a message to > majordomo@cougaar.org > > with the line "unsubscribe cougaar-developers" in the BODY of the message. > --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Tue Jun 5 13:57:53 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id NAA13327 for cougaar-developers-outgoing; Tue, 5 Jun 2001 13:57:53 -0400 Received: from mail1.dh.trw.com (mail1.dh.trw.com [129.193.109.1]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id NAA13324 for ; Tue, 5 Jun 2001 13:57:52 -0400 Received: from trw.com ([129.193.108.38]) by mail1.dh.trw.com (Netscape Messaging Server 3.6) with ESMTP id AAA2AD6 for ; Tue, 5 Jun 2001 11:03:49 -0700 Message-ID: <3B1D1F04.B6076B00@trw.com> Date: Tue, 05 Jun 2001 11:03:48 -0700 From: "Robert Manning" X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "cougaar-developers@cougaar.org" Subject: Re: Fw: Identical subscriptions from multiple plugins References: <001f01c0ee17$8ecf9080$3800000a@patdesktop> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cougaar-developers@cougaar.org Precedence: bulk Hi Pat, Yes, it was you :) If someone emails me off-list, I usually respond in like fashion. Interesting you should mention this... I checked the header of your email, and there's no "Reply-To:" field in it. It looks like they're using Majordomo, so I'd think that a Reply-To field could be added, no? -Robert Pat Clark wrote: > > Robert, > Sorry for the double copy of this. If my response was the one that > helped, I figured I better correct MY Friday night brain-dead mistake of > sending this to you privately instead of to the group (another group I > belong to automatically puts the group name in the "to" field when I reply). > Maybe it'll help someone else, I know a lot of this is tricky to think > through the first couple times through it. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Robert Manning TRW S&ITG - TS Software Engineer 310.764.9059 mailto:Robert.Manning@trw.com http://www.trw.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Wed Jun 6 23:37:19 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id XAA14413 for cougaar-developers-outgoing; Wed, 6 Jun 2001 23:37:19 -0400 Received: from pisces.starnet.gov.sg ([203.116.59.242]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with SMTP id XAA14410 for ; Wed, 6 Jun 2001 23:37:15 -0400 From: nkiabee@starnet.gov.sg Received: (from nobody@localhost) by pisces.starnet.gov.sg (8.10.1/8.10.1) id f573nvF11240 for cougaar-developers@cougaar.org; Thu, 7 Jun 2001 11:49:57 +0800 X-Authentication-Warning: pisces.starnet.gov.sg: nobody set sender to nkiabee@starnet.gov.sg using -f To: Subject: Re: RMI marshal exception? Message-ID: <991885796.3b1ef9e4e8110@www.starnet.gov.sg> Date: Thu, 07 Jun 2001 11:49:56 +0800 References: <3AF0A792.A81A6065@trw.com> <3AF14735.6FAC7B2@bbn.com> <988948723.3af228f342b30@www.starnet.gov.sg> In-Reply-To: <988948723.3af228f342b30@www.starnet.gov.sg> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: StarNet Mail System (SMS) Sender: owner-cougaar-developers@cougaar.org Precedence: bulk Have anyone got any ideas what causes this RMI Marshal exception? java.rmi.MarshalException: error marshalling arguments; nested exception is: java.net.SocketException: socket write error (code=10053) java.net.SocketException: socket write error (code=10053) at java.net.SocketOutputStream.socketWrite(Native Method) at java.net.SocketOutputStream.write(SocketOutputStream.java:87) at java.io.BufferedOutputStream.write (BufferedOutputStream.java:116) at java.io.ObjectOutputStream.drain(ObjectOutputStream.java:1238) at java.io.ObjectOutputStream.setBlockData (ObjectOutputStream.java:1260) at java.io.ObjectOutputStream.writeObject (ObjectOutputStream.java:383) at sun.rmi.server.UnicastRef.marshalValue(UnicastRef.java:272) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:110) at org.cougaar.core.society.rmi.MTImpl_Stub.receiveMessage (MTImpl_Stub.j ava:89) at org.cougaar.core.society.rmi.RMIMessageTransport$KeyedMT.receiveMessa ge(RMIMessageTransport.java:451) at org.cougaar.core.society.rmi.RMIMessageTransport$DestinationQueue.run (RMIMessageTransport.java:788) at java.lang.Thread.run(Thread.java:479) Regards. --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Fri Jun 8 05:47:47 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id FAA15218 for cougaar-developers-outgoing; Fri, 8 Jun 2001 05:47:47 -0400 Received: from pisces.starnet.gov.sg ([203.116.59.242]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with SMTP id FAA15215 for ; Fri, 8 Jun 2001 05:47:45 -0400 From: nkiabee@starnet.gov.sg Received: (from nobody@localhost) by pisces.starnet.gov.sg (8.10.1/8.10.1) id f58A0ZZ15099 for cougaar-developers@cougaar.org; Fri, 8 Jun 2001 18:00:35 +0800 X-Authentication-Warning: pisces.starnet.gov.sg: nobody set sender to nkiabee@starnet.gov.sg using -f To: Subject: Re: RMI marshal exception? Message-ID: <991994435.3b20a243d50ad@www.starnet.gov.sg> Date: Fri, 08 Jun 2001 18:00:35 +0800 References: <3AF0A792.A81A6065@trw.com> <3AF14735.6FAC7B2@bbn.com> <988948723.3af228f342b30@www.starnet.gov.sg> <991885796.3b1ef9e4e8110@www.starnet.gov.sg> In-Reply-To: <991885796.3b1ef9e4e8110@www.starnet.gov.sg> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: StarNet Mail System (SMS) Sender: owner-cougaar-developers@cougaar.org Precedence: bulk Maybe I should give more explanation to my problems: I have setup a few PCs running various nodes supporting each others. I noticed that some of the PCs can receive tasks from other nodes (in different PCs) but they simply cannot publish tasks to others (in different PCs). Only some PCs have the problems sending tasks out and they give the error. Are there any setting needs to be done. I don't recall doing that for those PCs that can publish tasks out. Regards. ---------------------------------------------------------------------- Quoting nkiabee@starnet.gov.sg: > Have anyone got any ideas what causes this RMI Marshal exception? > > java.rmi.MarshalException: error marshalling arguments; nested > exception > is: > java.net.SocketException: socket write error (code=10053) > java.net.SocketException: socket write error (code=10053) > at java.net.SocketOutputStream.socketWrite(Native Method) > at > java.net.SocketOutputStream.write(SocketOutputStream.java:87) > at java.io.BufferedOutputStream.write > (BufferedOutputStream.java:116) > at > java.io.ObjectOutputStream.drain(ObjectOutputStream.java:1238) > at java.io.ObjectOutputStream.setBlockData > (ObjectOutputStream.java:1260) > > at java.io.ObjectOutputStream.writeObject > (ObjectOutputStream.java:383) > at > sun.rmi.server.UnicastRef.marshalValue(UnicastRef.java:272) > at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:110) > at org.cougaar.core.society.rmi.MTImpl_Stub.receiveMessage > (MTImpl_Stub.j > ava:89) > at > org.cougaar.core.society.rmi.RMIMessageTransport$KeyedMT.receiveMessa > ge(RMIMessageTransport.java:451) > at > org.cougaar.core.society.rmi.RMIMessageTransport$DestinationQueue.run > (RMIMessageTransport.java:788) > at java.lang.Thread.run(Thread.java:479) > > > Regards. > ------------------------------------------------------------------------- -- > To unsubscribe from this list please send a message to > majordomo@cougaar.org > with the line "unsubscribe cougaar-developers" in the BODY of the > message. > --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Fri Jun 8 17:14:43 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id RAA15570 for cougaar-developers-outgoing; Fri, 8 Jun 2001 17:14:43 -0400 Received: from mail1.dh.trw.com (mail1.dh.trw.com [129.193.109.1]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id RAA15567 for ; Fri, 8 Jun 2001 17:14:42 -0400 Received: from trw.com ([129.193.108.38]) by mail1.dh.trw.com (Netscape Messaging Server 3.6) with ESMTP id AAA54F7; Fri, 8 Jun 2001 14:20:29 -0700 Message-ID: <3B21419B.3774ECED@trw.com> Date: Fri, 08 Jun 2001 14:20:27 -0700 From: "Robert Manning" X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "cougaar-developers@cougaar.org" Subject: Usage for Results in an Allocation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cougaar-developers@cougaar.org Precedence: bulk Hi All, In interface org.cougaar.domain.planning.ldm.plan.Allocation, there are several types of AllocationResult's (through class PlanElement): EstimatedResult, ReportedResult, ReceivedResult, ObservedResult According to the javadocs, I can obtain an AllocationResult instance for any of these four types of results. I can also set the AllocationResult for two types of results: EstimatedResult and ObservedResult (PlanElementImpl javadoc states that only the infrastructure is to use setReceivedResult, and that setReportedResult is deprecated). My questions have to do with ambiguity and apparent usage. Issue #1): Why Set Different Results? The javadoc for PlanElement.setEstimatedResult() states "Set the estimated allocation result so that a notification will propagate up another level." According to the Cougaar Plugin Developers' Guide 7.0, para. 5.4.3.2, titled "Notification (AllocationResult) Propagation", when an estimated AllocationResult is set on a plan element (something that can happens with a call to theLDMF.createAllocation that includes a non-null AllocationResult) the "Local infrastructure LP propagates change to next upstream plan element by copying this information to the reportedAllocationResult slot and performs publishChange(PlanElement)." In other words, the Cougaar infrastructure copies the EstimatedResult from the plugin/cluster performing a task, to the ReportedResult "slot" in the plugin/cluster that issued the task in the first place (see Figure 26, pg. 77). I can understand (and greatly appreciate) the utility of automatically communicating the AllocationResult in this fashion. But why is it necessary to change the meaning of that result? In other words, in the plugin/cluster that Allocates the Task, the inclusion of a non-null AllocationResult inside a call to theLDMF.createAllocation() results in the apparent setting of the EstimatedResult in that plugin, and the automatic setting of the ReportedResult in the tasking plugin/cluster. Why isn't the EstimatedResult set instead? Apparently, the setting of EstimatedResult is being used to trigger the sending of the AllocationResult to the tasking plugin/cluster; so by automatically setting the EstimatedResult in the original plugin/cluster, you'd create an automatic chain of events throughout the infrastructure, for as many plugins as were involved in this task. It almost appears as if this is a workaround used to prevent this effect. IMO, it would be simpler and clearer to have a method to trigger the "upstream" reporting of all AllocationResults, and keep the meanings of the various *Result types consistent across plugins. Which brings me to my next question: Issue #2): What are ObservedResult and ReceivedResult Used For? Since EstimatedResult and ReportedResult seem to be the only two result types I really need to worry about, what are these other two for? And, is there any automatic functionality hidden behind them (such as for EstimatedResult)? Can they be used to report the result of an allocation, the result of performing a task, something else, etc? Which brings me to my third question: Issue #3): What's The AllocationResult Used For? IMO, the automatic communication of an AllocationResult on a task might come in very handy for several things: it can be used to notify a plugin that created a task that the task has been received and Allocated to some Asset class. It could also be used to signify that a task *has been completed*. Since the AllocationResult holds info relating to the confidence, success, aspect types and results on *a task*, it seems quite natural to me, at first glance, that AllocationResults and the automatic infrastructure communication offered by setting the EstimatedResult, refer to the result of completing a task (not simply allocating a task). If the AllocationResult refers only to the result of an Allocation (e.g. the association of an Asset and a Task), and the confidence/success/aspect type array/results array information altogether only refer to the act of making an Allocation, then what shall we use to report the result(s) of the task itself? It would seem wasteful to create another task, just to report the results of the original task. Then we'd have to worry about reporting the result of the task that reported the result of a task that reported the result of a task ... (recursively ad infinitum). So, what is the AllocationResult really used for? Can I use it for anything I want to, as long as I use it consistently? Or must I consider that it is to only be used for reporting results of allocations? If so, what would be the preferred way to report on task completion (which to me is the more important issue anyway)? Thanks, Robert -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Robert Manning TRW S&ITG - TS Software Engineer 310.764.9059 mailto:Robert.Manning@trw.com http://www.trw.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Fri Jun 15 15:00:58 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id PAA20333 for cougaar-developers-outgoing; Fri, 15 Jun 2001 15:00:58 -0400 Received: from mail1.dh.trw.com (mail1.dh.trw.com [129.193.109.1]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id PAA20330 for ; Fri, 15 Jun 2001 15:00:56 -0400 Received: from trw.com ([129.193.108.38]) by mail1.dh.trw.com (Netscape Messaging Server 3.6) with ESMTP id AAA1DD8 for ; Fri, 15 Jun 2001 12:06:50 -0700 Message-ID: <3B2A5CC9.75F6BFE4@trw.com> Date: Fri, 15 Jun 2001 12:06:49 -0700 From: "Robert Manning" Organization: TRW X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "cougaar-developers@cougaar.org" Subject: RoleSchedule? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cougaar-developers@cougaar.org Precedence: bulk Hi All, How do I access and manipulate the RoleSchedule and the schedules for the various plan elements that are supposedly stored in it? Does a RoleSchedule pertain to the roles between organizations, or to the roles an organization plays while performing some task? Correct me if I'm wrong, but it would appear that when I have an asset of type Organization in my cluster (which includes myself as an asset), that whenever I allocate a task to such an asset, an entry should be made into the RoleSchedule for that asset. What I can find in the source code indicates that this takes place inside SimplePlugIn.publishAdd(). However, according to TASKS.PSP, there is some kind of default RoleSchedule inside my Organizational assets, that begins in 1990 and ends in 2010 (regardless of how many other tasks I've allocated to that organization). This seems to be true whether I'm allocating a task to my own cluster or some other cluster. If this isn't the right class to use for scheduling, can someone point me in the right direction? Thanks. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Robert Manning TRW S&ITG - TS Software Engineer 310.764.9059 mailto:Robert.Manning@trw.com http://www.trw.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Mon Jun 18 13:46:14 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id NAA22265 for cougaar-developers-outgoing; Mon, 18 Jun 2001 13:46:14 -0400 Received: from mail1.dh.trw.com (mail1.dh.trw.com [129.193.109.1]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id NAA22262 for ; Mon, 18 Jun 2001 13:46:12 -0400 Received: from trw.com ([129.193.108.38]) by mail1.dh.trw.com (Netscape Messaging Server 3.6) with ESMTP id AAA5D19; Mon, 18 Jun 2001 10:52:04 -0700 Message-ID: <3B2E3FC3.317B4E47@trw.com> Date: Mon, 18 Jun 2001 10:52:03 -0700 From: "Robert Manning" Organization: TRW X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "cougaar-developers@cougaar.org" Subject: Allocation to self doesn't work? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cougaar-developers@cougaar.org Precedence: bulk Hi All, I am trying to allocate a task to my own cluster, but for some reason the allocation does not appear in my logplan (in TASKS.PSP). I obtained a reference to my cluster as an Asset, by using a very general predicate that looks for all objects of type Asset, then searches for matches between ItemIdentificationPG.ItemIdentification (sans "UIC/") and getDelegate().getMetricsSnapshot().clusterName. Once I have a reference to my own cluster as an Asset, I can then create an Allocation using theLDMF.createAllocation() and publishAdd it to my logplan. This all seems to work without error, but the allocation never shows up. Why? Thanks! -Robert -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Robert Manning TRW S&ITG - TS Software Engineer 310.764.9059 mailto:Robert.Manning@trw.com http://www.trw.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Mon Jun 18 14:32:45 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id OAA22295 for cougaar-developers-outgoing; Mon, 18 Jun 2001 14:32:45 -0400 Received: from mail1.dh.trw.com (mail1.dh.trw.com [129.193.109.1]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id OAA22292 for ; Mon, 18 Jun 2001 14:32:44 -0400 Received: from trw.com ([129.193.108.38]) by mail1.dh.trw.com (Netscape Messaging Server 3.6) with ESMTP id AAA316C; Mon, 18 Jun 2001 11:38:40 -0700 Message-ID: <3B2E4AAF.A868B7FE@trw.com> Date: Mon, 18 Jun 2001 11:38:39 -0700 From: "Robert Manning" Organization: TRW X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "cougaar-developers@cougaar.org" Subject: Usage for Results in an Allocation (x2) References: <3B21419B.3774ECED@trw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cougaar-developers@cougaar.org Precedence: bulk Hi All, The following email was sent to the list 10 days ago. In the hopes that it was forgotten and not ignored, I'm sending the question again. Thanks :) Robert Manning wrote: > > Hi All, > > In interface org.cougaar.domain.planning.ldm.plan.Allocation, there are > several types of AllocationResult's (through class PlanElement): > > EstimatedResult, ReportedResult, ReceivedResult, ObservedResult > > According to the javadocs, I can obtain an AllocationResult instance for > any of these four types of results. I can also set the AllocationResult for > two types of results: EstimatedResult and ObservedResult (PlanElementImpl > javadoc states that only the infrastructure is to use setReceivedResult, > and that setReportedResult is deprecated). > > My questions have to do with ambiguity and apparent usage. > > Issue #1): Why Set Different Results? > > The javadoc for PlanElement.setEstimatedResult() states "Set the estimated > allocation result so that a notification will propagate up another level." > According to the Cougaar Plugin Developers' Guide 7.0, para. 5.4.3.2, titled > "Notification (AllocationResult) Propagation", when an estimated > AllocationResult is set on a plan element (something that can happens with a > call to theLDMF.createAllocation that includes a non-null AllocationResult) > the "Local infrastructure LP propagates change to next upstream plan element > by copying this information to the reportedAllocationResult slot and performs > publishChange(PlanElement)." In other words, the Cougaar infrastructure copies > the EstimatedResult from the plugin/cluster performing a task, to the > ReportedResult "slot" in the plugin/cluster that issued the task in the first > place (see Figure 26, pg. 77). > > I can understand (and greatly appreciate) the utility of automatically > communicating the AllocationResult in this fashion. But why is it necessary > to change the meaning of that result? In other words, in the plugin/cluster > that Allocates the Task, the inclusion of a non-null AllocationResult inside > a call to theLDMF.createAllocation() results in the apparent setting of the > EstimatedResult in that plugin, and the automatic setting of the > ReportedResult in the tasking plugin/cluster. Why isn't the EstimatedResult > set instead? Apparently, the setting of EstimatedResult is being used to > trigger the sending of the AllocationResult to the tasking plugin/cluster; > so by automatically setting the EstimatedResult in the original plugin/cluster, > you'd create an automatic chain of events throughout the infrastructure, for > as many plugins as were involved in this task. It almost appears as if this > is a workaround used to prevent this effect. > > IMO, it would be simpler and clearer to have a method to trigger the > "upstream" reporting of all AllocationResults, and keep the meanings of the > various *Result types consistent across plugins. Which brings me to my next > question: > > Issue #2): What are ObservedResult and ReceivedResult Used For? > > Since EstimatedResult and ReportedResult seem to be the only two result types > I really need to worry about, what are these other two for? And, is there any > automatic functionality hidden behind them (such as for EstimatedResult)? > Can they be used to report the result of an allocation, the result of > performing a task, something else, etc? Which brings me to my third question: > > Issue #3): What's The AllocationResult Used For? > > IMO, the automatic communication of an AllocationResult on a task might come > in very handy for several things: it can be used to notify a plugin that > created a task that the task has been received and Allocated to some Asset > class. It could also be used to signify that a task *has been completed*. > Since the AllocationResult holds info relating to the confidence, success, > aspect types and results on *a task*, it seems quite natural to me, at first > glance, that AllocationResults and the automatic infrastructure communication > offered by setting the EstimatedResult, refer to the result of completing a > task (not simply allocating a task). > > If the AllocationResult refers only to the result of an Allocation (e.g. the > association of an Asset and a Task), and the confidence/success/aspect type > array/results array information altogether only refer to the act of making an > Allocation, then what shall we use to report the result(s) of the task itself? > It would seem wasteful to create another task, just to report the results of > the original task. Then we'd have to worry about reporting the result of the > task that reported the result of a task that reported the result of a task > ... (recursively ad infinitum). > > So, what is the AllocationResult really used for? Can I use it for anything > I want to, as long as I use it consistently? Or must I consider that it is to > only be used for reporting results of allocations? If so, what would be the > preferred way to report on task completion (which to me is the more important > issue anyway)? > > Thanks, > Robert -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Robert Manning TRW S&ITG - TS Software Engineer 310.764.9059 mailto:Robert.Manning@trw.com http://www.trw.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- --------------------------------------------------------------------------- To unsubscribe from this list please send a message to majordomo@cougaar.org with the line "unsubscribe cougaar-developers" in the BODY of the message. From owner-cougaar-developers@cougaar.org Mon Jun 18 15:18:47 2001 Return-Path: Received: (from majordom@localhost) by alp-61.alp.isotic.org (8.9.3/8.9.3) id PAA22319 for cougaar-developers-outgoing; Mon, 18 Jun 2001 15:18:47 -0400 Received: from mailgate1.darpa.mil (mailgate1.darpa.mil [192.5.18.61]) by alp-61.alp.isotic.org (8.9.3/8.9.3) with ESMTP id PAA22316 for ; Mon, 18 Jun 2001 15:18:46 -0400 Received: from mailhub1.darp