Entity not removed from FTS indexing queue once (soft) deleted?

Support
#1

Hi

We have a service that setup standard tenant administration roles, groups and account. While doing this, it removes UserRole, and recreates Roles.

Looking at the log below, it seems that when removing and entity, it is not removed from the sys_fts_queue ?

11:28:58.465 INFO c.b.a.s.BusyTenantManagerServiceBean - creating local admin role
11:28:58.680 INFO c.b.a.s.BusyTenantManagerServiceBean - creating default ‘localadmin’ account, please change its password
11:29:01.451 ERROR c.h.fts.core.sys.LuceneIndexer - Entity instance not found: sec$Role-2eff9789-d388-bcba-dd7d-7baf77dbbb9c
11:29:01.451 ERROR c.h.fts.core.sys.LuceneIndexer - Entity instance not found: sec$Role-c95263f7-522c-c37a-0088-e7d580074eaa
11:29:01.451 ERROR c.h.fts.core.sys.LuceneIndexer - Entity instance not found: sec$Role-119f5b12-efc5-38cc-b3f5-f62563d1bb64
11:29:01.451 ERROR c.h.fts.core.sys.LuceneIndexer - Entity instance not found: sec$Role-8fb8453b-aa92-d254-6177-b77656f33d94
11:29:01.451 ERROR c.h.fts.core.sys.LuceneIndexer - Entity instance not found: sec$Role-69ecd423-843d-7249-f8cc-e8eca29598f2
11:29:01.461 ERROR c.h.fts.core.sys.LuceneIndexer - Entity instance not found: busy$ExtUser-c161ffc0-e39f-f824-c975-45dab722e972

#2

Hi Mike,

Yes, it is not removed from the queue. Does it cause any problems?

#3

Nothing dramatic, but removing an entity should not disturb indexing to the point it raises an error. While rare, this is a normal operation.

1 Like
#4

I generally agree, but in reality it means that instead of one database delete statement we will issue two each time we delete an instance. And in 99% of cases the second statement will be a waste. So I think we should rather leave it as it is, maybe just log a warning instead of error.

#5

Or maybe just simply ignore the case : when an entity is referenced in sys_fts_queue but not in database anymore, the only possible reason is a delete, which is not an abnormal state. Then, indexing does not make sense anymore, and could simply pass over. Like ignoring an exception on a stream.close() in a finally.

If one is skittish about not reporting the case, I agree, a warning would be enough. This way applications that do lots of delete can set the log level to error in order to avoid log cluttering. Currently, only OFF is possible which is not wishable.

#6

Is it possible to plan at some point to have this issue reported as a warning instead of error ? We keep having long list of messages while testing and switching the log to OFF is not really a solution.

#7

Yes, it is changed to INFO in release 6.9.