Tom_Davidson
VIP Member
I have been working with JDE for several weeks to determine why WebSaw is failing on our JDE.LOG files on the ES. It has been determined that there is a limitation of approximately 9000 log files until an internal OS allocation limit is reached (16M). In our case I run about 73K UBE's per week, this means that if I keep the logs only 1 day, I am over this limit. Since logs are processed fairly early in the process, this effectivelly makes WebSaw unusable for us. Before I suggest a SAR for this problem I thought I would get the lists input as to possible solutions.
1) One idea is that when DEBUG=FALSE the log is not created at all, now it creates the debug log with a line that says debug is disabled. Advantages: Does not create useless logs, should improve job startup performance slightly. Disadvantage: Doesn't solve my problem, cuts the number of logs in half, but I still exceed the 9000 limit.
2) Re-architect how WebSaw works to place processing logs last. Advantages: I get access to most of WebSaw, before it fails. Disadvantages: I don't get access to the logs from WebSaw, and I suspect that any 'save' feature to process data later would have to take place after log processing.
3) Re-architect how WebSaw handles logs. I am suggesting that when they reach their limit, they just go on to the next part of WebSaw, don't terminate the entire process. Advantages: At least I can see 9000 logs, and WebSaw is then useable for me. Disadvantages: Sometimes incomplete info is worse than no info.
4) Re-architect how WebSaw handles logs to allow it to handle the 32K + logs that I have (I keep 2 days). Advantages: Solves my problem. Disadvantages: So generic that it will probably end up 'Returned-Redesign not planned'.
Any other ideas from you guys out there? Thanks in advance.
Tom Davidson
1) One idea is that when DEBUG=FALSE the log is not created at all, now it creates the debug log with a line that says debug is disabled. Advantages: Does not create useless logs, should improve job startup performance slightly. Disadvantage: Doesn't solve my problem, cuts the number of logs in half, but I still exceed the 9000 limit.
2) Re-architect how WebSaw works to place processing logs last. Advantages: I get access to most of WebSaw, before it fails. Disadvantages: I don't get access to the logs from WebSaw, and I suspect that any 'save' feature to process data later would have to take place after log processing.
3) Re-architect how WebSaw handles logs. I am suggesting that when they reach their limit, they just go on to the next part of WebSaw, don't terminate the entire process. Advantages: At least I can see 9000 logs, and WebSaw is then useable for me. Disadvantages: Sometimes incomplete info is worse than no info.
4) Re-architect how WebSaw handles logs to allow it to handle the 32K + logs that I have (I keep 2 days). Advantages: Solves my problem. Disadvantages: So generic that it will probably end up 'Returned-Redesign not planned'.
Any other ideas from you guys out there? Thanks in advance.
Tom Davidson
