From twright at bbn.com  Mon Jun 23 15:05:30 2008
From: twright at bbn.com (Todd Wright)
Date: Mon, 23 Jun 2008 15:05:30 -0400
Subject: We've fixed the mailing list
Message-ID: <485FF3FA.6000108@bbn.com>


In April the Cougaar mailing list server was being overwhelmed with spam, so we 
reconfigured the machine.  However, the updated server has been blocking 
legitimate mail.  We think we've fixed the problem now.

If you've sent email to the list and its been dropped, please try again.  If 
your email is blocked then email me or Aaron (ahelsing at bbn.com) and we'll make 
sure it gets posted.

Thanks,
Todd


From duchene.morgan at wanadoo.fr  Mon Jun 23 15:48:50 2008
From: duchene.morgan at wanadoo.fr (=?ISO-8859-1?Q?Morgan_Duch=E8ne?=)
Date: Mon, 23 Jun 2008 21:48:50 +0200
Subject: wp recovery
Message-ID: <485FFE22.1040004@wanadoo.fr>

An HTML attachment was scrubbed...
URL: http://cougaar.org/pipermail/cougaar-developers/attachments/20080623/72b6c367/attachment-0001.html

From jzinky at bbn.com  Mon Jun 23 16:39:33 2008
From: jzinky at bbn.com (John Zinky)
Date: Mon, 23 Jun 2008 16:39:33 -0400
Subject: FrameSet Management
Message-ID: <65C59042-3276-4D65-B7C4-63B04591ABC7@bbn.com>

Alexander,
Please sign up to be a cougaar-developer. This will allow you to send  
messages to cougaar-developer and not have them thrown away as spam.  
It was a miracle that this message was found and not lost in the spam  
filter.

Also I would be interested in knowing which inference engine you are  
using and wether you are willing to share the code, if the engine is  
open-source. (We use Jess, which is not open source, so we can't  
release the rule engine part of FrameSets.)

In general, you should have only one plugin run the  
FrameSet.processQueue method and the logical place is the same plugin  
that created the FrameSet. FrameSetLoaderPlugin is the basic example  
for creating a FrameSet instance and setting up the subscription to  
have processQueue called in its execute().

Other plugins can use FrameSet.removeFrame(..) and  
FrameSet.makeFrame(..) in their execute blocks and then  
FrameSetLoaderPlugin will actually publish DatatFrames to the  
blackboard and update the FrameSet inferences.

If another plugin wants to run code and guarantee that the  
processQueue is not running, it should use FrameSet method:
   /**
    * Runs a body of code using a lock that prevents a
    * simultaneous invocation of {@link #processQueue}.
    * The runnable is executed in the caller's thread.
    */
   public void runInTransaction(Runnable r);


We found that it works better to run the rule engine and FrameSet in  
phases, letting each run to completion before starting the other.

1) So for our plugin that runs the rule engine, we have the following  
steps in execute()

a)  insert/delete ShadowFacts into the rule engine for each DataFrame  
that was added/deleted for this run of execute()
b)  run the rule engine
    i) queue up all DataFrame add/deletes specified by the rule engine
    ii) let all the rules fire until there are no more matches for  
this batch of ShadowFacts
c) insert/delete queued DataFrames into FrameSet.
    This is done in a FrameSet.runInTransaction()

2) After the RuleEnginPlugin runs, the FrameSetLoaderPlugin processes  
its queue and puts the RuleEngines DataFrames on the blackboard.

3) OtherPlugins process the blackboard changes created by the  
RuleEngine and add/delete their own DataFrames to the FrameSet.

4) The FrameSetLoaderPlugin processes its queue, now with the  
OtherPlugins' DataFrames.

and the cycle repeats.

Hope this helps
zinky

