Project:
| View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
| ID | ||||||||
| 0035289 | ||||||||
| Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||
| defect | [Retail Modules] Web POS | major | always | 2017-02-16 18:39 | 2017-06-19 11:09 | |||
| Reporter | inigoqz | View Status | public | |||||
| Assigned To | mtaal | |||||||
| Priority | normal | Resolution | fixed | Fixed in Version | RR17Q3 | |||
| Status | closed | Fix in branch | Fixed in SCM revision | 0769bc9065a6 | ||||
| Projection | none | ETA | none | Target Version | ||||
| OS | Any | Database | PostgreSQL | Java version | ||||
| OS Version | Database version | 9.5 | Ant version | |||||
| Product Version | SCM revision | |||||||
| Merge Request Status | ||||||||
| Review Assigned To | marvintm | |||||||
| OBNetwork customer | No | |||||||
| Support ticket | ||||||||
| Regression level | ||||||||
| Regression date | ||||||||
| Regression introduced in release | ||||||||
| Regression introduced by commit | ||||||||
| Triggers an Emergency Pack | No | |||||||
| Summary | 0035289: BUT: Duplicate transaction in POS (already done) | |||||||
| Description | Env: 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 Reproduce | Create 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) | |||||||
| Tags | No tags attached. | |||||||
| Attached Files | ||||||||
 Relationships [ Relation Graph ]
[ Dependency Graph ]
|
||||||||
|
||||||||
 Relationships |
|
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 (viewer) 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"))) { |
|
Notes |
|
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:01 | mtaal | OBNetwork customer | => No |
| 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 |
|
Issue History |
| Copyright © 2000 - 2009 MantisBT Group |
 |