Reactions (in vs read)

[Marcelo Nery dos Santos]

Hi! I have just started using LIME. Thanks for the functionalities that this project provides.

I am not sure how can I perform an "in-like" WeakReaction. By "in-like" reaction I mean: a reaction that removes the tuple that matched the template from the space.

In other words: Some agents are looking for the same kind of tuple, once a tuple arrives in the shared tuple space, I would like that only one of them gets the method reactsTo() fired.

Another possibility would be: when the reactsTo method is called, I would awake another thread so that it could try to perform an "in" operation to get the tuple. But, as long as the "in" operation will block until the tuple is avaiable, I would have several threads blocked, and only one would get the tuple. So, this is not a valid solution.

I tried to use the "inp" operation, but for using that, I would have to know where to look for the tuple. I was not able to get this information using the ReactionEvent provided to the reactsTo method.

Is it possible to achieve this result? (i.e. to make sure that only one agent will be able to handle one tuple that arrives in the whole space?)

Thanks in advance,

Marcelo

[Amy Murphy]

Your solution with the inp will work!  The information that you need IS in the ReactionEvent.  re.getSrouce() gives you the Agent ID of the agent that is holding the tuple.  new AgentLocation(re.getSource()) should be used as the "current" parameter for the inp. (destination can be unspecified)

Note: you will need to put the inp into a separate thread (similar to what you described in your in solution).  This is because Lime does not allow remote operations inside reactions, so if the tuple is remote, I believe an exception will be thrown. 

Hope this helps.  If not, write again.

-Amy

[Marcelo Nery dos Santos]

Thanks for the fast reply.

I have just tried the solution and it worked fine in a single host.

As long as the "inp" operation is a non-blocking operation, I think that it can be used inside the reaction code (in fact, I did it). After that, I tried to use an "in" operation just to confirm that an exception would be raised (and it was).

I will validate the "inp" operation inside the reaction code in an environment of several hosts. As long as it is a non-blocking operation, I would prefer to leave it there, so that when an agent receives a tuple, this tuple will be removed from the space and no other agent will be fired for that tuple.

As I undertand, as LIME executes the reaction code until completion, removing the tuple inside the reaction code will change the tuple space, and no other reactions will be fired for that tuple.

If I run into trouble using this approach, I will use another thread to get the tuple, just the one that really gets the tuple will perform some work, the others (that gets null for the "inp") will terminate its execution immediatelly.

Thanks,

Marcelo

[Marcelo Nery dos Santos]

Hi,

As long as I am new to SourceForge, please let me know if I really should use this forum in the way I am doing.

---

Adding further information on this thread.

An easy way to check this point is to use the LIME LChat example. If we define (in LChat class):

  public void handleReactionEvent(ReactionEvent e) {
      this.processEvent(e.getEventTuple());
      try {
        System.out.println("calling inp()");
      ITuple tuple = messageTS.inp(new AgentLocation(e.getSourceAgent()),AgentLocation.UNSPECIFIED, e.getEventTuple());
      System.out.println("inp() finished! tuple=" + tuple);
      }
      catch (TupleSpaceEngineException exc) {
        exc.printStackTrace();
      }
  }

and change the method "reactsTo" in class MessageListener to:

  public void reactsTo(ReactionEvent e){
//    agent.processEvent((ITuple)e.getEventTuple());
      agent.handleReactionEvent(e);     
  }

we can launch two agents using the same Launcher and each time that a tuple is written, both handlers are called and finished successfully.

But when we use two diffetent hosts, the inp operation, that is supposed to be a non-blocking operation, blocks.

----

Suggestions:

If using an inp operation is invalid within a handler code, then: Is it possible for LIME to raise an exception, just as it does when there is an read or in operation?

Is it possible for LIME to implement an UbiquitousReaction that takes the tuple from the space (instead of giving a copy to the agent)?

----

Concluding remarks:

The solution for me:

Everytime a handler is called, a Runnable element is added to the queue (LChat example) and the handler is over. When the agent executes this Runnable, it tries to perform an inp operation. In this case, the inp operation succeeds. If the agent gets the tuple, it perform some job, if it doesn't then it discards that notification.

Major drawback: if the number of agents is high, a lot of effort is wasted: everytime a tuple matches the template for the agents, all of them will be notified, and only one will really perform some useful task.

This is the reason why I was looking for a way that only one agent gets notified, and the tuple is automatically taken from the space to the agent.

Thanks in advance,

Marcelo

[Amy Murphy]

First, clarification.  inp is allowed inside the reactsTo code only if it is local in scope. 

As for your suggestion to throw an exception instead of failing, I can likely add this to the next minor release.  I also recently fixed a bug, so a new release should be coming soon (in a week or so).

About a ubiquitous reaction that removes a tuple.  That's not something I want to address inside Lime.  I realize that it would be a nice feature, but I am not interested in extending Lime in that manner.  Sorry.

The use of this forum is fine.

-Amy

[Marcelo Nery dos Santos]

OK, thanks. I think this thread is over.

I will start another thread about the way the tuple  template works in LIME.

Once more: LIME has a lot of nice features. At a first moment I thought that it would be harder to use, but a lot of things were done in a quick and easy way. I really appreciate this job.

Marcelo