> From: "Alexander Claus" <styjdt at claus4joy.de>
> Date: June 2, 2008 3:43:56 AM EDT
> To: <cougaar-developers at cougaar.org>
> Subject: FrameSet Management
>
>
> Hello,
>
> I'm working with the FrameSet stuff of Cougaar. The frames are used  
> as facts
> in a rule engine.
> I have 2 agents, each agent has its own rule engine and some other  
> plugins.
>
> There is a plugin, which creates the DataFrames via  
> FrameSet.makeFrame(..).
> One plugin, which consumes the DataFrames from the blackboard and  
> put them
> into the rule engine. And there is a plugin which "cleans" from time  
> to time
> the blackboard and the rule engine's knowledge base. This means,  
> that the
> DataFrames are retracted from the rule engine and removed from the  
> FrameSet
> via FrameSet.removeFrame(..).
>
> I found that after makeFrame(..) one has to call  
> FrameSet.processQueue() to
> publish the events on the blackboard and the same after  
> removeFrame(..) to
> remove them from the blackboard.
> But: I got some Exceptions while calling processQueue() ("... called  
> outside transaction ..."), so I refactored the system in such a way,  
> that processQueue() is now always called from the same plugin which  
> created the frameset. Now there are no Exceptions...
> Here are my questions:
>
> 1. Is it true, that this is the only way of doing this? Must  
> processQueue() always be called from the plugin which created the  
> frameset?
>
> 2. What is the purpose of the FrameSetLoaderPlugin? Should one  
> extend this plugin to a "FrameSetManagerPlugin" which is responsible  
> for all frameset-related operations?
>
> Thanks in advance
> Alexander Claus


From ddomingue at gmail.com  Tue Jun 24 08:06:58 2008
From: ddomingue at gmail.com (daniel domingue)
Date: Tue, 24 Jun 2008 14:06:58 +0200
Subject: Fwd: Issue when using agent mobility in Cougaar
In-Reply-To: <fef1db450806200807j4a05d56bwaa835217ea801992@mail.gmail.com>
References: <fef1db450806200807j4a05d56bwaa835217ea801992@mail.gmail.com>
Message-ID: <fef1db450806240506g294f5779qf01ea27773675b6@mail.gmail.com>

I'm trying a second attempt at the mailing list


---------- Forwarded message ----------
From: daniel domingue <ddomingue at gmail.com>
Date: Fri, Jun 20, 2008 at 5:07 PM
Subject: Issue when using agent mobility in Cougaar
To: cougaar-developers at cougaar.org


Hello all,

I have encountered a small problem when trying to use mobile agents.
The relocated agents have an IncrementalSubscription on message
elements in the blackboard which contain a specific object.
Mobility is triggered by a remote agent using the following code :

               /* get a ticket identification from the mobility factory */
               Object ticketId = mobilityFactory.createTicketIdentifier();

               /* get adresses of agent and host */
               MessageAddress agentAdd =
MessageAddress.getMessageAddress(agentName);
               MessageAddress origHostAdd =
MessageAddress.getMessageAddress(origHost);

               /* create a transfer ticket with the needed information */
               Ticket mTicket = new
Ticket(ticketId,agentAdd,origHostAdd,this.nodeId,false);

               /* create a move agent order with the created ticket */
               MoveAgent ac = mobilityFactory.createMoveAgent(mTicket);

               /* post the ticket to the blackboard for proceeding */
               blackboard.publishAdd(ac);


Everything works fine except that the relocated agents receive old
messages through the getAddedCollection() performed in the execute()
method after the blackboard has been rehydrated.
Below is part of the code that filters the messages in the relocated agents :

       for (Iterator iter = aValMsgSubs.getAddedCollection().iterator();
iter.hasNext();)
               {
                       LS_Com_Target co = (LS_Com_Target) iter.next() ;
                       Object o = co.getData();
                       Msg_LBValidator m = ((Msg_LBValidator) o);

                       /* placebo */
                       switch(m.getLoadType())
                       {
                       case(ScenarioEntry.MSG):

loadinfo.setRemainingMSGLoadCycles(m.getElapsed());
                       loadinfo.setMsgTargets(m.getTargetAgents());
                       System.out.println(this.agentId.toString()+"
received MSG");
                       break;

                       case(ScenarioEntry.PROC):

loadinfo.setRemainingCPULoadCycles(m.getElapsed());
                       System.out.println(this.agentId.toString()+"
received PROC");
                       break;

                       case(ScenarioEntry.SIZE):

loadinfo.setRemainingMEMLoadCycles(m.getElapsed());
                       System.out.println(this.agentId.toString()+"
received SIZE");
                       break;
                       }

                       modified=true;

               }

The problem I see is that when the blackboard is being rehydrated all
the old messages change state and are classified as new messages,
which are picked up at the first execute() call after the load().

Any clue that could help would be appreciated!


Thanks in advance,


--
Daniel Domingue



-- 
Daniel Domingue


From twright at bbn.com  Tue Jun 24 12:54:37 2008
From: twright at bbn.com (Todd Wright)
Date: Tue, 24 Jun 2008 12:54:37 -0400
Subject: wp recovery
In-Reply-To: <485FFE22.1040004@wanadoo.fr>
References: <485FFE22.1040004@wanadoo.fr>
Message-ID: <486126CD.5090305@bbn.com>

Morgan Duch?ne wrote:
> Hi all,
> 
> Great you are back, we were missing you!
> 
> I am making small demos of the different features of Cougaar, here 
> playing around with the white pages and it replication fixture:
> - Node 1 : PingSender
> - Node 2 : PingReceiver
> - Node 3 : NameServer1
> - Node 4 : NameServer2
> - Node 5 : NameServer3
> 
> NameServer 1, 2 and 3 are configured to replicate their content.
> 
> I start every node, everything works fine (/wp).
> 
> Then I stop one name server. First there are some catched exceptions and 
> messages, then only lines like:
> 2008-06-19 20:08:39,968 INFO  [DestinationQueueImpl] - Node3: No valid 
> links to NameServer2
> 
> Then I restart the stopped name server and all wps don't seem to recover 
> quite well from there. The name server agents seem to communicate, but 
> there seems to still be a problem communicating with the node because 
> there is still the same info problem and the white pages servlet 
> confirms it has not recovered well. But it comes back to normal if I 
> restart the other two name servers.
> 
> Is there any configuration or something I missed because I don't see why 
> agents don't recover from this stop and restart, which can happen in 
> real world? (my configuration is below)

This might be a problem with restarting a node with an old node's name.

Instead of restarting Node2, try start a new node with NameServer2, e.g.:
    <node name="Node6">
      <agent name="NameServer2">
        <component class='org.cougaar.core.wp.server.Server'/>
      </agent>
    </node>

> 
> On the other hand, it brings me to a question about white pages. In a 
> very big society with millions of nodes, 

At that scale you should probably use DNS or LDAP.

The local-only white pages implementation's "submit" method is only about 100 
lines:
http://cougaar.org/cgi-bin/viewcvs.cgi/core/src/org/cougaar/core/wp/LoopbackWhitePages.java?annotate=1.2&cvsroot=core

So, you could write your own implementation and modify
   configs/common/NodeAgent.xsl
to load it instead of the standard Cougaar implement.

> how would the white pages behave and isn't it a single point of failure with
> the default implementation?

No, it should work so long as any white pages server is running.  However, the 
performance will be O(N^2) for N servers.  For more info see:
   http://cougaar.org/docman/view.php/17/176/Scalable_Naming_KIMAS_2005.ppt
   http://cougaar.org/docman/view.php/17/175/scalability_paper_kimas_05.pdf

Todd

> 
> Thanks,
> Morgan
> 
> 
> 
> 
> 
> /_Logging props :_/
> log4j.rootCategory=WARN,A1
> log4j.appender.A1.layout=org.apache.log4j.PatternLayout
> log4j.appender.A1.layout.ConversionPattern=%d{ISO8601} %-5p [%c{1}] - %m%n
> log4j.appender.A1=org.apache.log4j.ConsoleAppender
> 
> log4j.category.org.cougaar.mts=INFO
> 
> 
> /_Runtime config file : _/
> <?xml version='1.0'?>
> 
> <!--
> Two-node "ping" runtime System Properties.
> -->
> <runtime>
> 
>   <!--
> NameServers
>   -->
>   <vm_parameter name="-Dorg.cougaar.name.server" 
> value="NameServer1 at localhost:8888"/>
>   <vm_parameter name="-Dorg.cougaar.name.server.WP-2" 
> value="NameServer2 at localhost:8888"/>
>   <vm_parameter name="-Dorg.cougaar.name.server.WP-3" 
> value="NameServer3 at localhost:8888"/>
>  
>   <vm_parameter
>     name="-Dorg.cougaar.society.xsl.param.template"
>     value="lan"/>
> 
>   <!-- Optional tuning to reduce naming service startup time -->
>   <vm_parameter name="-Dorg.cougaar.core.wp.server.successTTD" 
> value="30000"/>
>   <vm_parameter name="-Dorg.cougaar.core.wp.server.failTTD" value="1000"/>
>   <vm_parameter name="-Dorg.cougaar.core.wp.resolver.rmi.minLookup" 
> value="500"/>
>   <vm_parameter name="-Dorg.cougaar.core.wp.resolver.rmi.maxLookup" 
> value="2000"/>
>   <vm_parameter name="-Dorg.cougaar.core.mts.destq.retry.initialTimeout" 
> value="250"/>
>   <vm_parameter name="-Dorg.cougaar.core.mts.destq.retry.maxTimeout" 
> value="500"/>
> 
>   <!-- Optional log4j config file -->
>   <vm_parameter
>      name="-Dorg.cougaar.core.logging.config.filename"
>      value="logging.props"/>
> </runtime>
> 
> 
> /_Society config file :_/
> <?xml version='1.0'?>
> 
> <!--
> Two-node "ping" society definition.
> -->
> <society>
> 
>   <node name="Node1">
> 
>     <agent name="A">
>       <component class="org.cougaar.demo.wp.PingSender">
>         <argument name="target" value="B"/>
>       </component>
>       <component class="org.cougaar.demo.wp.PingServlet">
>         <argument name="path" value="/ping"/>
>       </component>
>     </agent>
>   </node>
> 
>  
>   <node name="Node2">
>    
>     <agent name="B">
>       <component class="org.cougaar.demo.wp.PingReceiver"/>
>     </agent>
>   </node>
> 
>   <!-- First wp -->
>   <node name="Node3">
> 
>     <!-- Agent "NameServer" will be our society-wide naming service -->
>     <agent name="NameServer1">
>       <component class='org.cougaar.core.wp.server.Server'/>
>     </agent>
>   </node>
> 
>   <!-- Another wp -->
>   <node name="Node4">
> 
>     <!-- Agent "NameServer" will be our society-wide naming service -->
>     <agent name="NameServer2">
>       <component class='org.cougaar.core.wp.server.Server'/>
>     </agent>
>   </node>
> 
>   <!-- Another wp -->
>   <node name="Node5">
> 
>     <!-- Agent "NameServer" will be our society-wide naming service -->
>     <agent name="NameServer3">
>       <component class='org.cougaar.core.wp.server.Server'/>
>     </agent>
>   </node>
>  
> </society>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Cougaar-developers mailing list
> Cougaar-developers at cougaar.org
> http://cougaar.org/mailman/listinfo/cougaar-developers


From ngivler at bbn.com  Tue Jun 24 17:08:13 2008
From: ngivler at bbn.com (Noelle Givler)
Date: Tue, 24 Jun 2008 17:08:13 -0400
Subject: Christian Bernardt - LogFiles, SD
In-Reply-To: <485FCD25.6040201@bbn.com>
References: <e65d710e0806230836u68e34bd6j9b96ad5c4186c1bc@mail.gmail.com>
	<485FCD25.6040201@bbn.com>
Message-ID: <4861623D.2090609@bbn.com>

Hi, Christian.

I'm assuming that your versions of SDRegistrationPlugin and 
SDClientPlugin extend SimpleSDRegistratonPlugin, SimpleSDClientPlugin 
and SimpleMatchmakerPlugin.. Debugging is a lot more straightforward 
with the simple versions. These are the base classes used in the pizza 
tutorial.

Would you first verify that MTA is successfully registering as a 
ProductionTaskProvider?

    *  Does registration plugin find the provider file?
          o Add debugging output to isProvider() and helper methods to
            print file name returned by getProviderFile() and
            getProviderFile() exists()
    *  Does the registration plugin find it's yp community?
          o SimpleSDRegistrationPlugin has debugging output charting the
            progress of the finding the YP community
    * Does the registration plugin register the provider
          o SimpleSDRegistrationPlugin has debugging output for
            registration process in the YP. Look for - MTA
            initialRegister success = true with <yp community name>

Please let me know whether registration is successful so I can suggest 
the next set of debugging steps.

Other thoughts -
1) Did you add follow the example of the pizza tutorial and implement a 
DomainAdapter (org.cougaar.servicediscovery.PizzaDomain) and Constants 
(org.cougaar.servicediscovery.Constants) to ensure that the 
ProductionTaskProvider role was properly constructed?

2)I'm perplexed by the reference to MilitaryServiceScheme in the 
MMQuery. SimpleMatchmakerPlugin.getServiceSchemeForRoles() defaults to 
UDDIConstants.COMMERCIAL_SERVICE_SCHEME. Can you verify that you're 
using an extension of SimpleMatchmakerPlugin and have not overwritten 
getServiceScheme?

Noelle

Noelle Givler wrote:
> Hi, Christian.
>
> I just started looking at your logs but I noticed that I don't see any 
> messages indicating that MTA registered sucessfully as a 
> ProductionTaskProvider. Do you have logging enabled for 
> org.cougaar.servicediscovery.plugin? There should be in an initial 
> DEBUG level message from SimpleSDRegistrationPlugin saying something 
> like -
> Registering: MTA with <your community name>
>
> If this doesn't appear, it indicates that cougaar isn't finding the 
> provider description file - probably related to a cougaar install path 
> problem. I'll see if I can find some documentation on setting up 
> environment variables.
>
> Noelle
>
>
> Christian Bernardt wrote:
>> Hi Noelle,
>>
>> here are the logging files. One, where DEBUG is set for entire 
>> cougaar plugins (full_...log) and the other one with just my plugins 
>> set to debug.
>> The xml file is my community start file and I have sent you the 
>> community file, a sample service file, my service scheme.
>> Just tell me, if you need any further material from my side.
>>
>> Yours sincerely,
>>
>> Christian Bernardt
>>
>> On Wed, Jun 18, 2008 at 4:20 PM, Noelle Givler <ngivler at bbn.com 
>> <mailto:ngivler at bbn.com>> wrote:
>>
>>     Hi, Christian.
>>
>>     I got your call yesterday. I'm committed to client meetings
>>     through the week. I should be available to talk next Monday
>>     morning. I'm usually in by 8 am edt.
>>
>>     Noelle
>>     Christian Bernardt wrote:
>>
>>         Hi Noelle,
>>
>>         this is Christian Bernardt, I have tried calling you, but just
>>         reached your answering machine.
>>         I would like to ask one more question concerning the yp
>>         service. I have managed to publish a FIND_PROVIDER task, which
>>         result in a mmquery published by the SDClientPlugin. But the
>>         query only seems to return null. When I use the servlet to
>>         look for the mmquery it tells me that all my queries are
>>         MilitaryService Queries and that I am using the
>>         MilitaryServiceScheme, which is very strange, because I never
>>         defined this ServiceScheme and can not find a code snippet
>>         where this service scheme is referenced. However I have
>>         referenced the CommercialServiceScheme, which contains all the
>>         information I need for my application.
>>         Could you please make some suggestion:
>>
>>         1.) why the mmqueries are failing, even though I have
>>         generated the owl files, have provided the ServiceScheme and
>>         published it
>>         2.) where I could find the reference to the Military Service
>>          Scheme so that I can change this reference to the
>>         CommercialServiceScheme.
>>
>>         Thank you very much.
>>
>>         I would really appreciate if we could talk on the phone on one
>>         of these days.
>>
>>         Yours sincerely, Christian Bernardt
>>
>>         On Tue, May 20, 2008 at 8:53 PM, Noelle Givler
>>         <ngivler at bbn.com <mailto:ngivler at bbn.com>
>>         <mailto:ngivler at bbn.com <mailto:ngivler at bbn.com>>> wrote:
>>
>>            Hi, Christian.
>>
>>            I assume you've already looked  at the pizza tutorial. (
>>            http://cougaar.org/projects/tutorials/ ). That's a very
>>            straightforward example of cougaar service discovery. I'm
>>         going to
>>            use the pizza tutorial as the context for my answers below.
>>
>>            CommercialServiceScheme-yp.xml and the service profiles
>>         define the
>>            set of services registered for a given agent within the 
>> yellow
>>            pages. The README file in 
>> tutorials/pizza/data/serviceprofiles
>>            discusses how to add a new service (i.e. IceCreamProvider)
>>         and how
>>            to add an new provider (i.e. Pizzahut).
>>
>>            SDPizzaNode1.xml and SDPizzaNode2.xml in
>>            tutorials/pizza/configs/pizzaparty are well commented
>>         examples of
>>            society .xml files. They illustrate how to define nodes and
>>            agents. In addition,  you can find information on how the
>>         plugins
>>            within the agents are configured to support service 
>> discovery.
>>
>>            Within the cougaar agents, the service functionality is
>>         modeled by
>>            plugins.
>>                   
>> tutorials/tutorials/pizza/src/org/cougaar/pizza/plugin/package.html
>>            discusses how the plugins use service discovery to find a
>>            PizzaProvider. For service discovery to work correctly in the
>>            simple service discovery case demonstrated by the pizza
>>         tutorial,
>>             Role.getName() (in the org.cougaar.planning.ldm.plan.Role
>>         sense)
>>            must match the string used to define the service in
>>            CommercialServiceScheme-yp.xml and the the service
>>         profiles. Hence
>>            the addition of the PIZZAPROVIDER and  PIZZACONSUMER Roles
>>         defined
>>            on org.cougaar.pizza.Constants.  Section 3.2.9 of the Cougaar
>>            Developers Guide discusses Service Discovery in greater 
>> detail.
>>
>>            If you have additional questions, it would be helpful if
>>         you could
>>            also provide some background on the problem you wish to 
>> solve.
>>
>>            Thanks,
>>            Noelle Givler
>>
>>            Subject:
>>            Re: Question Cougaar, mailing list not working
>>            From:
>>            Todd Wright <twright at bbn.com <mailto:twright at bbn.com>
>>         <mailto:twright at bbn.com <mailto:twright at bbn.com>>>
>>
>>            Date:
>>            Thu, 15 May 2008 11:06:04 -0400
>>
>>            To:
>>            Christian Bernardt <crossfire2003 at gmx.de
>>         <mailto:crossfire2003 at gmx.de>
>>            <mailto:crossfire2003 at gmx.de
>>         <mailto:crossfire2003 at gmx.de>>>,
>>         christian.bernardt at googlemail.com
>>         <mailto:christian.bernardt at googlemail.com>
>>            <mailto:christian.bernardt at googlemail.com
>>         <mailto:christian.bernardt at googlemail.com>>
>>            CC:
>>            Aaron Helsinger <ahelsing at bbn.com <mailto:ahelsing at bbn.com>
>>         <mailto:ahelsing at bbn.com <mailto:ahelsing at bbn.com>>>
>>
>>
>>
>>
>>            I've cc'ed Aaron.  I don't know much about the YP, so 
>> hopefully
>>            Aaron can answer your questions.
>>
>>            Also, try sending your email to mailing list again.  It was
>>         down
>>            for several weeks but I think we've fixed it.
>>
>>            Todd
>>
>>            Christian Bernardt wrote:
>>
>>                Hi Todd,
>>
>>                I have a question concerning the cougaar yellow page
>>         service.
>>                I hope you find the time to answer it.
>>                I am a little confused about the definition of roles. 
>> There
>>                are, as far as I know, 4 places where one can find a role
>>                definition:
>>
>>                   * CommercialServiceScheme-yp.xml
>>                   * the society xml, when creating the self-entity
>>                   * the serviceprofile owls
>>                   * Constants Class
>>
>>                Which of the places, where I can find the role names are
>>                essential to get the yellow page service working?
>>                Could you please explain a bit, what exactly is e.g.
>>         done in
>>                the Constants class, which I do not fully understand and
>>                therefore can not really adapt it to my problem.
>>                I know, that the pizza example creates complementary 
>> roles,
>>                provider vs. customer, but what does the creation of the
>>                relationship type in Constants do? and is it essential
>>         for the
>>                yellow page service?
>>
>>                I hope you find the time to elaborate a little more on 
>> the
>>                concept.
>>
>>                Yours sincerely,
>>
>>                Christian Bernardt
>>
>>
>>
>>
>>
>>
>>
>>
>>         --         secondary residence:
>>
>>         c/o Gregersen
>>         Karl-Marx-Ring 118
>>         81739 M?nchen
>>         Germany
>>         ______________________________________
>>         mobile: +49-151-56934998
>>         phone: +49-351-2644416 (VOIP)
>>         ______________________________________
>>         principal residence:
>>
>>         Christian Bernardt
>>         Gartenstr. 6
>>         01328 Dresden
>>         Germany
>>         phone:+49-(0)351-26 40 914
>>         fax: +49-(0)351-26 40 918
>>
>>
>>
>>
>>
>> -- 
>> secondary residence:
>>
>> c/o Gregersen
>> Karl-Marx-Ring 118
>> 81739 M?nchen
>> Germany
>> ______________________________________
>> mobile: +49-151-56934998
>> phone: +49-351-2644416 (VOIP)
>> ______________________________________
>> principal residence:
>>
>> Christian Bernardt
>> Gartenstr. 6
>> 01328 Dresden
>> Germany
>> phone:+49-(0)351-26 40 914
>> fax: +49-(0)351-26 40 918 
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cougaar.org/pipermail/cougaar-developers/attachments/20080624/5bc8686d/attachment-0001.html

