Keep track of nodeId's that were obtained by GETJOB

[mp911de]

If the majority of received messages (from client perspective) are produced on a node which the client is not connected to, it should be considered to reconnect the node from which the messages originate. This indicator is based mostly on queues and can be treated as advice. Not clear whether a reconnect is the right measure to react on the "advice" but for sure a metric to be considered in reconnects

[mp911de]

Proposal: QueueListener API for tracking the nodeId from which the client received most jobs and performing a reconnect.

API: QueueListener.create(DisqueURI disqueURI, RedisCodec<K, V> codec, K... queues) QueueListener.getjobs() QueueListener.getjobs(long timeout, TimeUnit timeUnit, long count)

Sample code:

QueueListener<String, String> queueListener = QueueListener.create(disqueURI, new Utf8StringCodec(), "myQueue");
Subscription subscription = queueListener.withNodeTracking(1, TimeUnit.MINUTES).getjobs()
        .subscribe(new Action1<Job<String, String>>() {
            @Override
            public void call(Job<String, String> job) {
                System.out.println("Received a job: " + job.getId() + ", " + job.getBody());
            }
        });

Open issues:

• Perform a reconnect/quit on a regular schedule or pass the control towards the user?
• Expose inner connection?
  • Yes, for not "wasting" resources
  • No, for encapsulating and protecting the connection. It does blocking things and one might not run into side-effects

[mp911de]

Perform a reconnect/quit on a regular schedule or pass the control towards the user? Answer: Do both.

Expose inner connection? Yes, for not "wasting" resources No, for encapsulating and protecting the connection. It does blocking things and one might not run into side-effects Answer: No

[mp911de]

Implemented.