Errors and Warnings in Logfile

I have a Docker setup with latest 10.8.1 and getting a few errors and warnings that might be interesting.
What caught my eye was:

[Core extension repository updater] ERROR aultExtensionRepositoryManager - Unexpected error when trying to find extension [] in repository []

and a few warnings related to notifications.

Are these known issues?

xwiki.log (36.7 KB)

18-Oct-2018 20:01:06.400 WARNING [localhost-startStop-1] org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [187,032] milliseconds.
18-Oct-2018 20:01:07.468 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/usr/local/tomcat/webapps/ROOT] has finished in [229,442] ms

Wow this is long… it should normally take 15-20 seconds to deploy XWiki in Tomcat.

2018-10-18 20:11:58,718 [XWiki Scheduler initialization] WARN w.i.AutomaticWatchModeListener - Failed to watch document [xwiki:Scheduler.NotificationEmailHourlySender] for user [xwiki:XWiki.frieder]
org.xwiki.notifications.NotificationException: Error while loading the notification filter preferences of the user [xwiki:XWiki.frieder].
at org.xwiki.notifications.filters.internal.NotificationFilterPreferenceStore.getPreferencesOfUser(
at org.xwiki.notifications.filters.internal.DefaultModelBridge.getInternalFilterPreferences(
at org.xwiki.notifications.filters.internal.DefaultModelBridge.getFilterPreferences(
at org.xwiki.notifications.filters.internal.CachedModelBridge.getFilterPreferences(
at org.xwiki.notifications.filters.internal.UserProfileNotificationFilterPreferenceProvider.getFilterPreferences(
at org.xwiki.notifications.filters.internal.DefaultNotificationFilterManager.getFilterPreferences(
at org.xwiki.observation.internal.DefaultObservationManager.notify(
at org.xwiki.observation.internal.DefaultObservationManager.notify(
at com.xpn.xwiki.XWiki.saveDocument(
at com.xpn.xwiki.XWiki.saveDocument(
at com.xpn.xwiki.XWiki.saveDocument(
at com.xpn.xwiki.plugin.scheduler.SchedulerPlugin.saveStatus(
at com.xpn.xwiki.plugin.scheduler.SchedulerPlugin.scheduleJob(
at com.xpn.xwiki.plugin.scheduler.SchedulerPlugin.register(
at com.xpn.xwiki.plugin.scheduler.SchedulerPlugin.register(
at com.xpn.xwiki.plugin.scheduler.SchedulerPlugin.restoreExistingJobs(
at com.xpn.xwiki.plugin.scheduler.SchedulerPlugin.initAsync(
at com.xpn.xwiki.plugin.scheduler.SchedulerPlugin.access$000(
at com.xpn.xwiki.plugin.scheduler.SchedulerPlugin$
Caused by: org.xwiki.query.QueryException: Exception while executing query. Query statement = [select nfp from DefaultNotificationFilterPreference nfp where nfp.owner = :owner order by]
at org.xwiki.query.internal.DefaultQueryExecutorManager.execute(
at org.xwiki.query.internal.DefaultQuery.execute(
at org.xwiki.notifications.filters.internal.NotificationFilterPreferenceStore.getPreferencesOfUser(
… 26 common frames omitted
Caused by: com.xpn.xwiki.XWikiException: Error number 0 in 3: Exception while hibernate execute
… 29 common frames omitted
Caused by: org.hibernate.hql.ast.QuerySyntaxException: DefaultNotificationFilterPreference is not mapped [select nfp from DefaultNotificationFilterPreference nfp where nfp.owner = :owner order by]
at org.hibernate.hql.ast.util.SessionFactoryHelper.requireClassPersister(
at org.hibernate.hql.ast.tree.FromElementFactory.addFromElement(
at org.hibernate.hql.ast.tree.FromClause.addFromElement(
at org.hibernate.hql.ast.HqlSqlWalker.createFromElement(
at org.hibernate.hql.antlr.HqlSqlBaseWalker.fromElement(
at org.hibernate.hql.antlr.HqlSqlBaseWalker.fromElementList(
at org.hibernate.hql.antlr.HqlSqlBaseWalker.fromClause(
at org.hibernate.hql.antlr.HqlSqlBaseWalker.query(
at org.hibernate.hql.antlr.HqlSqlBaseWalker.selectStatement(
at org.hibernate.hql.antlr.HqlSqlBaseWalker.statement(
at org.hibernate.hql.ast.QueryTranslatorImpl.analyze(
at org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(
at org.hibernate.hql.ast.QueryTranslatorImpl.compile(
at org.hibernate.engine.query.HQLQueryPlan.(
at org.hibernate.engine.query.HQLQueryPlan.(
at org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan(
at org.hibernate.impl.AbstractSessionImpl.getHQLQueryPlan(
at org.hibernate.impl.AbstractSessionImpl.createQuery(
at org.hibernate.impl.SessionImpl.createQuery(
… 31 common frames omitted

This is because you’re using an old 10.8.1 image I think. Can you try to “docker pull” the image? See

Good to know. I was already wondering if this is not a bit long. I didn’t do much so far. Basically only including the docker image in my setup and starting it.

2018-10-18 19:58:00,542 [Core extension repository updater] ERROR aultExtensionRepositoryManager - Unexpected error when trying to find extension [] in repository []
org.xwiki.extension.ResolveException: Failed to create extension object for extension []
at org.xwiki.extension.repository.xwiki.internal.XWikiExtensionRepository.resolve(
at org.xwiki.extension.repository.internal.DefaultExtensionRepositoryManager.resolve(
at org.xwiki.extension.repository.internal.core.DefaultCoreExtensionScanner.updateExtensions(
at org.xwiki.extension.repository.internal.core.DefaultCoreExtensionRepository$
Caused by: Invalid answer [500] from the server when requesting []
at org.xwiki.extension.repository.xwiki.internal.XWikiExtensionRepository.getRESTResource(
at org.xwiki.extension.repository.xwiki.internal.XWikiExtensionRepository.getRESTObject(
at org.xwiki.extension.repository.xwiki.internal.XWikiExtensionRepository.resolve(
at org.xwiki.extension.repository.xwiki.internal.XWikiExtensionRepository.resolve(
… 4 common frames omitted

I’ll let @tmortagne or @mflorea reply to this one. There might be a problem with

I don’t think so. I pulled the latest image with tag 10.8.1-mysql-tomcat and the warnings remain.

Hmm I think I know. See

(Check the part in yellow).

Could you check the table name you have: notification_filter_preferences or notification_filter_prefs?

I don’t think I ever used 10.8RC1 at least not that I know.
I don’t have any table like notification_filter_preferences.

mysql> show tables;
| Tables_in_xwiki               |
| activitystream_events         |
| activitystream_events_status  |
| activitystream_events_targets |
| feeds_aggregatorgroup         |
| feeds_aggregatorurl           |
| feeds_aggregatorurlgroups     |
| feeds_feedentry               |
| feeds_feedentrytags           |
| feeds_keyword                 |
| mailsender_events             |
| xwikiattachment               |
| xwikiattachment_archive       |
| xwikiattachment_content       |
| xwikiattrecyclebin            |
| xwikicomments                 |
| xwikidates                    |
| xwikidbversion                |
| xwikidoc                      |
| xwikidoubles                  |
| xwikifloats                   |
| xwikiid                       |
| xwikiintegers                 |
| xwikilargestrings             |
| xwikilinks                    |
| xwikilistitems                |
| xwikilists                    |
| xwikilock                     |
| xwikilongs                    |
| xwikiobjects                  |
| xwikipreferences              |
| xwikiproperties               |
| xwikircs                      |
| xwikirecyclebin               |
| xwikispace                    |
| xwikistatsdoc                 |
| xwikistatsreferer             |
| xwikistatsvisit               |
| xwikistrings                  |
38 rows in set (0.00 sec)

hmm that’s a problem, you should have a notification_filter_prefs table as otherwise the notification feature won’t work.

@gdelhumeau Any idea what could be wrong? (Guillaume is the author of this feature)

If it’s an installation on Linux it may be caused by an empty entropy pool (/dev/random).

If all works well, Xwiki needs between 60 and 75 seconds to start, but it easily takes up to several minutes if it’s restarted too often or immediately after server bootup.

It’s somewhat annoying, but probably a known tradeoff between security and usability.

According to my observations, forcing disk activity on the server helps a bit in this case and can accelerate the start time from 3-4 to about 2 minutes.

Actually I did three more restarts and the startup time went down from the 230 seconds seen above, first to 100 seconds and then to 42 seconds. I think I recreated the docker container before the first start, so that might have had some influence.

Starts under 20 seconds for me.

BTW we tried to speed this up by setting this at startup: -Dsecurerandom.source=file:/dev/urandom. Works fine on most machines and I don’t know why it has no effect on yours.

It’s also machine dependent, but for me it takes at least about 50 or 55 seconds as far as I observed. (It’s a virtual machine running on a slightly older Xeon server.)

The thing about -Dsecurerandom.source=file:/dev/urandom is interesting, I’ll have to look into this - it shouldn’t block in this case, but definitely does. In this case the log suspends after starting solr and it takes ages until the startup process continues.