I setup jobs :
Job “A” to crawls “Windows Shares”
Job “B” to crawl my internal site

The problem was when I tried to aborted the second job “B”
It hang in aborting state

After, I tried to start job “A” but it hanged in “Starting” state, and not start, after, I tried to abort it too and it hanged in Aborting state as of “B” job.

I increased log level of logging.xml to “info” but when I start manifoldcf as standalone I do not have many info on the logs/manifoldcf.log

I read:
INFO 2018-06-12T15:58:02,748 (main) - dataFileCache open start
INFO 2018-06-12T15:58:02,753 (main) - dataFileCache open end

And nothing more

So, I think that there could be a lock situation in the internal HSQLDB that I am not able to solve.
Da: Karl Wright <[EMAIL PROTECTED]>
Inviato: martedì 12 giugno 2018 15:46
A: [EMAIL PROTECTED]
Oggetto: Re: Job in aborting status

Hi Mario,

If you are using the single-process model, then stuck locks are not the problem and the lock-clean script is inappropriate to use.  Locks are all internal in that model.  That is why lock-clean is only distributed as part of the file-based multiprocess example.

Please tell me more about what you have set up for your jobs on this example.  How many are there, and how many documents are involved?  The embedded HSQLDB database has limits because it caches all tables in memory, so the single-process example is not going to be able to handle huge jobs.

Please have a look at the log to be sure there are no serious errors in it.

Thanks,
Karl
On Tue, Jun 12, 2018 at 9:26 AM Bisonti Mario <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>> wrote:
No, I am testing on the /example directory so I am using local HSQLDB
I copied lock-clean.sh script from the /usr/share/manifoldcf/multiprocess-file-example to the /usr/share/manifoldcf/example to try to clean-up my situation, but perhaps the script isn’t good for me because I am using jetty on the example directory?

Thanks
Da: Karl Wright <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>>
Inviato: martedì 12 giugno 2018 15:23
A: [EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>
Oggetto: Re: Job in aborting status

Hi Mario,

It appears you are trying to use embedded HSQLDB in a multiprocess environment.  That is not possible.

In a multiprocess environment, you have the following choices:

(1) standalone HSQLDB
(2) postgresql
(3) mysql

Thanks,
Karl
On Tue, Jun 12, 2018 at 9:06 AM Bisonti Mario <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>> wrote:
Thanks Karl.
I tried to execute lock-clean from my example directory after I stop manifoldcf but I obtain:
administrator@sslrvivv01:/usr/share/manifoldcf/example$ sudo -E ./lock-clean.sh
Configuration file successfully read
Synchronization storage cleaned up
2018-06-12 15:03:35,395 Shutdown thread FATAL Unable to register shutdown hook because JVM is shutting down. java.lang.IllegalStateException: Cannot add new shutdown hook as this is not started. Current state: STOPPED
        at org.apache.logging.log4j.core.util.DefaultShutdownCallbackRegistry.addShutdownCallback(DefaultShutdownCallbackRegistry.java:113)
        at org.apache.logging.log4j.core.impl.Log4jContextFactory.addShutdownCallback(Log4jContextFactory.java:271)
        at org.apache.logging.log4j.core.LoggerContext.setUpShutdownHook(LoggerContext.java:256)
        at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:216)
        at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:146)
        at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:41)
        at org.apache.logging.log4j.LogManager.getContext(LogManager.java:270)
        at org.apache.log4j.Logger$PrivateManager.getContext(Logger.java:59)
        at org.apache.log4j.Logger.getLogger(Logger.java:37)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.hsqldb.lib.FrameworkLogger.<init>(Unknown Source)
        at org.hsqldb.lib.FrameworkLogger.getLog(Unknown Source)
        at org.hsqldb.lib.FrameworkLogger.getLog(Unknown Source)
        at org.hsqldb.persist.Logger.getEventLogger(Unknown Source)
        at org.hsqldb.persist.Logger.logInfoEvent(Unknown Source)
        at org.hsqldb.persist.DataFileCache.logInfoEvent(Unknown Source)
        at org.hsqldb.persist.DataFileCache.open(Unknown Source)
        at org.hsqldb.persist.Log.getCache(Unknown Source)
        at org.hsqldb.persist.Logger.getCache(Unknown Source)
        at org.hsqldb.persist.Logger.newStore(Unknown Source)
        at org.hsqldb.persist.PersistentStoreCollectionDatabase.getStore(Unknown Source)
        at org.hsqldb.Table.getRowStore(Unknown Source)
        at org.hsqldb.TableBase.isEmpty(Unknown Source)
        at org.hsqldb.TableWorks.addIndex(Unknown Source)
        at org.hsqldb.StatementSchema.getResult(Unknown Source)
        at org.hsqldb.StatementSchema.execute(Unknown Source)
        at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
       at org.hsqldb.scriptio.ScriptReaderText.readDDL(Unknown Source)
        at org.hsqldb.scriptio.ScriptReaderBase.readAll(Unknown Source)
        at org.hsqldb.persist.Log.processScript(Unknown Source)
        at org.hsqldb.persist.Log.open(Unknown Source)
        at org.hsqldb.persist.Logger.open(Unknown Source)
        at org.hsqldb.Database.reopen(Unknown Source)
        at org.hsqldb.Database.open(Unknown Source)
        at org.hsqldb.DatabaseManager.getDatabase(Unknown Source)
        at org.hsqldb.DatabaseManager.newSession(Unknown Source)
        at org.hsqldb.jdbc.JDBCConnection.<init>(Unknown Source)
        at org.hsqldb.jdbc.JDBCDriver.getConnection(Unknown Source)
        a