From ngivler at bbn.com  Wed Jun 25 09:50:07 2008
From: ngivler at bbn.com (Noelle Givler)
Date: Wed, 25 Jun 2008 09:50:07 -0400
Subject: Service Discovery (was Re: Cougaar Framesets)
Message-ID: <48624D0F.9070609@bbn.com>

Thorsten,

Immediate failure of the query indicates that either the Provider isn't 
registered correctly or the Client isn't able to access the YP where the 
Provider is registered. Could you turn on Debug logging in 
org.cougaar.servicediscovery? That would should give some insight into 
where the process is failing.

Regards,
Noelle

Aaron Helsinger wrote:
> My first instinct would be the history servlet which should tell you 
> what messages are being sent where.
> Noelle?
>
> I also noted his comment that the mail lists are still screwy...
>
> John Zinky wrote:
>> I do not know anything about service discovery.
>> Any hints for this guy?
>>
>> Begin forwarded message:
>>
>>> From: "Schoeler, Thorsten (CT)" <thorsten.schoeler at siemens.com>
>>> Date: June 20, 2008 9:58:57 AM EDT
>>> To: "John Zinky" <jzinky at bbn.com>
>>> Cc: "Todd Wright" <twright at bbn.com>
>>> Subject: RE: Cougaar FrameSets
>>>
>>> John,
>>>
>>> sorry for bothering you again. At present we are using Frame Sets and
>>> our rule engine with good success. Unfortunately we have still problems
>>> with using Cougaar's service discovery. We do understand the pizza
>>> example but have problems in transferring the pizza service discovery
>>> protocol into our example application.
>>>
>>> In our example, the matchmaker is issuing the role query but instantly
>>> returns with an empty result set indicating that no service provider
>>> could be found although we have (properly) registered a service
>>> provider. Afterwards, the request is repeated with a certain frequency
>>> yielding no new results.
>>>
>>> Can you shed some light on our situation? We analysed the pizza
>>> execution logs and our debug logs but without success. Is there a
>>> servlet displaying the service discovery service current state, e.g.
>>> which services have already registered, etc.?
>>>
>>> Thanks again for your help and time.
>>>
>>> PS: The mailing list is still not working properly, there are no new
>>> posts apart from Mr Wright's test message dating 2008-05-09.
>>>
>>> With best regards,
>>> Dr.
>>> Thorsten Schoeler
>>>
>>> Siemens AG
>>> Corporate Technology
>>> Intelligent Autonomous Systems
>>> CT IC 6
>>> Otto-Hahn-Ring 6
>>> 81739 Muenchen, Germany
>>> Tel.: +49 (89) 636-44390
>>> Fax: +49 (89) 636-41423
>>> mailto:thorsten.schoeler at siemens.com
>>>
>>>
>>> Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard
>>> Cromme; Managing Board: Peter Loescher, Chairman, President and Chief
>>> Executive Officer; Wolfgang Dehen, Heinrich Hiesinger, Joe Kaeser, Jim
>>> Reid-Anderson, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen;
>>> Registered offices: Berlin and Munich; Commercial registries: Berlin
>>> Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322
>>>
>>> Important notice: This e-mail and any attachment thereof contain
>>> corporate proprietary information. If you have received it by mistake,
>>> please notify us immediately by reply e-mail and delete this e-mail and
>>> its attachments from your system. Thank you.
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: John Zinky [mailto:jzinky at bbn.com]
>>> Sent: Friday, May 09, 2008 7:07 PM
>>> To: Schoeler, Thorsten (CT)
>>> Cc: John Zinky
>>> Subject: Re: Cougaar FrameSets
>>>
>>> Thorsten,
>>> I got your message
>>> And they turned cougaar.org back on. (it was having problems so the
>>> sys-admin turned it off)
>>>
>>> We see only one legitimate user attempting to sign up for a cougaar
>>> mailing list.
>>> Do you have a list of the people you wanted to add?
>>>
>>> I will digest your previous message later today
>>> zinky
>>>
>>> On May 9, 2008, at 9:11 AM, Schoeler, Thorsten (CT) wrote:
>>>
>>>> Dear Dr Zinky,
>>>>
>>>> we are currently making good progress in using Cougaar for our use
>>>> cases. However we have some issues in properly understanding some of
>>>> it's procedures. Have you got my last e-mail?
>>>>
>>>> Do you know what is wrong with the Cougaar mailing lists? Some of my
>>>> colleagues have subscribed but never got an acknowledgement.
>>>> Moreover I
>>>> have not received any new post on the developer mailing list since
>>>> April
>>>> 24th.
>>>>
>>>> Can you please send me a short reply? I think BBN is very busy at the
>>>> moment and I do not want to occupy your precious time to much.
>>>>
>>>> With best regards,
>>>> Dr.
>>>> Thorsten Schoeler
>>>
>>
>>
>
>





