logging-log4php-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Habunek (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4PHP-138) Permission denied while renaming log file when hundred of users are accessing the application
Date Fri, 10 Jun 2011 09:12:58 GMT

    [ https://issues.apache.org/jira/browse/LOG4PHP-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13047091#comment-13047091
] 

Ivan Habunek commented on LOG4PHP-138:
--------------------------------------

I think I understand why this error happens. Let me explain.

Assuming a rollover is needed, the current rolling file appender does the following:
1. Lock the file
2. Write to file
3. Check file size (decide a rollover is needed)
4. Close the file (this unlocks the file)
5. Rename the file to file_1
6. Create a new file
7. Resume logging

Now, the problem with concurrent apps is that another process may be waiting to get a file
lock. When the appender reaches step 4 it unlocks the file allowing another concurrent appender
to get a lock before it can perform the rollover. Therefore, once it tries to rename the file
it fails because the file is locked.

To solve this, the file must not be unlocked during the rollover process. This can be done
like this:
1. Lock the file
2. Write to file
3. Check file size (decide a rollover is needed)
5. Copy the file to file_1 (instead of rename)
4. Truncate the file using ftruncate()
5. Rewind the file pointer using rewind()
6. Unlock the file
7. Resume logging

I have done some testing with multiple loggers started from CLI, and it seems to work as expected.


Another issue I found is that LoggerAppenderRollingFile::append() first calls the parent::append()
and then performs checking of filesize for rollover. This means that the file is locked and
then unlocked twice. Once by parent append(), once by the local append().

I have fixed both these issues in revision 1134244.

Bhumir, we would appreciate your feedback.

> Permission denied while renaming log file when hundred of users are accessing the application
> ---------------------------------------------------------------------------------------------
>
>                 Key: LOG4PHP-138
>                 URL: https://issues.apache.org/jira/browse/LOG4PHP-138
>             Project: Log4php
>          Issue Type: Bug
>          Components: Code
>    Affects Versions: 2.0
>         Environment: Windows operating system
>            Reporter: Bhumir Sheth
>            Assignee: Christian Grobmeier
>            Priority: Critical
>             Fix For: 2.1
>
>
> Hi,
> We have developed a web application and integrated with log4php, which is used by hundred
of users. When the size of log file exceed the maximum file size, it calls rollOver() function
to create back up file for log file and truncate the current log file. 
> We faced one error while renaming the file from "filename" to "filename.1". This error
is generated when hundred of users are accessing the application at the same time. The error
is generated as below:
> PHP Warning:  rename(C:\PHP\errors/Test_Module.log,C:\PHP\errors/Test_Module.log.1) [<a
href='function.rename'>function.rename</a>]: Permission denied in C:\Inetpub\wwwroot\Test_Application\System\System_Logger\log4php\src\main\php\appenders\LoggerAppenderRollingFile.php
on line 140
> Also, back up of log files are not created in sequence when above warning is generated.
For example, log file "Test_Module.log" is already exists and rollOver() function is called
to create new back up file then it creates "Test_Module.log.4" instead of "Test_Module.log.1".
> Moreover, log file has given all the required permissions and it works fine while appending
the logs.
> We would appreciate if you can help us by providing a solution or work-around for resolving
this issue.
> Please let me know if more details are required.
> Thank you.
> Best regards,
> Bhumir Sheth

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message