DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=40066>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=40066 ------- Additional Comments From [EMAIL PROTECTED] 2007-03-02 11:21 ------- (In reply to comment #2) >It does seem to be closely related enough and could be closed. >I do not agree however with the suggested change for 41735 and do believe that >my suggested change could still be an improvement. I'd only close this bug as duplicate of 41735 if the fix for 41735 fixed your problem. On first read, I was interpreting your problem as that you were losing logging data due to heavy load, not that there were gaps in the file names. I think the fix for 41735 may eliminate data loss where a rename or delete fails due to some side effect of a heavy load since it will stop subsequent renames and closing of the active log file. However, it could still result in a gap of file names above the locked file which should only be a minor cosmetic defect. If you see a defect in the fix for 47135 (svn diff -r513637:513638) where it does not address the issues raised in 47135 or introduces an undesirable side effect, please comment on the bug report for 41735 and reopen it if you think it is justified. If that patch doesn't fix the problem is this bug report, then we need to keep this bug open and figure out what is going on in your case. If an eventual patch for this bug ends up reverting part of the 47135 patch (while still keeping the behavior improvements), then that is fine. > Problem 1: you are deleting the last index when you start rolling over. If > lastindex is e.g. .10, and you have no .9, there is no reason to delete .10. > The test for deletion of the last file should be placed when you need this > name for putting the .9 file only. That is why I removed these lines and > added the test for the other renames. The bug 41735 patch tried to make the minimal changes necessary to eliminate the data loss problem. In particular, it tried to make the code path obviously identical to the existing code when the delete and renames succeeded. I'm extremely hesitant to make any substantial change to a successful code path without a clearly defined and substantial benefit. I don't think that filling in the gaps in a partial sequence is substantial enough. > Problem 2: for all renames, you are not testing if the target file exists, as > such a rename will fail when the file has e.g. read-only marks or is open in > a > non-exclusive mode. First deleting it avoid pending locks. e.g. virus > scanner might be scanning the file but without placing a lock The 41735 fix will only attempt to rename a file after having successfully renaming or deleting the target file if it had existed. Another process or thread could recreate the target file, but then the rename would fail and you'd defer the rollover and end up with foreign target file in the train and a larger than normal file corresponding to the active log file. > PS: The problem I reported is that the files are not being locked by the > system because no other process is accessing the files. It could be that > writing to the files occurs concurrently from different threads in the > application all using the same logging sub-system. There are inheritent suseptibilities in the current RFA's. The MultiFileAppender effort tried to address the same use cases without need to do file renames or preemptive closings. I'd like to get back to that and finish it off, but haven't had the time. I'm hesitant to making any changes to the existing RFA's where the problem isn't clearly identified and the code changes are low-risk. In this case, it isn't clear what the underlying problem is and the code modifications are not obviously low-risk. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
