> but they all extend DirectoryBasedIndexManager, no?
No

Can you point me to these implementions, please?

Can also re-read the Index Affinity wiki if you want to learn more about that.

Thanks, I understand there is the need for ISPN, but so far I fail to see the need for other implementations. You pointed to one issue related to ES, which I'd describe as "collecting and asynchronously sending index updates in bulks", but that sounds very different from "closing the index writer".

Again, it seems you are mixing two separate concerns here, so these should be handled differently. Or we need to find a more general name which makes sense for both applications. "Closing the index writer" just doesn't make any sense for ES at the level we use it.

Generally I think it's bad design that the invoker needs to know the implementation details;

That's the thing, who is the invoker of this method actually? I'd agree with you if it was some code in the common "engine" part of HSEARCH, but I don't see that usage. I only see it being called within ISPN query itself. Which is exactly why I am wondering what's that method doing on the IM SPI level.

So working with instanceof and see if I should be casting to some kind of IndexManager to see if I should let it know that we're needing this index shared to relinquish resources is a big no-no from design point of view.

But where is this usage in HSEARCH engine?

Please live with it, it's a sign of good design.

Sorry, I disagree We should not bloat our SPIs only needed by specific implementations. If you are after general "clean-up" hook, the method should be renamed, but then there is destroy() already. So where would be the difference?

At the very least, the method should be renamed into something more generic which actually makes sense for all backends. But as it stands, this method is not even invoked in HSEARCH itself, so I don't see why we are having it to begin with. The bits invoking the method on the ISPN side know the IM implementation they are dealing with (it's happening from within the specific sub-class itself!), so there is no need at all to have this at the IM contract itself.

And remember this is an SPI not a public API.

Sure, but this does not mean we should put less consideration into designing it properly.