I'd be chuffed to get some feedback on this proposal (after the current log4j emergency has calmed down, of course). Thanks.

@faxm0dem @mcorbin Any thoughts?

Without looking at the implementation, my opinion is that this would be okay for 99% of use-cases. But what about the other 1%?
If we decide to merge this, I guess it would require a major version bump? Oh wait, we're still < 1.0...

I would like to do something to make this easier for new users. I proposed a few solutions in #957, and maybe folks would be interested in exploring solutions in that issue. This PR is the solution that I prefer, because it doesn't add any new functions, or require more documentation to explain the subtleties of index (which should probably be called index!). That function has reasonably complex behaviour, and it wasn't obvious how it worked to me when I was a new user (as we all were at some point). Even with extended documentation, it's something that people have to learn about and watch out for, instead of something that just behaves predictably.

Even James' book, which is an exceptionally useful resource for new users, doesn't capture all the nuances. It reads that index is:

[...] the function that sends events to Riemann's index. ¹

In reality, index is

a function that returns the index attached to the core that will be used after the next core transition (triggered by config [re]load). As a side-effect, it may also replace that index with a brand new one, orphaning any reapers that are attached to the existing (future) index. Whether this happens or not depends on global state. The index of the currently running core is unaffected.

That's a lot to reason about, and it trips people up. In particular, it trips up people who have their Riemann configuration spread over multiple files, if more than one of them, quite innocently, says:

(let [index (index)])

That's a mutating call (sometimes), but how does the user know that? In practice, they don't know. They just end up with broken expiry, because they have reapers attached to indices that aren't attached to cores. Thankfully, my production config has a decent test suite, so it discovered that expiry stopped working, but I'm sure there are Riemann users who don't use the (amazing) test functionally, especially if they're new.

All in all, I'm arguing in favour of behaviour that is less subtle, and gives results that are more consistent when users do things that they see as examples in the documentation and The Art of Monitoring.

_{1. https://artofmonitoring.com/TheArtOfMonitoring_sample.pdf Page 23-24.}

I pretty much agree to what you're saying, but I'll leave the decision to more experienced riemann contributors.