Restarts: question on how to avoid replays

[Andrew Oswald]

Hello Chronicle folks, hope all is well.

I'm using ServiceWrappers, providing input and output source ids, but do have the occasional lull in appender activity lasting longer than roll cycles (in my case, daily).  If my application restarts after one of these lulls of appender activity, I get the log message (see below), but was definitely not expecting my input queue to be "replayed".  Is this a bug?  If not, can you provide some suggestions on how to avoid the replays?

Here's the log message:

{main/core-event-loop} net.openhft.chronicle.queue.impl.single.SingleChronicleQueueExcerpts - Rolled 3 times to find the next cycle file. This can occur if you appenders have not written anything for a while, leaving the cycle files with a gap.

thanks!

-andy

[Rob Austin]

can you send the stack trace from this log line, in net.openhft.chronicle.queue.impl.single.SingleChronicleQueueExcerpts

I think you will find its just trying to get the last cycle as you have just restarted, but if you send me the stack trace from this point in the code, I can take a look and tell you for sure.

Rob

--
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.

[Andrew Oswald]

Thanks, Rob.

Are you suggesting new Throwable().getStackTrace() there?  If something else, please advise.

thanks again!

[Rob Austin]

yes, you could do that or put a break point in the debugger ( in your IDE ) and send me the call stack from the debugger.

Note : Chronicle-Queue  does not record which is the last cycle file, when you start up it looks at the files on your file system to determine what the last cycle is.

This code below is reporting that when trying to find the next cycle file, a cycle file was missing and so was skipped, ( this is possibly happening on startup ).

It make sense in your case because you did not write anything to one of the cycles. It’s highly likely that chronicle-queue is not attempting to read every message in each file, rather just looking at the cycle files them selves. I’ll be able to see more of whats going on in your case with the call stack.

Rob

[Andrew Oswald]

I thought replaying some of the .cq4 files locally would reproduce it, but that doesn't seem to be the case.  Afraid I can't provide a stacktrace.  I'll put a little more thought into it, but it's likely not going to happen.

Given that I know for certain that the appender hasn't been written to, what can be done to avoid the replays?

thanks!

[Rob Austin]

On 17 Oct 2016, at 16:06, Andrew Oswald <andrew...@gmail.com> wrote:

Given that I know for certain that the appender hasn't been written to, what can be done to avoid the replays?

I don’t think it’s replaying, I think its more likely that chronicle-queue is just looking at the directory to see what cycle files are available.

[Andrew Oswald]

I've observed its output and it's replaying.

[Rob Austin]

understood, ( I understand that you have having issues reproducing this ), but 

if you are able to put together a simple test case that reproduces the problem, we will merge this test case into Github and fix the issue.

thanks

Rob

[Andrew Oswald]

Will put some additional thought into it...  One question, is the file's timestamp taken into consideration as opposed to its name?

Thanks for the prompt correspondence, Rob, I really appreciate it!

[Rob Austin]

It only uses the filename to resolve which cycle files are available.