[JBoss JIRA] (LOGMGR-256) Failure to rotate logfile on Windows system because of already open file lock
by James Perkins (Jira)
[ https://issues.jboss.org/browse/LOGMGR-256?page=com.atlassian.jira.plugin... ]
James Perkins commented on LOGMGR-256:
--------------------------------------
The {{setFileInternal(null)}} is correct. Sorry I should have caught that and I'll see if I can create a test for it.
The other issue of the rotate happening twice is a WildFly issue. I've filed WFCORE-4558 for this and I'll get a fix sorted out for this as well. Unfortunately I can't think of a workaround for this.
> Failure to rotate logfile on Windows system because of already open file lock
> -----------------------------------------------------------------------------
>
> Key: LOGMGR-256
> URL: https://issues.jboss.org/browse/LOGMGR-256
> Project: JBoss Log Manager
> Issue Type: Bug
> Affects Versions: 2.1.13.Final
> Reporter: Patrick Colbaut
> Assignee: James Perkins
> Priority: Major
>
> I've run into a similar error to the one described in LOGMGR-154, using the jboss-logmanager 2.1.13.Final release on a system that's still running Windows 7.
> Of note: The server.log file is configured to be rotated on boot.
> {code:java}
> LogManager error of type GENERIC_FAILURE: Failed to move file C:\wildfly\standalone\log\server.log to C:\wildfly\standalone\log\server.log.1.
> java.nio.file.FileSystemException: C:\wildfly\standalone\log\server.log -> C:\wildfly\standalone\log\server.log.1: The process cannot access the file because it is being used by another process.
> at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
> at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
> at sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:387)
> at sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:287)
> at java.nio.file.Files.move(Files.java:1395)
> at org.jboss.logmanager.handlers.SuffixRotator.move(SuffixRotator.java:246)
> at org.jboss.logmanager.handlers.SuffixRotator.rotate(SuffixRotator.java:174)
> at org.jboss.logmanager.handlers.SuffixRotator.rotate(SuffixRotator.java:233)
> at org.jboss.logmanager.handlers.SuffixRotator.rotate(SuffixRotator.java:193)
> at org.jboss.logmanager.handlers.SizeRotatingFileHandler.setFile(SizeRotatingFileHandler.java:142)
> at org.jboss.logmanager.handlers.FileHandler.setFileName(FileHandler.java:189)
> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:217)
> at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:197)
> at org.jboss.logmanager.config.LogContextConfigurationImpl.doApplyPostCreate(LogContextConfigurationImpl.java:313)
> at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:345)
> at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:289)
> at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:299)
> at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:106)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1411)
> at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:521)
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:472)
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:434)
> at org.jboss.as.server.ServerService.boot(ServerService.java:435)
> at org.jboss.as.server.ServerService.boot(ServerService.java:394)
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:374)
> at java.lang.Thread.run(Thread.java:748){code}
> A similar error will also occur if a compression suffix is used, although it will be the Files.delete(File) instead the Files.move(File, File) call which will fail.
> Debugging shows that SizeRotatingFileHandler.setFileName(String) is called once immediately during server boot (initialization via logging.properties) and again a short time after (via the logging subsystem I'm guessing).
> This second call results in the error above, because the SizeRotatingFileHandler instance already holds a file lock via its outputStream field, but a rotation is still attempted, as the file should rotate on boot and already contains content at that point in time.
> To confirm whether this process internal file lock is responsible, I additionally checked for other processes that might own such a handle. The only listed one is the Java process running Wildfly.
> As far as I can tell, this kind of error case should be easily fixed by adding an additional setFileInternal(null) call to clean up the open lock before actually triggering the rotation, as seen in this snippet:
> {code:java}
> public void setFile(final File file) throws FileNotFoundException {
> synchronized (outputLock) {
> // Check for a rotate
> if (rotateOnBoot && maxBackupIndex > 0 && file != null && file.exists() && file.length() > 0L) {
> setFileInternal(null);
> suffixRotator.rotate(getErrorManager(), file.toPath(), maxBackupIndex);
> }
> setFileInternal(file);
> }
> }
> {code}
> Manually adding the above mentioned call seems to allow everything to work as intended.
> And while the fact that the second setting of the same file name triggers an additional log file rotation (as rotateOnBoot = true in the used configuration) slightly annoys me, that's probably a problem for a different followup bug.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFCORE-4558) Comparing log configuration values do not correctly compare null values
by James Perkins (Jira)
James Perkins created WFCORE-4558:
-------------------------------------
Summary: Comparing log configuration values do not correctly compare null values
Key: WFCORE-4558
URL: https://issues.jboss.org/browse/WFCORE-4558
Project: WildFly Core
Issue Type: Bug
Components: Logging
Reporter: James Perkins
Assignee: James Perkins
During the boot of the logging subsystem values from the configuration are compared against the values from the model to determine if a change to the configuration is needed. When getting the configuration value it is wrapped with a {{String.valueOf()}} which for {{null}} values returns {{"null"}}. This fails the comparison and results in the configuration being overwritten. For something like a handler this means log messages could be lost if {{rotate-on-boot}} is set to {{true}} or {{append}} is set to {{false}}.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (LOGMGR-256) Failure to rotate logfile on Windows system because of already open file lock
by James Perkins (Jira)
[ https://issues.jboss.org/browse/LOGMGR-256?page=com.atlassian.jira.plugin... ]
James Perkins reassigned LOGMGR-256:
------------------------------------
Assignee: James Perkins
> Failure to rotate logfile on Windows system because of already open file lock
> -----------------------------------------------------------------------------
>
> Key: LOGMGR-256
> URL: https://issues.jboss.org/browse/LOGMGR-256
> Project: JBoss Log Manager
> Issue Type: Bug
> Affects Versions: 2.1.13.Final
> Reporter: Patrick Colbaut
> Assignee: James Perkins
> Priority: Major
>
> I've run into a similar error to the one described in LOGMGR-154, using the jboss-logmanager 2.1.13.Final release on a system that's still running Windows 7.
> Of note: The server.log file is configured to be rotated on boot.
> {code:java}
> LogManager error of type GENERIC_FAILURE: Failed to move file C:\wildfly\standalone\log\server.log to C:\wildfly\standalone\log\server.log.1.
> java.nio.file.FileSystemException: C:\wildfly\standalone\log\server.log -> C:\wildfly\standalone\log\server.log.1: The process cannot access the file because it is being used by another process.
> at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
> at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
> at sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:387)
> at sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:287)
> at java.nio.file.Files.move(Files.java:1395)
> at org.jboss.logmanager.handlers.SuffixRotator.move(SuffixRotator.java:246)
> at org.jboss.logmanager.handlers.SuffixRotator.rotate(SuffixRotator.java:174)
> at org.jboss.logmanager.handlers.SuffixRotator.rotate(SuffixRotator.java:233)
> at org.jboss.logmanager.handlers.SuffixRotator.rotate(SuffixRotator.java:193)
> at org.jboss.logmanager.handlers.SizeRotatingFileHandler.setFile(SizeRotatingFileHandler.java:142)
> at org.jboss.logmanager.handlers.FileHandler.setFileName(FileHandler.java:189)
> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:217)
> at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:197)
> at org.jboss.logmanager.config.LogContextConfigurationImpl.doApplyPostCreate(LogContextConfigurationImpl.java:313)
> at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:345)
> at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:289)
> at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:299)
> at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:106)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1411)
> at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:521)
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:472)
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:434)
> at org.jboss.as.server.ServerService.boot(ServerService.java:435)
> at org.jboss.as.server.ServerService.boot(ServerService.java:394)
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:374)
> at java.lang.Thread.run(Thread.java:748){code}
> A similar error will also occur if a compression suffix is used, although it will be the Files.delete(File) instead the Files.move(File, File) call which will fail.
> Debugging shows that SizeRotatingFileHandler.setFileName(String) is called once immediately during server boot (initialization via logging.properties) and again a short time after (via the logging subsystem I'm guessing).
> This second call results in the error above, because the SizeRotatingFileHandler instance already holds a file lock via its outputStream field, but a rotation is still attempted, as the file should rotate on boot and already contains content at that point in time.
> To confirm whether this process internal file lock is responsible, I additionally checked for other processes that might own such a handle. The only listed one is the Java process running Wildfly.
> As far as I can tell, this kind of error case should be easily fixed by adding an additional setFileInternal(null) call to clean up the open lock before actually triggering the rotation, as seen in this snippet:
> {code:java}
> public void setFile(final File file) throws FileNotFoundException {
> synchronized (outputLock) {
> // Check for a rotate
> if (rotateOnBoot && maxBackupIndex > 0 && file != null && file.exists() && file.length() > 0L) {
> setFileInternal(null);
> suffixRotator.rotate(getErrorManager(), file.toPath(), maxBackupIndex);
> }
> setFileInternal(file);
> }
> }
> {code}
> Manually adding the above mentioned call seems to allow everything to work as intended.
> And while the fact that the second setting of the same file name triggers an additional log file rotation (as rotateOnBoot = true in the used configuration) slightly annoys me, that's probably a problem for a different followup bug.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFCORE-109) Update syslog handler attributes
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFCORE-109?page=com.atlassian.jira.plugin... ]
James Perkins commented on WFCORE-109:
--------------------------------------
Hi [~rornaz] sorry no update yet. We have not had many requests for it yet, but it's something that needs to be looked at. Is there something specific you'd like? There could potentially be at least a workaround for it until this issue is sorted out.
> Update syslog handler attributes
> --------------------------------
>
> Key: WFCORE-109
> URL: https://issues.jboss.org/browse/WFCORE-109
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Major
>
> The syslog handler does not currently expose the formatter for formatting messages. There will also be changes in a future logmanager release for TCP support and various other properties based on the new TCP support.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (DROOLS-4287) KnowledgeBuilderImpl does not set a valid configuration for DTABLE resources
by Edoardo Vacchi (Jira)
Edoardo Vacchi created DROOLS-4287:
--------------------------------------
Summary: KnowledgeBuilderImpl does not set a valid configuration for DTABLE resources
Key: DROOLS-4287
URL: https://issues.jboss.org/browse/DROOLS-4287
Project: Drools
Issue Type: Enhancement
Reporter: Edoardo Vacchi
Assignee: Edoardo Vacchi
KnowledgeBuilder.add(r, ResourceType.DTABLE) gives NPE in
{code}
compileResource:64, DecisionTableProviderImpl (org.drools.decisiontable)
loadFromResource:42, DecisionTableProviderImpl (org.drools.decisiontable)
loadFromResource:35, DecisionTableFactory (org.drools.compiler.compiler)
decisionTableToPackageDescr:396, KnowledgeBuilderImpl (org.drools.compiler.builder.impl)
addPackageFromDecisionTable:366, KnowledgeBuilderImpl (org.drools.compiler.builder.impl)
addKnowledgeResource:728, KnowledgeBuilderImpl (org.drools.compiler.builder.impl)
add:2239, KnowledgeBuilderImpl (org.drools.compiler.builder.impl)
add:2228, KnowledgeBuilderImpl (org.drools.compiler.builder.impl)
{code}
because no valid default config is provided instead (null in the conditional expression)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (SWSQE-807) Tablue Project Access
by Matthew Mahoney (Jira)
Matthew Mahoney created SWSQE-807:
-------------------------------------
Summary: Tablue Project Access
Key: SWSQE-807
URL: https://issues.jboss.org/browse/SWSQE-807
Project: Kiali QE
Issue Type: Task
Reporter: Matthew Mahoney
Assignee: Prachi Yadav
[~skondkar] now has access to Tablue, but no visible projects.
[~pyadav] will you work with Sunil to get access to the following projects?
Swiftsunshine
Jaeger
Maistra
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (DROOLS-4258) DMN UX - overlay information about a single scenario run
by Edson Tirelli (Jira)
[ https://issues.jboss.org/browse/DROOLS-4258?page=com.atlassian.jira.plugi... ]
Edson Tirelli commented on DROOLS-4258:
---------------------------------------
[~uxdlc] the design for this feature should target 7.5, but the development of the feature will not make 7.5, we will have to work on that for 7.6.
> DMN UX - overlay information about a single scenario run
> --------------------------------------------------------
>
> Key: DROOLS-4258
> URL: https://issues.jboss.org/browse/DROOLS-4258
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Affects Versions: 7.24.0.Final
> Reporter: Daniele Zonca
> Assignee: Tao Zhu
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam, drools-tools
>
> Related to https://issues.jboss.org/browse/DROOLS-3731
> This task will cover this use case:
> - user creates a DMN model
> - user creates a Test Scenario with some scenarios
> - user executes the Test Scenario
> - user open Coverage Report
> - user wants to analyze the execution of a *single scenario* in the DMN model
> - user clicks on "a link" related to the scenario to analyze
> - user lands on DMN editor with overlay information about decision executed, decision failed and for each decision the possibility see actual and expected value (from the scenario) and to open an executed decision table to see which row has been evaluated
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (LOGMGR-256) Failure to rotate logfile on Windows system because of already open file lock
by Patrick Colbaut (Jira)
[ https://issues.jboss.org/browse/LOGMGR-256?page=com.atlassian.jira.plugin... ]
Patrick Colbaut updated LOGMGR-256:
-----------------------------------
Issue Type: Bug (was: Feature Request)
> Failure to rotate logfile on Windows system because of already open file lock
> -----------------------------------------------------------------------------
>
> Key: LOGMGR-256
> URL: https://issues.jboss.org/browse/LOGMGR-256
> Project: JBoss Log Manager
> Issue Type: Bug
> Affects Versions: 2.1.13.Final
> Reporter: Patrick Colbaut
> Priority: Major
>
> I've run into a similar error to the one described in LOGMGR-154, using the jboss-logmanager 2.1.13.Final release on a system that's still running Windows 7.
> Of note: The server.log file is configured to be rotated on boot.
> {code:java}
> LogManager error of type GENERIC_FAILURE: Failed to move file C:\wildfly\standalone\log\server.log to C:\wildfly\standalone\log\server.log.1.
> java.nio.file.FileSystemException: C:\wildfly\standalone\log\server.log -> C:\wildfly\standalone\log\server.log.1: The process cannot access the file because it is being used by another process.
> at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
> at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
> at sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:387)
> at sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:287)
> at java.nio.file.Files.move(Files.java:1395)
> at org.jboss.logmanager.handlers.SuffixRotator.move(SuffixRotator.java:246)
> at org.jboss.logmanager.handlers.SuffixRotator.rotate(SuffixRotator.java:174)
> at org.jboss.logmanager.handlers.SuffixRotator.rotate(SuffixRotator.java:233)
> at org.jboss.logmanager.handlers.SuffixRotator.rotate(SuffixRotator.java:193)
> at org.jboss.logmanager.handlers.SizeRotatingFileHandler.setFile(SizeRotatingFileHandler.java:142)
> at org.jboss.logmanager.handlers.FileHandler.setFileName(FileHandler.java:189)
> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:217)
> at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:197)
> at org.jboss.logmanager.config.LogContextConfigurationImpl.doApplyPostCreate(LogContextConfigurationImpl.java:313)
> at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:345)
> at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:289)
> at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:299)
> at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:106)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1411)
> at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:521)
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:472)
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:434)
> at org.jboss.as.server.ServerService.boot(ServerService.java:435)
> at org.jboss.as.server.ServerService.boot(ServerService.java:394)
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:374)
> at java.lang.Thread.run(Thread.java:748){code}
> A similar error will also occur if a compression suffix is used, although it will be the Files.delete(File) instead the Files.move(File, File) call which will fail.
> Debugging shows that SizeRotatingFileHandler.setFileName(String) is called once immediately during server boot (initialization via logging.properties) and again a short time after (via the logging subsystem I'm guessing).
> This second call results in the error above, because the SizeRotatingFileHandler instance already holds a file lock via its outputStream field, but a rotation is still attempted, as the file should rotate on boot and already contains content at that point in time.
> To confirm whether this process internal file lock is responsible, I additionally checked for other processes that might own such a handle. The only listed one is the Java process running Wildfly.
> As far as I can tell, this kind of error case should be easily fixed by adding an additional setFileInternal(null) call to clean up the open lock before actually triggering the rotation, as seen in this snippet:
> {code:java}
> public void setFile(final File file) throws FileNotFoundException {
> synchronized (outputLock) {
> // Check for a rotate
> if (rotateOnBoot && maxBackupIndex > 0 && file != null && file.exists() && file.length() > 0L) {
> setFileInternal(null);
> suffixRotator.rotate(getErrorManager(), file.toPath(), maxBackupIndex);
> }
> setFileInternal(file);
> }
> }
> {code}
> Manually adding the above mentioned call seems to allow everything to work as intended.
> And while the fact that the second setting of the same file name triggers an additional log file rotation (as rotateOnBoot = true in the used configuration) slightly annoys me, that's probably a problem for a different followup bug.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (LOGMGR-256) Failure to rotate logfile on Windows system because of already open file lock
by Patrick Colbaut (Jira)
Patrick Colbaut created LOGMGR-256:
--------------------------------------
Summary: Failure to rotate logfile on Windows system because of already open file lock
Key: LOGMGR-256
URL: https://issues.jboss.org/browse/LOGMGR-256
Project: JBoss Log Manager
Issue Type: Feature Request
Affects Versions: 2.1.13.Final
Reporter: Patrick Colbaut
I've run into a similar error to the one described in LOGMGR-154, using the jboss-logmanager 2.1.13.Final release on a system that's still running Windows 7.
Of note: The server.log file is configured to be rotated on boot.
{code:java}
LogManager error of type GENERIC_FAILURE: Failed to move file C:\wildfly\standalone\log\server.log to C:\wildfly\standalone\log\server.log.1.
java.nio.file.FileSystemException: C:\wildfly\standalone\log\server.log -> C:\wildfly\standalone\log\server.log.1: The process cannot access the file because it is being used by another process.
at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
at sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:387)
at sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:287)
at java.nio.file.Files.move(Files.java:1395)
at org.jboss.logmanager.handlers.SuffixRotator.move(SuffixRotator.java:246)
at org.jboss.logmanager.handlers.SuffixRotator.rotate(SuffixRotator.java:174)
at org.jboss.logmanager.handlers.SuffixRotator.rotate(SuffixRotator.java:233)
at org.jboss.logmanager.handlers.SuffixRotator.rotate(SuffixRotator.java:193)
at org.jboss.logmanager.handlers.SizeRotatingFileHandler.setFile(SizeRotatingFileHandler.java:142)
at org.jboss.logmanager.handlers.FileHandler.setFileName(FileHandler.java:189)
at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:217)
at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:197)
at org.jboss.logmanager.config.LogContextConfigurationImpl.doApplyPostCreate(LogContextConfigurationImpl.java:313)
at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:345)
at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:289)
at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:299)
at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:106)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1411)
at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:521)
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:472)
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:434)
at org.jboss.as.server.ServerService.boot(ServerService.java:435)
at org.jboss.as.server.ServerService.boot(ServerService.java:394)
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:374)
at java.lang.Thread.run(Thread.java:748){code}
A similar error will also occur if a compression suffix is used, although it will be the Files.delete(File) instead the Files.move(File, File) call which will fail.
Debugging shows that SizeRotatingFileHandler.setFileName(String) is called once immediately during server boot (initialization via logging.properties) and again a short time after (via the logging subsystem I'm guessing).
This second call results in the error above, because the SizeRotatingFileHandler instance already holds a file lock via its outputStream field, but a rotation is still attempted, as the file should rotate on boot and already contains content at that point in time.
To confirm whether this process internal file lock is responsible, I additionally checked for other processes that might own such a handle. The only listed one is the Java process running Wildfly.
As far as I can tell, this kind of error case should be easily fixed by adding an additional setFileInternal(null) call to clean up the open lock before actually triggering the rotation, as seen in this snippet:
{code:java}
public void setFile(final File file) throws FileNotFoundException {
synchronized (outputLock) {
// Check for a rotate
if (rotateOnBoot && maxBackupIndex > 0 && file != null && file.exists() && file.length() > 0L) {
setFileInternal(null);
suffixRotator.rotate(getErrorManager(), file.toPath(), maxBackupIndex);
}
setFileInternal(file);
}
}
{code}
Manually adding the above mentioned call seems to allow everything to work as intended.
And while the fact that the second setting of the same file name triggers an additional log file rotation (as rotateOnBoot = true in the used configuration) slightly annoys me, that's probably a problem for a different followup bug.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months