ChronicleQueue, events and/or thread waiting

54 views
Skip to first unread message

victo...@gmail.com

unread,
Jun 24, 2015, 8:06:11 AM6/24/15
to java-ch...@googlegroups.com
Hi,

If I understood well, the API provided around ChronicleQueue (I think I'm talking about v3 :) is non-blocking: in the example it shows that to know if there is something new in the queue, you would use a loop like this to know if there is more to read:

while(!reader.nextIndex());

What I am wondering (pardon my low skills in thread-stuffs) is if doing that I won't be constantly be running my thread instead of having it being woke up when there is more to read.

So is there some kind of way to get notified of new things, either by an event or by a blocking operation like Object.wait()?
Or am I wrong and the code I just cited does just that?
Or is it impossible because the tailer can only read and is not "notifiable" by another process?

Thanks!

Victor

Peter Lawrey

unread,
Jun 24, 2015, 1:06:36 PM6/24/15
to java-ch...@googlegroups.com

You have two options;
- you can create a stateless client which listens to a TCP connection and this will block when there is nothing to read.
- or you can busy wait on the queue to receive new events. Normally you would only do this when the ~10 us it takes to receive the data via tcp is unacceptable.  Busy waiting works best when you want the minimum latencies and jitter.

--
You received this message because you are subscribed to the Google Groups "Chronicle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to java-chronicl...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Luca Burgazzoli

unread,
Jun 24, 2015, 1:59:18 PM6/24/15
to java-ch...@googlegroups.com
If you are on the same host you can use a tcp client that shares the data files with the source. If I'm not mistaking the method to configure this is sharedChronicle(true) on ChronicleQueueBuilder

With such configuration the client will blocks and waits for new events. When the client waits, the source busy check for events then notifies the client.


--
lb

victo...@gmail.com

unread,
Jun 25, 2015, 3:41:39 AM6/25/15
to java-ch...@googlegroups.com
Thanks both of you.

If I understand well if I use a TCP client (instead of working directly with a chronicle), I can take advantage of the TCP behaviour to be notified (by blocking).
And if I do it while using sharedChronicle (while being local), I can even read and write as with working directly with a chronicle.
And if it's the same JVM, I just need to implement my own notification mechanism (which isn't hard :).

Thank you!

Victor


Le mercredi 24 juin 2015 19:59:18 UTC+2, Luca Burgazzoli a écrit :
If you are on the same host you can use a tcp client that shares the data files with the source. If I'm not mistaking the method to configure this is sharedChronicle(true) on ChronicleQueueBuilder

With such configuration the client will blocks and waits for new events. When the client waits, the source busy check for events then notifies the client.

On Wednesday, June 24, 2015, Peter Lawrey <peter....@gmail.com> wrote:

You have two options;
- you can create a stateless client which listens to a TCP connection and this will block when there is nothing to read.
- or you can busy wait on the queue to receive new events. Normally you would only do this when the ~10 us it takes to receive the data via tcp is unacceptable.  Busy waiting works best when you want the minimum latencies and jitter.

On 24 Jun 2015 1:06 pm, <victo...@gmail.com> wrote:
Hi,

If I understood well, the API provided around ChronicleQueue (I think I'm talking about v3 :) is non-blocking: in the example it shows that to know if there is something new in the queue, you would use a loop like this to know if there is more to read:

while(!reader.nextIndex());

What I am wondering (pardon my low skills in thread-stuffs) is if doing that I won't be constantly be running my thread instead of having it being woke up when there is more to read.

So is there some kind of way to get notified of new things, either by an event or by a blocking operation like Object.wait()?
Or am I wrong and the code I just cited does just that?
Or is it impossible because the tailer can only read and is not "notifiable" by another process?

Thanks!

Victor

--
You received this message because you are subscribed to the Google Groups "Chronicle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to java-chronicle+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Chronicle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to java-chronicle+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--
lb

Peter Lawrey

unread,
Jun 25, 2015, 4:58:44 AM6/25/15
to java-ch...@googlegroups.com
Hello Victor,
   yes, that is all correct.  You could also have a dummy TCP connection without the contents of the message between JVMs just for the notification, though I don't know anyone who does this.

Regards,
   peter.

To unsubscribe from this group and stop receiving emails from it, send an email to java-chronicl...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Chronicle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to java-chronicl...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--
lb

--
You received this message because you are subscribed to the Google Groups "Chronicle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to java-chronicl...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages