Project:
View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
ID | ||||||||
0033141 | ||||||||
Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||
design defect | [Retail Modules] Web POS | major | have not tried | 2016-06-05 23:51 | 2016-06-24 10:07 | |||
Reporter | mtaal | View Status | public | |||||
Assigned To | mtaal | |||||||
Priority | normal | Resolution | fixed | Fixed in Version | ||||
Status | closed | Fix in branch | Fixed in SCM revision | fb2636899313 | ||||
Projection | none | ETA | none | Target Version | RR16Q3 | |||
OS | Any | Database | Any | Java version | ||||
OS Version | Database version | Ant version | ||||||
Product Version | SCM revision | |||||||
Merge Request Status | ||||||||
Review Assigned To | migueldejuana | |||||||
OBNetwork customer | No | |||||||
Support ticket | ||||||||
Regression level | ||||||||
Regression date | ||||||||
Regression introduced in release | ||||||||
Regression introduced by commit | ||||||||
Triggers an Emergency Pack | No | |||||||
Summary | 0033141: Change transaction mode to try server one by one and not broadcast the transaction | |||||||
Description | The current transaction mode broadcasts a message to all eligible servers. This can be okay and robust but gives rise to all kinds of race conditions when replicating transactions from one server to another. A more safe/better controllable approach seems to be to only send a transaction to the first eligible server. This also fits better to the concept of offline mode which corresponds to no server being available for a message. This is better than the current approach where we say that if one main server is not reachable that the user is in offline mode. | |||||||
Steps To Reproduce | Create an environment with 2 servers Create a ticket and check that it is broadcast to both servers at the same time | |||||||
Proposed Solution | Only send a message to the first online server which can receive it. If a server is not online then retry it several times and then retry a next available server. The message stays in the database until it can be send to at least one of the servers. | |||||||
Tags | No tags attached. | |||||||
Attached Files | ||||||||
![]() |
|
![]() |
|
(0087174) hgbot (developer) 2016-06-10 15:43 |
Repository: erp/pmods/org.openbravo.mobile.core Changeset: fb2636899313df3c617c64202fd9afbd8c54b896 Author: Martin Taal <martin.taal <at> openbravo.com> Date: Fri Jun 10 15:43:16 2016 +0200 URL: http://code.openbravo.com/erp/pmods/org.openbravo.mobile.core/rev/fb2636899313df3c617c64202fd9afbd8c54b896 [^] Fixes issue 33141: Change transaction mode to try server one by one and not broadcast the transaction Use fail over mode for transactional message, keep it in the database to retry, show offline always if there is at least one message to sync irrespective of server. --- M web/org.openbravo.mobile.core/source/component/dialog/ob-modalitemstosync.js M web/org.openbravo.mobile.core/source/component/dialog/ob-modalmodelstosync.js M web/org.openbravo.mobile.core/source/data/ob-requestrouter.js M web/org.openbravo.mobile.core/source/model/ob-message.js --- |
(0087881) migueldejuana (viewer) 2016-06-24 10:07 |
Tested and reviewed |
![]() |
|||
Date Modified | Username | Field | Change |
2016-06-05 23:51 | mtaal | New Issue | |
2016-06-05 23:51 | mtaal | Assigned To | => mtaal |
2016-06-05 23:51 | mtaal | OBNetwork customer | => No |
2016-06-05 23:51 | mtaal | Triggers an Emergency Pack | => No |
2016-06-10 15:43 | hgbot | Checkin | |
2016-06-10 15:43 | hgbot | Note Added: 0087174 | |
2016-06-10 15:43 | hgbot | Status | new => resolved |
2016-06-10 15:43 | hgbot | Resolution | open => fixed |
2016-06-10 15:43 | hgbot | Fixed in SCM revision | => http://code.openbravo.com/erp/pmods/org.openbravo.mobile.core/rev/fb2636899313df3c617c64202fd9afbd8c54b896 [^] |
2016-06-20 16:20 | mtaal | Review Assigned To | => migueldejuana |
2016-06-24 10:07 | migueldejuana | Note Added: 0087881 | |
2016-06-24 10:07 | migueldejuana | Status | resolved => closed |
Copyright © 2000 - 2009 MantisBT Group |