Skip to content

reducing complexity #1

manzke opened this Issue Jan 24, 2012 · 3 comments

2 participants

manzke commented Jan 24, 2012


I stumbled about your tayler, because I looked today at HawtJournal and Journal.IO.

I just want to leave a link, because I think, you have a lot of complicated stuff in your taylor implementation, which is not necessary.

Some time ago, I created a Websockets-based Tailor implementation:


  • if a file is rotated, you don't need to reopen it / just seek to 0
  • raf is able to read a line (RandomAccessFile.readLine()) / why are you doing all the stuff?! :)

Have fun. :)


Hi Daniel,

thanks for your feedback, much appreciated.

To address your two complexity points:

1) File rotation.
I kept that trick from the original codebase, coming from Apache Commons: it should address some incompatibilities with file seek in case of rotation, never actually tested it but it doesn't hurt, so I left it there.

2) Line reading
There are two notable differences: RandomAccessFile.readLine() isn't buffered and blocks until the line ending condition is met.

Hope that helps clarifying the implementation: do you see any other complexity points?

manzke commented Jan 25, 2012


thanks for your feedback. The readline is interesting. I'll have a look at it.

What I "don't like" is the manual delay of the thread. I would encapsulate this stuff into the executor like you have described it in your javadoc. (but with a real executor :))

For myself I try to remove all manual thread handling from the code. Executors and ExecutorService are pretty nice tools. :)


You're generally correct about Executors, but I think they wouldn't provide such an improvement over current approach to justify a refactoring: I've got it from the previous Apache implementation, it worked and again, I kept it :)

@sbtourist sbtourist closed this May 7, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.