From twright at bbn.com  Wed Jun 25 14:17:52 2008
From: twright at bbn.com (Todd Wright)
Date: Wed, 25 Jun 2008 14:17:52 -0400
Subject: Fwd: Issue when using agent mobility in Cougaar
In-Reply-To: <fef1db450806240506g294f5779qf01ea27773675b6@mail.gmail.com>
References: <fef1db450806200807j4a05d56bwaa835217ea801992@mail.gmail.com>
	<fef1db450806240506g294f5779qf01ea27773675b6@mail.gmail.com>
Message-ID: <48628BD0.5020005@bbn.com>

Daniel,

I tested this in Cougaar 12.4 using the demo "ping" society and the "/move" 
servlet and it worked for me.

Maybe there's something wrong with your MoveAgent request, 'though it looks 
okay to me.  It could be a bug that doesn't happen in the ping test, e.g. a 
race condition.

Please run the following test:

1) Download and unzip Cougaar 12.4 from:
http://cougaar.org/frs/?group_id=17&release_id=161

2) Unzip the required code:
unzip -q cougaar.zip
unzip -q cougaar-support.zip
unzip -q demo-ping.zip

3) Set the required environment variables:
export COUGAAR_INSTALL_PATH=/opt/Cougaar12_4
export COUGAAR_SOCIETY_PATH=/opt/Cougaar12_4/ping
export COUGAAR_RUNTIME_PATH=/opt/Cougaar12_4/ping/run

