Bug #2682

Editor results computing executed with not computed parents branch or too long process may lead to display wrong data in editor

Added by Sebastien Jacquot 6 months ago. Updated 4 months ago.

Status:Feedback Start date:11/29/2019
Priority:Urgent Due date:
Assignee:- % Done:

80%

Category:Persistence / Lazy Spent time: -
Target version:TXM 0.8.1

Description

WIP SJ:

There are most cases where an editor may seems ready to be used but actually doesn't.
Behavior may be problematic according to the duration of the parents branch computing or duration of the result computing itself.

  • a) reopening a persisted result when its parent branch is not ready
  • b) computing a complex result

In both of these cases, if the duration is too long, the editor widget should be disabled or not opened before the computing has ended.
Otherwise, user can change parameters and run a compute leading to wrong result or simply some crashes due of various reasons.

Example of bug 1

There is a bug in 0.8.0 where the index of partition found nothing if the parent partition parts are not computed yet, typically when reopening TXM.
More information: the problem here is important. When creating an index of partition, the editor opens and the parent and children of parent are computed in background. But since the editor is ready, if we type eg. "faire" before the parts are computed, nothing is found in the index.

Steps to reproduce

=> have a Partition based on a complex query, eg. ELTECFRAORIG_sp_n
=> launch TXM execute Index with "faire" query
=> the editor and console return no results

Solutions to restrict and/or avoid the behavior of case a)

  • ensure the computing of parents branch is done before displaying the editor

SJ: solution has been implemented by running a modal cancelable dialog to block the UI until the needed parents branch is computed.
The editor is not displayed until the process has ended.
NOTE: later, it would be nice to manage a blocking state only for the concerned branch, so the user can still use TXM on other corpora or branches
New issue for this improvement and validation tests: #2746.

Solutions to restrict and/or avoid the behavior of case b)

  • 1) permit only one compute at a time in TXMEditor.Compute() by storing the current computing Job and returns if it's already running
    => will avoid the possibility to get some wrong results when the Partition is not yet computed (eg. typing "faire" in an Index does not return empty result anymore, atm this message is displayed in the console: "Editor is already computing .... Please wait or abort the computing job (Calcul de Index de partition: ELTECFRAORIG_sp_n: ...…).")
    => It doesn't avoid to open another Index
    SJ: this solution 1 has been implemented. Need to translate the log.

* 2) on computing, find a way to disable the editor widgets (or computing button) so the user can not start parallel computing
New issue for about this point here: #2747.

Validation tests

  • create and compute a complex result
  • while computing, change some parameters and click on compute button
    => it should display a console alert
    => when the first compute has ended, the parameter widget values must match the parameters used by the first compute

Related issues

related to Bug #2742: RCP: 0.8.0, TXMEditor parameter toolbar is broken when CQ... Feedback 01/24/2020

Associated revisions

Revision 2558
Added by Sebastien Jacquot 4 months ago

Fixes: Deleting a result node doesn't close its result children editors (refs #2679)
Progresses on: TXMEditor parameter toolbar is broken when CQP corpus is not ready (refs #2742)
Progresses on: Commands executed on not loaded Partition may lead to wrong results (refs #2682)

Revision 2559
Added by Sebastien Jacquot 4 months ago

Progresses on: TXMEditor parameter toolbar is broken when CQP corpus is not ready (refs #2742)
Progresses on: Commands executed on not loaded Partition may lead to wrong results (refs #2682)

Revision 2565
Added by Sebastien Jacquot 4 months ago

Progresses on: TXMEditor parameter toolbar is broken when CQP corpus is not ready (refs #2742)
Progresses on: Commands executed on not loaded Partition may lead to wrong results (refs #2682)

Revision 2566
Added by Sebastien Jacquot 4 months ago

Progresses on: TXMEditor parameter toolbar is broken when CQP corpus is not ready (refs #2742)
Progresses on: Commands executed on not loaded Partition may lead to wrong results (refs #2682)

Revision 2567
Added by Sebastien Jacquot 4 months ago

Fixes: Dialog boxes of Sub-corpus and Partition creation are broken when CQP corpus is not ready (refs #2745)
Progresses on: Editor results computing executed with not computed parents branch or too long process may lead to display wrong data in editor (refs #2682)

Revision 2579
Added by Sebastien Jacquot 4 months ago

Progresses on: TXMEditor parameter toolbar is broken when CQP corpus is not ready (refs #2742)
Progresses on: Commands executed on not loaded Partition may lead to wrong results (refs #2682)

Revision 2648
Added by Sebastien Jacquot 3 months ago

Fixes: Editor results computing executed with not computed parents branch or too long process may lead to display wrong data in editor (refs #2682)

History

#1 Updated by Sebastien Jacquot 6 months ago

  • Subject changed from Commands executed on not loaded Partition may lead to wrong results to Commands executed on not loaded Partition may lead to wrong results or TXM crash
  • Description updated (diff)

#2 Updated by Sebastien Jacquot 6 months ago

  • Description updated (diff)

#3 Updated by Sebastien Jacquot 6 months ago

  • Description updated (diff)

#4 Updated by Sebastien Jacquot 6 months ago

  • Description updated (diff)

#5 Updated by Sebastien Jacquot 6 months ago

  • Description updated (diff)

#6 Updated by Sebastien Jacquot 6 months ago

Need to do a new issue about the cqpjni multi-thread access and maybe about the transfer of C++ errors to Java exceptions.
Using synchronized in MemCqiClient may help to reduce crash due to multi-thread access:

    @Override
    public synchronized void cqpQuery(String arg0, String arg1, String arg2)
            throws IOException, UnexpectedAnswerException, CqiServerError {
        if (arg0 == null || arg1 == null || arg2 == null) {
            throw new CqiServerError("cqpQuery called with NULL parameter.");
        }
        Boolean ret = server.cqpQuery(arg0, arg1, arg2);
        // System.out.println("CQPSERVER return: "+ret);
        if (ret == null || !ret) {
            int e = server.getErrorCode();
            // System.out.println("throw exception with cqp error code: "+e);
            throwExceptionFromCqi(e);
        }
    }

#7 Updated by Sebastien Jacquot 5 months ago

  • Description updated (diff)

#8 Updated by Sebastien Jacquot 5 months ago

  • Description updated (diff)

#9 Updated by Sebastien Jacquot 5 months ago

  • Subject changed from Commands executed on not loaded Partition may lead to wrong results or TXM crash to Commands executed on not loaded Partition may lead to wrong results
  • Description updated (diff)

#10 Updated by Sebastien Jacquot 5 months ago

New issue about the native crash: http://forge.cbp.ens-lyon.fr/redmine/issues/2697.

#11 Updated by Sebastien Jacquot 4 months ago

  • Description updated (diff)
  • Target version changed from TXM 0.8.2 to TXM 0.8.1
  • % Done changed from 0 to 10

#12 Updated by Sebastien Jacquot 4 months ago

  • Subject changed from Commands executed on not loaded Partition may lead to wrong results to Editor results computing executed with not computed parents branch or too long process may lead to display wrong data in editor
  • Description updated (diff)

#13 Updated by Sebastien Jacquot 4 months ago

  • Description updated (diff)

#14 Updated by Sebastien Jacquot 4 months ago

  • Description updated (diff)

#15 Updated by Sebastien Jacquot 4 months ago

  • Description updated (diff)
  • % Done changed from 10 to 50

#16 Updated by Sebastien Jacquot 4 months ago

  • Description updated (diff)

#17 Updated by Sebastien Jacquot 4 months ago

  • Description updated (diff)
  • Status changed from New to Feedback
  • % Done changed from 50 to 80

#18 Updated by Sebastien Jacquot 4 months ago

  • Category changed from Development to Persistence / Lazy

Also available in: Atom PDF