Placement in NetarchiveSuite software
Every channel is named after the set of applications instances that are expected to receive messages sent to it. All channel names are constructed privately in the
dk.netarkivet.common.distribute.ChannelID class. To get a channel, you must use one of the public methods in
There are to types of channels used in the JMS protocol:
- Queue where only one listener takes a message from the channel. For example a queue where a request for doing a harvest is only received by one harvester.
- Topic where all listeners takes a copy of the message. For example a batch job which has to be executed by all bitarchive applications.
In NetarchiveSuite we use a naming convention that topic channel names include the string "_ALL_" and the suffix "_TOPIC".
The structure of channel names is as follows:
- Environment Name value must be the same for all channels on all JVMs belonging to a single NetarchiveSuite installation. It identifies the environment for the queue, e.g.: "DEV", "TEST", "RELEASETEST", "CLOVER", "PROD" or initials of developer running personal environment for e.g. sanity tests. It is read from the setting
settings.common.environmentNameof the NetarchiveSuite installation.
ReplicaID Name of the replica (ie the "location" in a distributed system), or COMMON if channel shared by all replicas.
- Channel Specifier Prefix if present is one of the following:
- THE - communicate with singleton in the system.
- THIS - communicate with one uniquely identified instance of a number of distributed listeners.
- ANY - has all instances listening to the same queue.
- ALL - is used for topics only, i.e. topics are sent to all listeners on the channel
- Channel Specifier simply expresses what the channel is used for. By convention this (usually) describes what kind of application should listen on this channel.
Here is a complete list of the channels in an actual realistic distributed NAS system (IP addresses have been anonymised for security reasons).
Topic used by the harvesters to call in ready for new jobs
|SystemTest_COMMON_HARVESTMON||Queue to which harvesters send messages showing crawl progress for display in the GUI|
|SystemTest_COMMON_HCHAN_VAL_REQ||Queue for harvesters to register the harvest channel they are processing jobs from.|
|SystemTest_COMMON_HCHAN_VAL_RESP||Queue for response from the HarvestManager to the Harvesters requesting HarvestChannel registrations.|
Queue for sending messages to the IndexServer
|SystemTest_COMMON_JOB_PARTIAL_HIGHPRIORITY||Queue used to send jobs to the selective harvesters in the highpriority pool.|
|SystemTest_COMMON_JOB_SNAPSHOT_LOWPRIORITY||Queue used for sending jobs to the harvester configured for snapshot harvesting.|
|SystemTest_COMMON_MONITOR_TOPIC||Topic for the monitor registry|
Queue for sending messages to the ArcRepository.
|SystemTest_COMMON_THE_SCHED||Queue on which HarvestControllers reply with status messages to the HarvestScheduler.|
Queue on which a specific HarvestControllerServer listens for responses from the IndexServer
|SystemTest_COMMON_THIS_REPOS_CLIENT_xxx_225_xx_xxx_HCS_SBHIGH_H3||One-per-client queue on which client (in this case a HarvestControllerServer) receives replies from the repository.|
|SystemTest_COMMON_THIS_REPOS_CLIENT_xxx_226_xxx_xx_WI||One-per-client queue on which client (in this case a WaybackIndexer) receives replies from the repository.|
|SystemTest_COMMON_THIS_REPOS_CLIENT_xxx_226_xxx_5_IS||One-per-client queue on which client (in this case an IndexServer) receives replies from the repository.|
|SystemTest_COMMON_THIS_REPOS_CLIENT_xxx_226_xxx_5_VP||One-per-client queue on which client (in this case a ViewerProxy) receives replies from the repository.|
|SystemTest_CS_THE_CR||Queue for sending messages to a specific Checksum replica (the replica named CS).|
|SystemTest_KB_ALL_BA_TOPIC||Topic for broadcasting messages to all bit archives at KB|
|SystemTest_KB_ANY_BA||Queue for sending a message to any one of the bitarchive applications at KB|
|SystemTest_SB_THE_BAMON||Queue for sending messages to the bitarchive monitor at SB - ie to run batch jobs on the SB replica.|