Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0035289
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Retail Modules] Web POSmajoralways2017-02-16 18:392017-06-19 11:09
ReporterinigoqzView Statuspublic 
Assigned Tomtaal 
PrioritynormalResolutionfixedFixed in VersionRR17Q3
StatusclosedFix in branchFixed in SCM revision0769bc9065a6
ProjectionnoneETAnoneTarget Version
OSAnyDatabasePostgreSQLJava version
OS VersionDatabase version9.5Ant version
Product VersionSCM revision 
Review Assigned Tomarvintm
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0035289: 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)
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]
related to design defect 0036196RR17Q3 closedmtaal Prevent same ticket from being send twice by the user from being processed 

-  Notes
(0095923)
hgbot (developer)
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 (manager)
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"))) {

- Issue History
Date Modified Username Field Change
2017-02-16 18:39 inigoqz New Issue
2017-02-16 18:39 inigoqz Assigned To => Retail
2017-02-16 18:39 inigoqz Triggers an Emergency Pack => No
2017-03-29 14:04 mtaal Assigned To Retail => mtaal
2017-04-10 06:01 mtaal Review Assigned To => marvintm
2017-04-10 06:08 hgbot Checkin
2017-04-10 06:08 hgbot Note Added: 0095923
2017-04-10 06:08 hgbot Status new => resolved
2017-04-10 06:08 hgbot Resolution open => fixed
2017-04-10 06:08 hgbot Fixed in SCM revision => http://code.openbravo.com/erp/pmods/org.openbravo.mobile.core/rev/0769bc9065a6f0825bc776b8a94915f59775b34c [^]
2017-04-10 06:11 mtaal Note Added: 0095924
2017-05-09 08:42 marvintm Status resolved => closed
2017-05-09 08:42 marvintm Fixed in Version => RR17Q3
2017-06-19 11:09 mtaal Relationship added related to 0036196


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker