1

I am using ChronicleMap in JavaEE7/CDI app. Conversation scope is used a lot. It's very difficult to predict where the user will exit the conversation in order to close the maps.

Although I am trying to close all instances in a @PreDestroy method, apparently I am not closing all of them.

What is the consequence of the following error:

11:20:47,866 ERROR [net.openhft.chronicle.hash.impl.ChronicleHashResources] (Reference Handler) ChronicleMap{name=null, file=null, identityHashCode=1146047764} is not closed manually, cleaned up from Cleaner

Does it harm to not manually close the maps?

Is a map first closed before it's cleaned up from the Cleaner?

Thanks

kem
  • 407
  • 1
  • 6
  • 20
  • 1
    please explain what do you mean by "apparently I am not closing all of them"? PreDestroy will be invoked by container before removal of the bean. Are you opening different Chronicle Map for each conversation? It seems that you should have application scoped service which will work with the map and inject that service into your conversation scoped beans. – Sergey Prokofiev Sep 05 '17 at 09:48
  • 1
    @SergeyProkofiev thanks. I like your suggestion of Application or Session scope. – kem Sep 05 '17 at 09:56
  • 1
    JavaEE app is based on another JavaSE app. Both use a lot ChronicleMap. I believe that @PreDestroy is doing the job for JavaEE app map instances. It's not the case for JavaSE app – kem Sep 05 '17 at 10:05
  • 1
    the general idea is that you should encapsulate all manipulations with the ChronicleMap in one place. And then, work with such service. It can be even EJB, which you can integrate with your applications. – Sergey Prokofiev Sep 05 '17 at 10:16
  • 1
    Is a map first closed before it's cleaned up from the Cleaner? – kem Sep 05 '17 at 10:19
  • 1
    You should call close then you're done with map manipulations, see [Close ChronicleMap](https://github.com/OpenHFT/Chronicle-Map#close-chroniclemap) – Sergey Prokofiev Sep 05 '17 at 10:22

1 Answers1

1

Not closing Chronicle Maps is not more harmful than e. g. not unmapping direct ByteBuffers manually. It may lead to OutOfMemoryError in some unfortunate scenarios, even though formally the live working set of objects + live off-heap memory never exceeds the configured limits.

leventov
  • 14,760
  • 11
  • 69
  • 98