ReceiverPool is a JMS message consumer that creates, destroys and maintains multiple pools of on-demand receivers. It listens to an XQueue for requests carried by ObjectMessages. The incoming message is supposed to contain a task map with the URI and a transmit XQueue, etc. ReceiverPool evaluates the URI to figure out the details of the request. If the request is to ask for a new receiver, it first looks up the classname of the implementation based on the URI and the given properties. Then ReceiverPool tries to check out the pool of the classname from the cache. If there exists the receiver pool for the implementation, it just checks out a new instance of the receiver with the given properties. Otherwise, ReceiverPool will create a new pool for the classname and checks out a new instance of the receiver from it. It then starts up a new thread on the receiver and returns the thread back. The requester is supposed to monitor the status of the thread in order to tell the status of the receiver. The requester is also able to control the receiver via the associated transmit queue. ReceiverPool will frequently monitor the status of all active receivers in every heartbeat. If any one of them is stopped or closed, ReceiverPool will checkin the receiver and clean up the cache. If the request is to return the used thread, it will check in both the thread and the receiver.
URI is used to identify the data source and the implementation. ReceiverPool parses the URI string and creates a map with all XML properties from the key-value pairs specified in the query-string. Therefore, requesters can add multiple properties to the query-string for a new receiver. In case the URI contains its own query-string, the URI separator, &URI=&, must be used to separate the original query-string and add-on properties. So please carefully define the add-on properties in the query-string of the URI. ReceiverPool also allows default properties defined for each implementation. If any of the default properties is missing in the URI, PersisterPool will copy it to the XML property map before the instantiation of the MessageReceiver.
Apart from the common properties, there are many implementation specific properties for PersisterPool.
Property Name | Data Type | Requirement | Description | Examples |
---|---|---|---|---|
Heartbeat | integer | optional | interval in sec to check outstanding requests | 30 (default: 60) |
MaxNumberReceiver | integer | optional | max number of receivers | 32 (default: 256) |
DefaultPoolSize | integer | optional | pool size for new receivers | 8 (default: Capacity of the node) |
Template | string | optional | template to build the URI | |
URIField | string | optional | field name for URI | (default: URI) |
RCField | string | optional | field name to store return code (0 for success) | (default: ReturnCode) |
DefaultProperty | list | optional | list of default property map for new receivers | see example |
Here is an example of ReceiverPool:
{ "Name": "pstr_pool_in", "ClassName": "org.qbroker.persister.ReceiverPool", "Operation": "accept", "LinkName": "ipool", "Capacity": "128", "XAMode": "1", "MaxNumberReceiver": "512", "DefaultPoolSize": "32", "Heartbeat": "60", "DisplayMask": "13", "StringProperty": { "URI": "ipool" }, "DefaultProperty": [{ "ClassName": "org.qbroker.persister.StreamReceiver", "URI": "tcp://localhost:7225", "Operation": "read", "EOTBytes": "0x0a", "TextMode": "1", "Mode": "daemon", "KeepAlive": "true", "SOTimeout": "60", "ReceiveTime": "1000", "RetryTimeout": "300", "PauseTime": "5000", "StandbyTime": "12000", "PoolSize": "128", "DisplayMask": "0" },{ "ClassName": "org.qbroker.persister.JMSReceiver", "URI": "mq://localhost", "QueueName": "YLU", "Operation": "get", "Mode": "daemon", "MaxIdleTime": "900", "PoolSize": "128", "DisplayMask": "0" },{ "ClassName": "org.qbroker.persister.JMSSubscriber", "URI": "mq://localhost", "TopicName": "YLU", "Operation": "sub", "Mode": "daemon", "MaxIdleTime": "600", "PoolSize": "128", "DisplayMask": "0" }] }