Status of previous version

By old versions as soon as a message arrives at the JMS server, it will be delivered to its client(HPM server) at once. And with this message a correcponding task for asset assignment will be created and stored in a queue of a server job. If the HPM server is crashed or restarted, then all unprocessed tasks for assignment can not be continued, because:

• such tasks exist only in memory, all information about assignment are lost by crashed or restarted server

• JMS message can not be delievered again after restart, as message acknowledgement is already happened right after the “onMessage” method returns successfully after invoking consumer’s MessageListener at HPM server.

Solution with refactoring

The JMS asset event processing mechanism is refactored to be able to handle the corresponding tasks continuously:

1. The server jobs does not use the Taskqueue any more(not inherit from TaskQueueJob any more ), but receives and processes the corresponding JMS message consecutively.

2. Asynchronous + synchronous: by old versions the JMS messages are delievered only with Asynchronous mode, it is refactored also with Synchronous mode, so that a server job can receive and process the corresponding message consecutively.

   1. Asynchronous: JMS provider deliver messages to a client as they arrive; a client does not have to request messages in order to receive them. It is implemented with a MessageListener at Cosumer.

   2. Synchronous:HPM server should explicitly call a message consumer's “receive” or “receiveNoWait” method to get the next message.

3. Each Message Queue is processed in owner session to improve the performance. And each session processs the messages with the ActiveMQSession.INDIVIDUAL_ACKNOWLEDGE mode, it means, that the acknowledge method of the message should be always called explicitly to acknowledge message. If this method is not called by any exception, the message will be delievered again after HPM server restarts.

   1. AUTO_ACKNOWLEDGE(used by old versions):

      • Asynchronous: acknowledgement happens right after the "onMessage" method returns successfully after invoking consumer’s MessageListener at the HPM server. Thus if the message is successfully parsed to corresponding task, then such message can not be delievered again, even if the corresponding task is not successfullly performed.

      • Synchronous: acknowledgement happens before the call to a message consumer's "receive" method returns a message. Thus if the JMS provider or message consumer crashes before “receive” returns the message to the consumer, the message will be lost.

   2. INDIVIDUAL_ACKNOWLEDGE: acknowledgement happens with the call to the acknowledge method of the message, thus we can explicitly acknowledge message after all corresponding tasks are successfully finished. If this method is not called by any exception, the message will be delievered again after HPM server restarts.

4. By old verisons the Media Manager defines only one queue, and now it has more queues and one special queue for AssignDocument, NewDerivative JMS, thus the corresponding messages for assignment can be efficiently processed in owner session, and the correct order of the message for AssignDocument and NewDerivative will be kept.

   At the Media Manager the following new message queue are adjusted for AutoAsisgnment and AssetModified, which are adjusted also in the corresponding workflows:

   • JMS message with topic "AssignDocument" and "NewDerivative" : will be send to Message Queue heiler.hmm.backend.event.assignment

   • JMS message with topic "AssetModified": will be send to Message Queue heiler.hmm.backend.event.assetModified

   • all other JMS messages will be send to Message Queue heiler.hmm.backend.event

5. Each Queue has several Topics and each topic has several Listeners which is extedned with Extension Point:com.heiler.ppm.mediaasset.server.opasg.notificationListener.

6. In the previous versions all JMS messages are asynchronouly received in HPM server, and the corresponding tasks are stored in a task queue to precess the JMS with furher logic. Such task queues are not used any more in this new JMS handling mechanism, by which the in Extension Contribution of com.heiler.ppm.mediaasset.server.opasg.notificationQueue defined server job should consecutively receive and trigger the tasks for the next message which is send to the Message Queue of Synchronous mode. if any exception during process occurs, it will be written in ProblemLog. And such server job should also record the useful information for user, e.g. how many messages are received, what is the last processd asset id. Default the AssignDocumentJob is defined to process the messages of the Queue heiler.hmm.backend.event.assignment, and UpdateModifiedAssetJob is for the messages of the Queue heiler.hmm.backend.event.assetModified. The following image indicates the status of the AssignDocumentJob which shows that the unprocessed messages can be processed furthermore after HPM server restarts.

   

7. The same task for AssignDocument can be also performed in Import job by PostImport mode. Other than the previous versions, such tasks run synchronously in post import step of the Import job, that means, the post import step can be finished only after all AssignDocument tasks are finished.

Configuration

1. change of hmm.properties:

   1. Remove

      Removed properties

      hmm.notification.port=61616

      hmm.notification.protocolPrefix=failover:

      hmm.notification.connectionOptions=?wireFormat.maxInactivityDuration=0

   2. Create an new setting hmm.jms.connection.url which contains all information of the above mentioned removed settings for connection URL to Media Manager JMS server.

      New Property

      hmm.jms.connection.url=failover:tcp://Hsis465:61616?wireFormat.maxInactivityDuration=0

2. Alll messages of one certain Message Queue should be received by synchronous mode or asynchronous mode, which is initialized by contribution of the follwoing new Extension Point com.heiler.ppm.mediaasset.server.opasg.notificationQueue:

   1. Attribute queue indicates the name of the corresponding Message Queue.

   2. Attribute synchronousReceipt indicates whether the message receipt from the corrsponding queue will be done synchronously. By synchronous mode the corresponding receive method has to be called in a loop to recieve the messages consecutively. By asynchronous mode the messages will be received asynchronously with a message listener. Default value is false. Important: a queue can receive message only by one mode: either synchronously or asynchronously, therefore it is not allowed, that the same queue is contributed by different modes.

   3. Attribute receivedByServerJob is only meaningful if synchronousReceipt is true. That means, by synchronous mode the message of this queue should be received by an explicit synchronous call which is performed usually by a server job. The attribute "receivedByServerJob" indicates the identifier of such server job. If the queue receives the message in the asynchronous way, then this attirubte will be ignored.

      

3. The JMS message can be received by a MessageListener(aynchronous mode) or by a message consumer's “receive” or “receiveNoWait” method(synchronous mode). After message receipt the desired message handling tasks will be performed, and only after all tasks are successful finished, the acknowledge method of the message will be called. The corresponding tasks for certain message should be performed in a Listener which must be initlaized by contribution of the follwoing Extension Point com.heiler.ppm.mediaasset.server.opasg.notificationListener:

   1. Attributes

      • Attribute topic indicates the message topic this notification listener is listening to.

      • Attribute class indicates the listener implementation which is informed if a notification event is received from the PIM Media Manager.

      • Attribute queue is the message queue to which this notification listener is listening. It should be selected from the Extension Contribution of the Extension Point com.heiler.ppm.mediaasset.server.opasg.notificationQueue

   2. All not successfully processed messages will be kept in JMS server. E.g, during processing an error occurs, or no corresponding notificationListener is defined. Therefore in Stadard PIM an corresponding notificationListener is already defined for all default message topics which are defined in the standard Media Manager, even if no concrete handling task is implemented for such message topic. E.g. the message with topic "ModifyDerivative" which is defined in standard Media Manager, but we have no correponding handling task at Product Manager side, nevertheless an new ModifyDerivativeNotificationListener is defined, so that such messages will be ackonwledged(removed) from JMS server.