4) Modified the ping code to add debug output:
cd ping
modify src/org/cougaar/demo/ping/PingSender.java to add line 145:
   log.shout("sub added="+sub.getAddedCollection()+" all="+sub.getCollection());
ant jar
mv tmp/ping.jar lib
cd run

5) In one console run:
cougaar ../configs/PingTwoNodesSociety.xml PingTwoNodesRuntime.xml Node1
and then in a second console run:
cougaar ../configs/PingTwoNodesSociety.xml PingTwoNodesRuntime.xml Node2

6) The first console prints:
   SHOUT [PingSender] - A: sub added=[] all=[]
This shows that the subscription starts out empty, as expected.

7) Let it run for a while then load:
http://localhost:8800/$Node1/move?op=Move&mobileAgent=A&originNode=Node1&destNode=Node2&isForceRestart=false&action=Add

8) The first console prints:
   SHOUT [DOTS] - P+-+....
and the second console prints:
   SHOUT [PingSender] - A: sub added=[] all=[(SimpleRelay uid=A/1214417255150 
source=A target=B query=10 reply=10)]
This shows that the subscription "getAddedCollection()" is empty and the 
"iterator()" was repopulated with the prior state.

Todd

daniel domingue wrote:
> I'm trying a second attempt at the mailing list
> 
> 
> ---------- Forwarded message ----------
> From: daniel domingue <ddomingue at gmail.com>
> Date: Fri, Jun 20, 2008 at 5:07 PM
> Subject: Issue when using agent mobility in Cougaar
> To: cougaar-developers at cougaar.org
> 
> 
> Hello all,
> 
> I have encountered a small problem when trying to use mobile agents.
> The relocated agents have an IncrementalSubscription on message
> elements in the blackboard which contain a specific object.
> Mobility is triggered by a remote agent using the following code :
> 
>                /* get a ticket identification from the mobility factory */
>                Object ticketId = mobilityFactory.createTicketIdentifier();
> 
>                /* get adresses of agent and host */
>                MessageAddress agentAdd =
> MessageAddress.getMessageAddress(agentName);
>                MessageAddress origHostAdd =
> MessageAddress.getMessageAddress(origHost);
> 
>                /* create a transfer ticket with the needed information */
>                Ticket mTicket = new
> Ticket(ticketId,agentAdd,origHostAdd,this.nodeId,false);
> 
>                /* create a move agent order with the created ticket */
>                MoveAgent ac = mobilityFactory.createMoveAgent(mTicket);
> 
>                /* post the ticket to the blackboard for proceeding */
>                blackboard.publishAdd(ac);
> 
> 
> Everything works fine except that the relocated agents receive old
> messages through the getAddedCollection() performed in the execute()
> method after the blackboard has been rehydrated.
> Below is part of the code that filters the messages in the relocated agents :
> 
>        for (Iterator iter = aValMsgSubs.getAddedCollection().iterator();
> iter.hasNext();)
>                {
>                        LS_Com_Target co = (LS_Com_Target) iter.next() ;
>                        Object o = co.getData();
>                        Msg_LBValidator m = ((Msg_LBValidator) o);
> 
>                        /* placebo */
>                        switch(m.getLoadType())
>                        {
>                        case(ScenarioEntry.MSG):
> 
> loadinfo.setRemainingMSGLoadCycles(m.getElapsed());
>                        loadinfo.setMsgTargets(m.getTargetAgents());
>                        System.out.println(this.agentId.toString()+"
> received MSG");
>                        break;
> 
>                        case(ScenarioEntry.PROC):
> 
> loadinfo.setRemainingCPULoadCycles(m.getElapsed());
>                        System.out.println(this.agentId.toString()+"
> received PROC");
>                        break;
> 
>                        case(ScenarioEntry.SIZE):
> 
> loadinfo.setRemainingMEMLoadCycles(m.getElapsed());
>                        System.out.println(this.agentId.toString()+"
> received SIZE");
>                        break;
>                        }
> 
>                        modified=true;
> 
>                }
> 
> The problem I see is that when the blackboard is being rehydrated all
> the old messages change state and are classified as new messages,
> which are picked up at the first execute() call after the load().
> 
> Any clue that could help would be appreciated!
> 
> 
> Thanks in advance,
> 
> 
> --
> Daniel Domingue
> 
> 
> 


From duchene.morgan at wanadoo.fr  Fri Jun 27 08:10:28 2008
From: duchene.morgan at wanadoo.fr (=?ISO-8859-1?Q?Morgan_Duch=E8ne?=)
Date: Fri, 27 Jun 2008 14:10:28 +0200
Subject: Adaptivity, where to start from?
Message-ID: <4864D8B4.8010202@wanadoo.fr>

Hi all,

I order to continue my investigation and make some other tutorials 
(we'll have to speak about them if you want to include them in the next 
release), I would like to know how the adaptivity system works. More 
precisely, I would like to understand the different threat levels, how 
to define rules, the components in charge of this and maybe find some 
examples.

There are some explanations given in the security documentation, but 
isn't there some simple examples before I dive into the security overlay 
(which I have almost made work in v12.4)?

Thanks,
Morgan



From ddomingue at gmail.com  Fri Jun 27 13:05:32 2008
From: ddomingue at gmail.com (daniel domingue)
Date: Fri, 27 Jun 2008 19:05:32 +0200
Subject: Fwd: Issue when using agent mobility in Cougaar
In-Reply-To: <48628BD0.5020005@bbn.com>
References: <fef1db450806200807j4a05d56bwaa835217ea801992@mail.gmail.com>
	<fef1db450806240506g294f5779qf01ea27773675b6@mail.gmail.com>
	<48628BD0.5020005@bbn.com>
Message-ID: <fef1db450806271005y3c6aadddgfdd49b4e0481bf60@mail.gmail.com>

Hello,

I tried the test you proposed with the ping demo and it works, the
agent's subscription works as described.

By rewriting another identical plugin from scratch ,
I was able to isolate the problem which is in the load() method of the plugin :

	public void load()
	{
		super.load();
		
		if(blackboard.didRehydrate())
		{
			
			blackboard.openTransaction();
			Collection c = blackboard.query(new LBAgentPredicate());
			blackboard.closeTransactionDontReset();
		}
	}

When I try to get a blackboard element from the load(), the problem
occurs. When the code concerning the blackboard transaction is
commented out, it works perfectly fine.
I don't know if using this type of calls to the blackboard in the
load() method has a direct impact on the other elements in it, and if
there is a good way of implementing this.

Best regards,

	
On Wed, Jun 25, 2008 at 8:17 PM, Todd Wright <twright at bbn.com> wrote:
> Daniel,
>
> I tested this in Cougaar 12.4 using the demo "ping" society and the "/move"
> servlet and it worked for me.
>
> Maybe there's something wrong with your MoveAgent request, 'though it looks
> okay to me.  It could be a bug that doesn't happen in the ping test, e.g. a
> race condition.
>
> Please run the following test:
>
> 1) Download and unzip Cougaar 12.4 from:
> http://cougaar.org/frs/?group_id=17&release_id=161
>
> 2) Unzip the required code:
> unzip -q cougaar.zip
> unzip -q cougaar-support.zip
> unzip -q demo-ping.zip
>
> 3) Set the required environment variables:
> export COUGAAR_INSTALL_PATH=/opt/Cougaar12_4
> export COUGAAR_SOCIETY_PATH=/opt/Cougaar12_4/ping
> export COUGAAR_RUNTIME_PATH=/opt/Cougaar12_4/ping/run
>
> 4) Modified the ping code to add debug output:
> cd ping
> modify src/org/cougaar/demo/ping/PingSender.java to add line 145:
>  log.shout("sub added="+sub.getAddedCollection()+"
> all="+sub.getCollection());
> ant jar
> mv tmp/ping.jar lib
> cd run
>
> 5) In one console run:
> cougaar ../configs/PingTwoNodesSociety.xml PingTwoNodesRuntime.xml Node1
> and then in a second console run:
> cougaar ../configs/PingTwoNodesSociety.xml PingTwoNodesRuntime.xml Node2
>
> 6) The first console prints:
>  SHOUT [PingSender] - A: sub added=[] all=[]
> This shows that the subscription starts out empty, as expected.
>
> 7) Let it run for a while then load:
> http://localhost:8800/$Node1/move?op=Move&mobileAgent=A&originNode=Node1&destNode=Node2&isForceRestart=false&action=Add
>
> 8) The first console prints:
>  SHOUT [DOTS] - P+-+....
> and the second console prints:
>  SHOUT [PingSender] - A: sub added=[] all=[(SimpleRelay uid=A/1214417255150
> source=A target=B query=10 reply=10)]
> This shows that the subscription "getAddedCollection()" is empty and the
> "iterator()" was repopulated with the prior state.
>
> Todd
>
> daniel domingue wrote:
>>
>> I'm trying a second attempt at the mailing list
>>
>>
>> ---------- Forwarded message ----------
>> From: daniel domingue <ddomingue at gmail.com>
>> Date: Fri, Jun 20, 2008 at 5:07 PM
>> Subject: Issue when using agent mobility in Cougaar
>> To: cougaar-developers at cougaar.org
>>
>>
>> Hello all,
>>
>> I have encountered a small problem when trying to use mobile agents.
>> The relocated agents have an IncrementalSubscription on message
>> elements in the blackboard which contain a specific object.
>> Mobility is triggered by a remote agent using the following code :
>>
>>               /* get a ticket identification from the mobility factory */
>>               Object ticketId = mobilityFactory.createTicketIdentifier();
>>
>>               /* get adresses of agent and host */
>>               MessageAddress agentAdd =
>> MessageAddress.getMessageAddress(agentName);
>>               MessageAddress origHostAdd =
>> MessageAddress.getMessageAddress(origHost);
>>
>>               /* create a transfer ticket with the needed information */
>>               Ticket mTicket = new
>> Ticket(ticketId,agentAdd,origHostAdd,this.nodeId,false);
>>
>>               /* create a move agent order with the created ticket */
>>               MoveAgent ac = mobilityFactory.createMoveAgent(mTicket);
>>
>>               /* post the ticket to the blackboard for proceeding */
>>               blackboard.publishAdd(ac);
>>
>>
>> Everything works fine except that the relocated agents receive old
>> messages through the getAddedCollection() performed in the execute()
>> method after the blackboard has been rehydrated.
>> Below is part of the code that filters the messages in the relocated
>> agents :
>>
>>       for (Iterator iter = aValMsgSubs.getAddedCollection().iterator();
>> iter.hasNext();)
>>               {
>>                       LS_Com_Target co = (LS_Com_Target) iter.next() ;
>>                       Object o = co.getData();
>>                       Msg_LBValidator m = ((Msg_LBValidator) o);
>>
>>                       /* placebo */
>>                       switch(m.getLoadType())
>>                       {
>>                       case(ScenarioEntry.MSG):
>>
>> loadinfo.setRemainingMSGLoadCycles(m.getElapsed());
>>                       loadinfo.setMsgTargets(m.getTargetAgents());
>>                       System.out.println(this.agentId.toString()+"
>> received MSG");
>>                       break;
>>
>>                       case(ScenarioEntry.PROC):
>>
>> loadinfo.setRemainingCPULoadCycles(m.getElapsed());
>>                       System.out.println(this.agentId.toString()+"
>> received PROC");
>>                       break;
>>
>>                       case(ScenarioEntry.SIZE):
>>
>> loadinfo.setRemainingMEMLoadCycles(m.getElapsed());
>>                       System.out.println(this.agentId.toString()+"
>> received SIZE");
>>                       break;
>>                       }
>>
>>                       modified=true;
>>
>>               }
>>
>> The problem I see is that when the blackboard is being rehydrated all
>> the old messages change state and are classified as new messages,
>> which are picked up at the first execute() call after the load().
>>
>> Any clue that could help would be appreciated!
>>
>>
>> Thanks in advance,
>>
>>
>> --
>> Daniel Domingue
>>
>>
>>
>



-- 
Daniel Domingue


From twright at bbn.com  Fri Jun 27 17:15:38 2008
From: twright at bbn.com (Todd Wright)
Date: Fri, 27 Jun 2008 17:15:38 -0400
Subject: Fwd: Issue when using agent mobility in Cougaar
In-Reply-To: <fef1db450806271005y3c6aadddgfdd49b4e0481bf60@mail.gmail.com>
References: <fef1db450806200807j4a05d56bwaa835217ea801992@mail.gmail.com>	
	<fef1db450806240506g294f5779qf01ea27773675b6@mail.gmail.com>	
	<48628BD0.5020005@bbn.com>
	<fef1db450806271005y3c6aadddgfdd49b4e0481bf60@mail.gmail.com>
Message-ID: <4865587A.7040203@bbn.com>


Okay, this makes sense.

First, it's unusual to do a blackboard query in "load()".  This is usually done 
in "setupSubscriptions()", as seen in the PingSender "getInitialCounter()" example.

Second, the query should find all objects, not just the "getAddedCollection()". 
  So it makes sense that it would find the old messages.

Lastly, subscriptions should be made in the first transaction, which is (by 
default) the "setupSubscriptions()" method.  This will rehydrate the 
subscription with its pending add/change/remove lists that were saved in the 
persistence snapshot's per-plugin "SubscriberState" object.

For example, say we have two plugins, a ping sender and receiver, and they 
publish blackboard objects back and forth to one another as fast as possible. 
There will always be an outstanding "ping" or "ack" message that's "in flight" 
between the two plugins, waiting to be delivered and processed in the target 
plugin's "execute()" method.  This pending message is saved in the mobile 
agent's persistence snapshot's SubscriberState and will be restored if the 
subscription is recreated in the "setupSubscriptions()" method, otherwise it 
will be discarded.  So, it's important to create subscriptions in the 
"setupSubscriptions()" method if you want to rehydrate these add/change/remove 
messages.

Todd

daniel domingue wrote:
> Hello,
> 
> I tried the test you proposed with the ping demo and it works, the
> agent's subscription works as described.
> 
> By rewriting another identical plugin from scratch ,
> I was able to isolate the problem which is in the load() method of the plugin :
> 
> 	public void load()
> 	{
> 		super.load();
> 		
> 		if(blackboard.didRehydrate())
> 		{
> 			
> 			blackboard.openTransaction();
> 			Collection c = blackboard.query(new LBAgentPredicate());
> 			blackboard.closeTransactionDontReset();
> 		}
> 	}
> 
> When I try to get a blackboard element from the load(), the problem
> occurs. When the code concerning the blackboard transaction is
> commented out, it works perfectly fine.
> I don't know if using this type of calls to the blackboard in the
> load() method has a direct impact on the other elements in it, and if
> there is a good way of implementing this.
> 
> Best regards,
> 
> 	
> On Wed, Jun 25, 2008 at 8:17 PM, Todd Wright <twright at bbn.com> wrote:
>> Daniel,
>>
>> I tested this in Cougaar 12.4 using the demo "ping" society and the "/move"
>> servlet and it worked for me.
>>
>> Maybe there's something wrong with your MoveAgent request, 'though it looks
>> okay to me.  It could be a bug that doesn't happen in the ping test, e.g. a
>> race condition.
>>
>> Please run the following test:
>>
>> 1) Download and unzip Cougaar 12.4 from:
>> http://cougaar.org/frs/?group_id=17&release_id=161
>>
>> 2) Unzip the required code:
>> unzip -q cougaar.zip
>> unzip -q cougaar-support.zip
>> unzip -q demo-ping.zip
>>
>> 3) Set the required environment variables:
>> export COUGAAR_INSTALL_PATH=/opt/Cougaar12_4
>> export COUGAAR_SOCIETY_PATH=/opt/Cougaar12_4/ping
>> export COUGAAR_RUNTIME_PATH=/opt/Cougaar12_4/ping/run
>>
>> 4) Modified the ping code to add debug output:
>> cd ping
>> modify src/org/cougaar/demo/ping/PingSender.java to add line 145:
>>  log.shout("sub added="+sub.getAddedCollection()+"
>> all="+sub.getCollection());
>> ant jar
>> mv tmp/ping.jar lib
>> cd run
>>
>> 5) In one console run:
>> cougaar ../configs/PingTwoNodesSociety.xml PingTwoNodesRuntime.xml Node1
>> and then in a second console run:
>> cougaar ../configs/PingTwoNodesSociety.xml PingTwoNodesRuntime.xml Node2
>>
>> 6) The first console prints:
>>  SHOUT [PingSender] - A: sub added=[] all=[]
>> This shows that the subscription starts out empty, as expected.
>>
>> 7) Let it run for a while then load:
>> http://localhost:8800/$Node1/move?op=Move&mobileAgent=A&originNode=Node1&destNode=Node2&isForceRestart=false&action=Add
>>
>> 8) The first console prints:
>>  SHOUT [DOTS] - P+-+....
>> and the second console prints:
>>  SHOUT [PingSender] - A: sub added=[] all=[(SimpleRelay uid=A/1214417255150
>> source=A target=B query=10 reply=10)]
>> This shows that the subscription "getAddedCollection()" is empty and the
>> "iterator()" was repopulated with the prior state.
>>
>> Todd
>>
>> daniel domingue wrote:
>>> I'm trying a second attempt at the mailing list
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: daniel domingue <ddomingue at gmail.com>
>>> Date: Fri, Jun 20, 2008 at 5:07 PM
>>> Subject: Issue when using agent mobility in Cougaar
>>> To: cougaar-developers at cougaar.org
>>>
>>>
>>> Hello all,
>>>
>>> I have encountered a small problem when trying to use mobile agents.
>>> The relocated agents have an IncrementalSubscription on message
>>> elements in the blackboard which contain a specific object.
>>> Mobility is triggered by a remote agent using the following code :
>>>
>>>               /* get a ticket identification from the mobility factory */
>>>               Object ticketId = mobilityFactory.createTicketIdentifier();
>>>
>>>               /* get adresses of agent and host */
>>>               MessageAddress agentAdd =
>>> MessageAddress.getMessageAddress(agentName);
>>>               MessageAddress origHostAdd =
>>> MessageAddress.getMessageAddress(origHost);
>>>
>>>               /* create a transfer ticket with the needed information */
>>>               Ticket mTicket = new
>>> Ticket(ticketId,agentAdd,origHostAdd,this.nodeId,false);
>>>
>>>               /* create a move agent order with the created ticket */
>>>               MoveAgent ac = mobilityFactory.createMoveAgent(mTicket);
>>>
>>>               /* post the ticket to the blackboard for proceeding */
>>>               blackboard.publishAdd(ac);
>>>
>>>
>>> Everything works fine except that the relocated agents receive old
>>> messages through the getAddedCollection() performed in the execute()
>>> method after the blackboard has been rehydrated.
>>> Below is part of the code that filters the messages in the relocated
>>> agents :
>>>
>>>       for (Iterator iter = aValMsgSubs.getAddedCollection().iterator();
>>> iter.hasNext();)
>>>               {
>>>                       LS_Com_Target co = (LS_Com_Target) iter.next() ;
>>>                       Object o = co.getData();
>>>                       Msg_LBValidator m = ((Msg_LBValidator) o);
>>>
>>>                       /* placebo */
>>>                       switch(m.getLoadType())
>>>                       {
>>>                       case(ScenarioEntry.MSG):
>>>
>>> loadinfo.setRemainingMSGLoadCycles(m.getElapsed());
>>>                       loadinfo.setMsgTargets(m.getTargetAgents());
>>>                       System.out.println(this.agentId.toString()+"
>>> received MSG");
>>>                       break;
>>>
>>>                       case(ScenarioEntry.PROC):
>>>
>>> loadinfo.setRemainingCPULoadCycles(m.getElapsed());
>>>                       System.out.println(this.agentId.toString()+"
>>> received PROC");
>>>                       break;
>>>
>>>                       case(ScenarioEntry.SIZE):
>>>
>>> loadinfo.setRemainingMEMLoadCycles(m.getElapsed());
>>>                       System.out.println(this.agentId.toString()+"
>>> received SIZE");
>>>                       break;
>>>                       }
>>>
>>>                       modified=true;
>>>
>>>               }
>>>
>>> The problem I see is that when the blackboard is being rehydrated all
>>> the old messages change state and are classified as new messages,
>>> which are picked up at the first execute() call after the load().
>>>
>>> Any clue that could help would be appreciated!
>>>
>>>
>>> Thanks in advance,
>>>
>>>
>>> --
>>> Daniel Domingue
>>>
>>>
>>>
> 
> 
> 


From ngivler at bbn.com  Mon Jun 30 17:38:29 2008
From: ngivler at bbn.com (Noelle Givler)
Date: Mon, 30 Jun 2008 17:38:29 -0400
Subject: Christian Bernardt - LogFiles, SD
In-Reply-To: <e65d710e0806261509i6e90ced1h7c927896d0902739@mail.gmail.com>
References: <e65d710e0806230836u68e34bd6j9b96ad5c4186c1bc@mail.gmail.com>	
	<485FCD25.6040201@bbn.com> <4861623D.2090609@bbn.com>
	<e65d710e0806261509i6e90ced1h7c927896d0902739@mail.gmail.com>
Message-ID: <48695255.6020304@bbn.com>

Problem seems to be with your yp community. Comments embedded below
Christian Bernardt wrote:
> Hi Noelle,
>
> I have gone through your list and found out about the following facts:
>
> *0.)*
> My ServiceProfileURL looks like this:
> file:/N:/arbeit/cougaar/programming/CougaarControl/src/data/serviceprofiles/
>
> Does this look right to you?
It's fine so long as that's the correct path to your service profiles. 
Are you writing your own method to generate it or using the method 
provided by org.cougaar.servicediscovery.Constants?
>
> *1.)*
> The SimpleSDRegistrationPlugin.isProvider() -> returns with true
>
> I don't understand this code in the SimpleSDRegistrationPlugin:
>
> protected void initYPInfo() {
>     Collection params = getParameters();
>    
>     if (params.isEmpty()) {
>       IllegalArgumentException iae = new IllegalArgumentException();
>       log.error("SDRegistrationPlugin: no YP agent parameter" +
>         " - unable to register.", iae);
>     } else {
>       ypInfo = new YPInfo((String) params.iterator().next(),
>               _*null*_, false, false);
>     }
>
> It puts null to the new YPInfo, where there should be inserted a 
> YPCommunity, so I guess this is inserted at another point in the code, 
> but where. The SimpleSDReg..Plugin prints out
>
> /DEBUG - SDRegistrationPlugin - MTA: : ypInfo = 
> org.cougaar.servicediscovery.plugin.SimpleSDRegistrationPlugin$YPInfo at 138b0d5/
>
> In the SimpleSDR..Plugin the code for the community doesn't set the 
> community:
>
> protected void findYPCommunity() {
>     Community ypCommunity =
>       
> communityService.getCommunity(getYPCommunityName(ypInfo.getAgentName()),
>                     new YPCommunityResponseListener(ypInfo));
>    
>     if (ypCommunity != null) {
>       ypInfo.setCommunity(ypCommunity);
>       if (log.isDebugEnabled()) {
>     log.debug("Registering: " + getAgentIdentifier() + " with " +
>           ypInfo.getCommunity().getName());
>       }
>       initialRegister();
>     } else if (log.isDebugEnabled()) {
>       log.debug("waiting on community info " +
>         getYPCommunityName(ypInfo.getAgentName()));
>     }
>
> it instead runs the else branch (yellow part) of the code and issues:
>
> /DEBUG - SDRegistrationPlugin - MTA: waiting on community info 
> TrySimFactoryYPA-YPCOMMUNITY/
>
> So I assume it did not find the community. Then the initialRegister() 
> doesn't get called, because readyToRegister() return false:
>
>  if (ypInfo.readyToRegister()) {
>     if (log.isDebugEnabled()) {
>       log.debug("Registering: " + getAgentIdentifier() + " with " +
>             ypInfo.getCommunity().getName());
>     }
>     initialRegister();
>       }
>     }
>
> To sum up, the community does not get found, the registration is 
> therefore not completed.
Short answer - SimpleSDRegistrationPlugin calls  findYPCommunity() to 
find the YP community for the specified agent. (That's the point of the 
initial null value in the ypInfo structure.) So it looks like there's 
something wrong in the way you've set up the community support via 
Communities.xml. The CommunityViewerServlet should show you the yp 
communities in the running society so you can see how the Cougaar is 
interpreting your Communities.xml Section 3.2.10 of the Cougaar 
Developer's Guide also addresses Cougaar community support.

>
> *2.)*
> I have attached my Constants.java to let you see, whether the roles 
> are defined correctly.
Looks fine to me.
> *3.)*
> About the MilitaryServiceScheme, this is what bothered me most as 
> well, because I thought, when using the pizza example as my 
> foundation, I would automatically use the COMMERCIAL_SERVICE_SCHEME, 
> when I look into the servlet, I also see, that the MMQuery refers to 
> the MilitaryServiceScheme. What can I do about it? I have not 
> overwritten the getServiceScheme. However I have copied the 
> MatchMakerPlugin to my Plugins for debugging reasons, but it still has:
>
> protected String getServiceSchemeForRoles() {
>     return Constants.UDDIConstants.COMMERCIAL_SERVICE_SCHEME;
>   }
>
> in it.
>
Is it possible that your plugin somehow extends 
org.cougaar.servicediscovery.plugin.MatchmakerStubPlugin instead of 
SimpleMatchmakerPlugin? MatchmakerStubPlugin does reference the 
MilitaryServiceScheme when generating ServiceClassifications based on 
MMQueryRequests - see MatchmakerStubPlugin.addRQ().
> I hope you don't find this mail too confusing and the formatting gets 
> transmitted right.
>
> Looking forward to hear from you. I really appreciate your help.
>
> Thank you very much. Yours, Christian
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cougaar.org/pipermail/cougaar-developers/attachments/20080630/8863ec6b/attachment.html