Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Waiting for the ack to go all the way back to A before sending the next record will definitely slow you down because C is essentially idle while this is happening. Why don't you move to a queuing architecture? Why not create a persistent queue on C which can receive the records from A (via B) and then have one (or many) processors for this queue sitting on C.</p> <p>This way you decouple how fast A can send from how fast C can process them. A's ack becomes the fact that the message was delivered to the queue successfully. I would use <a href="http://www.jboss.org/hornetq/" rel="nofollow">HornetQ</a> for this purpose.</p> <p><strong>EDIT</strong></p> <p>The HornetQ getting-started guide is <a href="http://docs.jboss.org/hornetq/2.2.2.Final/quickstart-guide/en/html_single/index.html." rel="nofollow">here</a>.</p> <p>If you can't use this, for the simplest non-persistent in-memory queue, simply use a ThreadPoolExecutor from Java's concurrency libraries. You create a ThreadPoolExecutor like this:</p> <pre><code>new ThreadPoolExecutor( threadPoolSize, threadPoolSize, KEEP_ALIVE, MILLISECONDS, new LinkedBlockingQueue&lt;Runnable&gt;(queueSize), ThreadPoolExecutor.DiscardOldestPolicy.discardOldest()); </code></pre> <p>Where queueSize can be MAX_INT. You call execute() with a Runnable on the ThreadPool to get tasks to be carried out. So your receiving code in C can simply pop these Runnables created and parameterized with the Record on to the ThreadPool and then return the ack immediately to A (via B).</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload