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

View Issue Details[ Jump to Notes ] [ Issue History ] [ Print ]
ID
0042034
TypeCategorySeverityReproducibilityDate SubmittedLast Update
design defect[Retail Modules] Web POSminorhave not tried2019-10-15 18:452022-08-19 15:03
ReporterALopeteguiView Statuspublic 
Assigned Torqueralta 
PrioritynormalResolutionopenFixed in Version
StatusscheduledFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned To
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0042034: External Orderloader import_entry processed in asynchronous mode stays in 'Initial' status for ever

DescriptionIn one client we had an import_entry in status Initial all the time, because somehow the external orderloader was sent in asynchronous mode and the run() function in this mode is empty, for that reason even if the import_entry_manager, wants to process the import_entry, it doesn't do anything and the import entry continues in status 'Initial' for ever. Besides, there is always one thread occupied trying to process that entry, but it can't finish.
How that external orderleader was sent in different way is unclear, because all external orderloader before and after that entry was processed normally in synchronous mode. To workaround this problem in the client we change manually the importstatus='Error'.
Steps To ReproduceSend a external order loader in asynchronous mode. You will see that the import_entry is not processed never.
TagsNo tags attached.
Attached Files

- Relationships [ Relation Graph ] [ Dependency Graph ]

-  Notes
(0118666)
marvintm (manager)
2020-03-18 09:50

 After further discussion, we consider this a design defect.

Currently the ExternalOrderLoader creates the import entry in initial status and then commits the transaction, and after that continues with the process. If the process ends correctly, it then changes the import entry to Success status, and otherwise it changes it to Error.

The import entries were left in Initial status in this case because the customer environment was suffering a problem, and the database ran out of available connections at some point. This meant that the import entries had been created, the process then failed, and as there were no available connections, it could not change them to Error status.

Therefore, the problem could be avoided simply by removing the commit that creates the import entry, so that if the same problem happens the import entries would not be created, or would be left in error.

However, the commit is there for a reason: it was added to prevent cases of duplicated requests adding unnecessary work to the server, and even more, to prevent very ugly cases of integrations with external systems being executed twice.

Therefore, we currently believe that the potential risk of doing this change doesn't offset the small benefit of avoiding this quite harmless problem that so far has happened only twice, and that has the very simple solution of just removing the generated import entries manually.

- Issue History
Date Modified Username Field Change
2019-10-15 18:45 ALopetegui New Issue
2019-10-15 18:45 ALopetegui Assigned To => Retail
2019-10-15 18:45 ALopetegui Triggers an Emergency Pack => No
2020-02-25 16:33 kchoperena Resolution time => 1583794800
2020-02-27 23:47 rqueralta Assigned To Retail => rqueralta
2020-02-27 23:47 rqueralta Status new => scheduled
2020-03-11 12:58 ALopetegui Severity major => minor
2020-03-11 12:58 ALopetegui Type defect => design defect
2020-03-18 09:50 marvintm Resolution time 1583794800 =>
2020-03-18 09:50 marvintm Note Added: 0118666
2022-08-19 15:03 ivancaceres Issue Monitored: ivancaceres

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker