Open Source Document Management System | OpenKM

I'm using OpenKM 5.1.11 on Windows with MySQL DB and ldap users configuration.

Today, I got a very weird error.I closed OpenKM and when I tried to login again, I got a red window exception saying this:
Repository Internal Error, your session has already been closed.I closed the browser and tried again, but the same error occured. At the same time, this error occured at other users trying to login too. The problem was only solved when I restarted the server.
Does this have to do with the session.keep.alive feature?I had this property at 25 min and now I reduced it at 15min.What is the ideal value for this?

And something more, I tried force logout some users but I cannot locate the logout user icon on the "Logged Users" page!!!Why is that?Is it because of the ldap configuration?

p.s. I'm sorry I don't have the error stack trace. I couldn't find it in the error log after the restart

Thank you

OpenKM 5.1 is obsolete. I recommend to upgrade to a more recent version like 6.2.3

With change of session.keep.alive will not avoid Repository Internal Error. That is an ugly error I suggest you be sure you got a backup of your application. And as suggest pavila is good idea - when be possible to you - upgrade to latest 6.2.X because if some day you got hard disk broken ( lost sectors etc... ) and backup is not totally correct ( it should ) from 5.x version and olders is more difficult recover broken repository than 6.x

My repository generally works fine. I think that this error was caused due to a very long Full GC that caused database connections time out. I guess I will have to tweak java heap ratio...

The most important think is the backup. Ensure is right that's the best security policy you got.

I shutdown and backup the whole server folder + db every night

I am still trying to figure out what caused this problem and I am digging through my code to find faults. I think that I found a possible leak...
I have created an extension toolbar button and a frontend servlet that extends OKMRemoteServiceServlet and implements some services that are called from that button. Inside the frontend servlet I use commands like: or but I haven't created a finally block with command. Should I use JCRUtils.logout(session) or session.logout() after I have called system session?Could this have caused the "Repository Internal Error - This session has been closed" error? Generally speaking, is it a bad technique to use system session inside a frontend servlet?
And something last:
I have noticed that in your package com.openkm.module.direct, when you do some operations with JCRSession you always have a finally block of this kind: But what if token!=null? If I use OKMDocument.getInstance().copy(JcrSessionManager.getInstance().getSystemToken(), String docPath, String dstPath), then token!=null and thus the finally block won't work.

p.s. I am talking about version 5.1.11.
p.s.2 Sorry If my questions are stupid but I have been working with java just a year and a half and your open source project is like a paradise of discovering and learning java.

If you make a JCRUtils.logout of the System Session, will cause problems in OpenKM.

As said previously, forget OpenKM 5.1 and upgrade to 6.2.

Anyway, I managed to isolate the problem. I got a java.util.ConcurrentModificationException from jackrabbit when two different threads tried to make actions on the same node using system session.The first one tried to copy the node and the second one tried to change permissions.Thus, jcr forced system session to close and repository hang...
I'll avoid using system session as far as possible, maybe synchronize some blocks and then start migrating in version 6 where I think you have changed repository. Hope it won't take me forever to adapt my code to newer version...

Good luck

Source code change from 5.x to 6.x has been done to take full control ( in 5.x was not possible take control of some parts, because was not accessible directly from jackrabbit api and needed major changes on it ). The changes we have done has come to stay, we do not think in major architecture changes, althought we're working on several areas like clustering and record management etc... the actual main core implementation seems will not need the radical change we have done from 5.x to 6.x