Trigger issue?

, ,
1

Dear wmUsers,

In one of our integration we are using a request and reply mechanism. The time out for the whole process is 30 sec. If we don’t reply within 30 sec, the requester times-out. Most of the time the process completed within 2-5 sec. But some times it fails to send the reply within 30 sec. According to our log history, it shows that once the document get published it stays in broker for long time (~25-30 sec) before the trigger picks it up.

  • the documents are small in size (<10Kb)
  • the capcity of the trigger is 50 with refill level of 15, concurrent with 15 max thread execution.

Have you experience such problem? If yes, i would appreciate your suggestions.

Thanks,
Kerni

2

Are you experiencing a high volume when this happens?

3

I have seen this problem both during high and normal volumes.

I have one doubt about how the trigger works tho`.
Lets say we have a trigger with property:

  • capcity: 10
  • refill level: 4
  • Max exec thread: 2
  • Process mode: concurrent
    And lets assume we have 100 documents in broker queue related to this trigger.

Initially the IS will fill the trigger queue with 10 documents to be processed and the trigger will invoke two associated services at a time and after the trigger queue reaches 4, the IS will refill the trigger queue.

Now my questions is, once the trigger is refilled does it sort the documents so that the documents will be processed as first come first serve way or it is a random process.
If it is random, then there is a probability that the first 4 documents will stay in the queue until the 96 documents gets processed.
Do you have any details regarding this?

thanks for your reply
kerni

4

Although I haven’t seen any documentation that states this, I doubt it that it’s random. When processing is set to Serial, the documents are processed First In, First Out to guarantee order. So it wouldn’t make sense to me if just because processing mode is set to concurrent, the documents would be processed in a random order.

By the way, by definition, documents are added to a queue at the end of the queue (or tail). Therefore, there is no need to resort the queue once more documents are added. The order is inherently kept by the pure nature of the Queue.

  • Percio
5

The queue integrity will remain intact (FIFO). What will introduce apparent randomness is the thread scheduler in the JVM.