Troubleshooting and Frequently Asked Questions

 

Troubleshooting

  1. Make sure your class path includes the Salsa distribution and your compiled Salsa code class files.
  2. Check your CLASSPATH environment variable if you are not explicitly setting the class path on the command line.
  3. Make sure all theaters have access to the same versions of class files needed for the actors that will run on them.
  4. Make sure all theaters are running the same version of Java. Certain classes will not serialize between different versions.
  5. Be sure to restart the theater each time a class file changes.

 

FAQ

Question: Now that bind has been removed from the SALSA language, how to I start an actor with a given UAN or UAL when it is ran?
Answer: You can specify the UAN or UAL of an actor at runtime with the following commands:
                        java -Duan=<UAN> -Dual=<UAL> -Didentifier=<Identifier> myactor.salsa
An actor can be created at runtime with only the "uan" system property,  this will bind the actor with the given UAN, and a system specified UAL.  If both the "uan" and "ual" system properties are specified, the actor will be created at the UAL specified and bound to the given UAN -- creating an actor remotely if needed.  If an actor is to be created locally with a given UAL,  this ual can be specified with the "identifier" system property, appending this identifier to an rmsp string specifying the local theater.  This can be used in conjunction with the "uan" system property, but not the "ual" system property.
 
Question:  How do I get a reference to a service actor by its UAN?
Answer: Assume the actor has type MyActor:
 MyActor myActorReference = (MyActor)MyActor.getReferenceByName(uan);

 
Note that the return values of the methods must be casted to the appropriate type,  however this will be fixed in the upcoming version.
 
Question: How do I compile the source distributions?
Answer: Compile all the java files in the salsa/wwc/ and salsa/ packages. (e.g. javac -g `find salsa/ | grep Java$'` )
 
Question: How do I run the examples in the examples directory?
Answer: Well, compile it and run it. See "How to compile and run SALSA programs".
 
Question: What version of Java should I use?
Answer: Salsa was developed using the Java 1.4.1 compiler and virtual machine but the grammar is based on the Java 1.2 grammar. Some language features, such as assertions, will not parse with the salsa compiler. There is a noticeable difference between JDK 1.4 and earlier JDKs in terms of performance when using graphical debuggers and especially profilers for debugging Java programs in general.
 
Question: I think I found a bug. What information should I send to the developers with my bug?
Answer: It's best to send a description of the problem you encountered, what you were trying to accomplish, and the code you used to generate the bug. Please don't hard code UANs or UALs and it is very helpful if programs output usage information or are well commented. Please send the problem to salsadev@cs.rpi.edu. Generally we will try to reproduce your problem and recommend a workaround if possible.
 
Question: Is there any protection against overwriting universal names?
Answer: Not yet, but security in naming is being researched.
 
Question: Do behaviors have to be placed in modules?
Answer: Behaviors that are not in modules will now compile.
 
Question: How can I use Swing with Salsa?
Answer: Swing was designed to not be thread safe so invoking methods on Swing objects directly is not a good idea. Several salsa programs demonstrating universal naming and migration are written using swing. The SwingUtilities.invokeLater( ... ) method must be used.

To send a message from a swing component to the actor that contains it:

public void sendMessage( String messageName, Object argument ) {
   Actor[] _targets = { owner };
   String[] _methodNames = { messageName };
   Object[][] _arguments = { { argument } };
   owner.send( new Message( owner, _targets, _methodNames, _arguments ) );
}

To invoke a method on a swing component:

/**
This method is placed in the Swing Component, in this case a window
containing a Board panel for drawing.

This method is invoked by the Actor thread when it receives
a updateMouse message from a peer.
*/
public void updateMouse( final Point p, final String uan ) {
   Runnable r = new Runnable() {
        public void run() {
             board.movePointer( uan, p );
        }
   };
   SwingUtilities.invokeLater( r );
}
/**
This message handler is placed in the containing actor. It invokes the above method on the Swing component.
*/
void updateMouse( Point p, String name ) {
   board.updateMouse( p, name );
}

 

 

Question: Can I overload message handlers? What are the potential restrictions?
Answer: Message handlers can be safely overloaded in many cases. If two or more message handlers with the same name differ only because one takes primitive wrapper types and the other takes the corresponding primitive types, the handler with the composite types will be chosen. If if a message is received with all null arguments and two or more handlers with the same name and same number of arguments are defined for that message, the runtime will not be able to resolve the message handler. (The null value does not have an associated type in Java, and no static checking is done for message resolution.)
 
Question: I'm trying to debug my program and I'm confused where my message handler code ends up.
Answer: You must run the debugger on the VM that your code is running on- so you might have to point the debugger at an instance of wwc.messaging.Theater and then wait till the actor migrates to the theater.
Salsa files are compiled into Java classes containing and Actor class and an inner State class. Message handlers are placed in the inner state class, the Actor class contains constructors, acts as a forwarder and provides type checking for actor references. Using a conventional debugger is possible, but you must place break points carefully.
 
Question: What should I expect in future releases?
Answer: Code mobility, applet theaters, location specific message sending and naming, resource discovery, asynchronous exception passing, autonomous actor mobility, to name only a few products of current research.
 
Question: Can I change the listening IP address for a theater/nameserver?
Answer: Yes, the netif option will do. After getting an appropriate network interface name (e.g., eth0, eth1, wlan0, lo,...) by the ifconfig command on Unix-based systems, you can specify it when running a theater/nameserver as follows. Note: for those who use windows-based systems, ipconfig does not give you a list of network interfaces, so please use ListNetIfs.java to get it instead.

 

return to the salsa home page