Openbravo Issue Tracking System - Retail Modules
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0035289Retail ModulesWeb POSpublic2017-02-16 18:392017-06-19 11:09
Reporterinigoqz 
Assigned Tomtaal 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOS5OS Version
Product Version 
Target VersionFixed in VersionRR17Q3 
Merge Request Status
Review Assigned Tomarvintm
OBNetwork customer
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0035289: BUT: Duplicate transaction in POS (already done)
DescriptionEnv: SS + Tomcat cluster + BUT synchonize mode environment.

SS has a functionality to retry ticket creation in case it does not receive an OK.

In a cluster environment, if we kill CS Apache + Tomcat in the node processing the ticket, SS will retry in another CS apach+Tomcat node.

When SS retries to write the ticket, the previous transaction may have reached the DB and commit or not. If it has not been committed in DB, there is not problem at all, because SS retries until it gets and OK.

But if previous transaction has been commited in DB and SS did not receive the OK message, the second time the record is already in database and USER in POS gets an " Duplicate transaction in POS (already done) " message
Steps To ReproduceCreate first ticket in SS1 POS, will be directed in T1 trough LB (see /var/log/haproxy.log).

Create 2nd ticket in in the same SS1, it will continue using T1 trough LB, but before pushing "Done" in the POS (start apache in T2) and after pushing "Done", stop apache T1 while processing ticket (remember we have set a sleep time).

In LB see /var/log/haproxy.log, see the error and how the request “SynchronizedServerProcessCaller” is directed into T2.

At POS user level the error could be:
Completely transparent to the user
If we stop t1 just a little bit later and the transaction is already in DB, we can receive a duplicate transaction in POS (already done)
Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
related to design defect 0036196RR17Q3 closed mtaal Prevent same ticket from being send twice by the user from being processed 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2017-02-16 18:39inigoqzNew Issue
2017-02-16 18:39inigoqzAssigned To => Retail
2017-02-16 18:39inigoqzTriggers an Emergency Pack => No
2017-03-29 14:04mtaalAssigned ToRetail => mtaal
2017-04-10 06:01mtaalReview Assigned To => marvintm
2017-04-10 06:08hgbotCheckin
2017-04-10 06:08hgbotNote Added: 0095923
2017-04-10 06:08hgbotStatusnew => resolved
2017-04-10 06:08hgbotResolutionopen => fixed
2017-04-10 06:08hgbotFixed in SCM revision => http://code.openbravo.com/erp/pmods/org.openbravo.mobile.core/rev/0769bc9065a6f0825bc776b8a94915f59775b34c [^]
2017-04-10 06:11mtaalNote Added: 0095924
2017-05-09 08:42marvintmStatusresolved => closed
2017-05-09 08:42marvintmFixed in Version => RR17Q3
2017-06-19 11:09mtaalRelationship addedrelated to 0036196

Notes
(0095923)
hgbot   
2017-04-10 06:08   
Repository: erp/pmods/org.openbravo.mobile.core
Changeset: 0769bc9065a6f0825bc776b8a94915f59775b34c
Author: Martin Taal <martin.taal <at> openbravo.com>
Date: Mon Apr 10 06:08:35 2017 +0200
URL: http://code.openbravo.com/erp/pmods/org.openbravo.mobile.core/rev/0769bc9065a6f0825bc776b8a94915f59775b34c [^]

Fixes issue 35289: BUT: Duplicate transaction in POS (already done)
The WebPOS client will automatically retry transaction requests to the server. Each retry uses the same json which has the same message id. On the server store the message in an archived import entry to detect that the message was already processed and can be ignored in subsequent requests which are done because of retrying.

Note that there are more special cases that the response gets lost completely at the last retry. If in this case the user will press the done button again and sends the ticket to the server then the optimistic locking checks in the OrderLoader (and the same for customerloader) will prevent saving a record again if it was already updated.

This commit also incorporates some other changes:
- repairs some duplicate code, see the handleCentralServerRequestException method
- changes the way a check is done if an importentry was already created using 'select 1' instead of 'select count(*)'

---
M src/org/openbravo/mobile/core/servercontroller/MultiServerJSONProcess.java
---
(0095924)
mtaal   
2017-04-10 06:11   
Note: to retest this issue it is not needed to have a clustered environment. You can also reproduce it by putting a breakpoint after the call to:

createArchiveEntry(jsonSent.getString("messageId"), jsonSent);

and then see that the MultiServerJSONProcess is retried and called again by also putting a breakpoint near:

if (getImportEntryId() == null && doesImportEntryExist(jsonSent.getString("messageId"))) {