Unlike conventional middleware platforms, the AMETAS agent system infrastructure occupies a considerable part of the runime environment. It is therefore important for the kernel design to isolate failures from applications so that one failing application cannot do harm to the rest of the runtime environment. However, there are cases when an application turns the place into a state so that a restart of the application is difficult or even impossible. Consider this example:
Imagine you have a user adapter starting a set of agents. The first thing after instantiation is probably to send a message to this group of agents. The implementor chose to send the message to the group, using multicast. However, the application fails; the agents do not fetch the message. The message itself remains inside the post office.
After some debugging you found the error, and now you try to restart the application. However, your agents find the outdated message still lying in the post office and take it instead of your new message, making the application fail again.
Of course, the post office removes the outdated messages at some time, but since this can mean to wait for a considerable time before the post office cleans away this message, you will lose this time during early stages of development. One easy way - and seen ever again in many places - is to stop the whole place and restart it. But this requires you to be the administrator of the place. And remember: Stopping the place will kill all remaining agent applications currently running there!
What can we do?
Simple answer:
Avoid it.
Sounds clever, doesn't it. - In our opinion, it is a matter of good manners to let your application run in some testbed before going into the real world. A testbed is just like the real-world environment, except that only your applications are running there. You should model it to the real-world environment as closely as possible. If you encounter some problems, you may in many times simply stop the place and restart it.
But this is not all. Clever application design may also avoid these situations. In the above example, it was unwise to send the message to the group because the group address is the same for every start. A better solution would be to send a message to each agent in turn. Remember that your user adapter perfectly knows the complete Place User ID of every agent it starts. And this ID is unique for every run. So your agents will never be bothered by outdated messages from previous runs.
Other hints: