Community for yuuvis® RAD

0 votes
by (150 points)
edited by


we are currently implementing a microservice that we connect to the Yuuvis ActiveMQ via JMS. We have followed this example ( Service Usage) and so far everything is working fine.

Now the question: The example implies that a JMS message can contain n documents/items.

  "messages": [
      "itemid": "7FA37B7A959A421E8769EB4FAA18F39F",
      "versionid": "ECE2CCF164174D8CAE86E598C8EA392C",
      "disableQueing": false,
      "messageid": "0E0E453A2CD44491ABB99FFA1D729660",
      "action": "new",
      "typeid": "DF56A82C63AE402F894B5FFAABCAFE58",
      "version": 1,
      "typename": "thetype"

Up to now we could not reproduce an JMS message with multiple dcuments in the DEV environment. Since we work with redeliveries ,for example if the subsequent processing goes wrong, we actually always want a 1:1 relationship between document and JMS message.

Is it possible to configure that it is always a 1:1 relationship?
When would there be multiple documents in one message?

Bonus question:
Is it "safe" to consume the dead letter queue (ActiveMQ.DLQ) or is Yuuvis consuming this queue?

Many thanks and best regards

1 Answer

0 votes
by (12k points)

Hello Martin,

messages with multiple items will appear when you use one the DmsBatchService.create endpoint or the subsequent fulltext indexing operation for example.
The format is {"messages": [{"itemi1"},{"item2"},...]}

The index-service can handle both types of messages and it is not possible to tell it to reject messages with multiple items.

The advantage of multiple items in one message is that the items can be processed in one transaction and thus the overhead per item is reduced. Also subsequent processing steps are only called once for all items and not for every single one.

Bonus: yuuvis currently doesn't consume the DLQ, so you can safely use it for your purposes.

Best regards

by (150 points)
Hi Nicolai,

thank you very much for your answer.

Because we have to process each document individually within a transaction, we came up with the following solution.
If necessary, we split the message and send each document to a different topic.  We then consume the messages with the individual documents from this topic.

Best regards

Related questions

+1 vote
2 answers
+1 vote
3 answers
0 votes
1 answer