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

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0033293
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Openbravo ERP] A. Platformminorhave not tried2016-06-16 16:412022-02-01 08:05
ReportershuehnerView Statuspublic 
Assigned ToTriage Platform Base 
PriorityhighResolutionopenFixed in Version
StatusacknowledgedFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned To
Web browser
ModulesCore
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0033293: LogCleanup Utility background job inside pi not working correctly in at least one case

DescriptionHas been observed in a customer installation having 15Q2.

The ad_pinstance + _para tables are not cleanup up by that process as they should be.

process monitor shows the process being executed but ends in status 'ERR' on every execution.

Log for those process execution always looks similar:
2016-06-08 19:00:00.049 - Starting log clean up process for Client:CLIENT_NAME - Organization:*+|
2016-06-08 19:00:00.118 - Cleaning up entity ADSessionUsageAudit +|
2016-06-08 19:00:01.546 - Deleted 0 rows +|
2016-06-08 19:00:01.546 - Entity ADSessionUsageAudit cleaned up in 1428ms +|
2016-06-08 19:00:01.551 - Cleaning up entity ADParameter +|
                                                                                No excpetion is logged in catalina.out or openbravo.log or process monitor output which makes it hard to debug.

Checking the configuration table for this process shows that all config entries are duplicated and one set of the entries is missing value for ad_column_id.

http://wiki.openbravo.com/wiki/Logs_Clean_Up [^]
That maybe related to the Red warning in this document but unclear.
Steps To ReproduceUnknown but from observed apparently wrong behavior in customer instance.
Access can be requested via SHU
Proposed SolutionCheck and improve error logging to make it possible to debug.
Review failure and avoid if possible.
If double config to be cleanup manually is cause of the problem check if it is not possible to make user more aware of the issue
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]
related to defect 0034667 closedalostale incorrect log in LogCleanUpProcess if vacuum fails 

-  Notes
There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
2016-06-16 16:41 shuehner New Issue
2016-06-16 16:41 shuehner Assigned To => platform
2016-06-16 16:41 shuehner Modules => Core
2016-06-16 16:41 shuehner Triggers an Emergency Pack => No
2016-12-01 12:43 alostale Status new => acknowledged
2016-12-01 14:03 alostale Priority normal => high
2016-12-01 15:37 alostale Relationship added related to 0034667
2022-02-01 08:05 alostale Assigned To platform => Triage Platform Base


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker