[JBoss JIRA] (WFCORE-4532) Investigate new JDK 13 regressions
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFCORE-4532?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-4532:
------------------------------------------
[~dlofthouse] The general goal is that the first WildFly .Final release after a JDK goes GA will support that JDK. JDK 13 is meant to go GA on Sept 17[1], after the planned WF 18 release, so the target would be WF 19, i.e. late November.
Having a WF .Final work with a JDK RC is there is one available is a nice-to-have. We were able to do that with WF 16 and JDK 12, but it's just a nice to have, something to go for if people have bandwidth, something to be happy about in https://wildfly.org/news/2019/02/27/WildFly16-Final-Released/.
If we shifted the WF 18 schedule a bit such that it went .Final after the JDK 13 GA I wouldn't ask that we support 13; i.e. the expectation has been 19 and a couple weeks delay doesn't bring in a major requirement like this.
[1] http://openjdk.java.net/projects/jdk/13/#Schedule
> Investigate new JDK 13 regressions
> ----------------------------------
>
> Key: WFCORE-4532
> URL: https://issues.jboss.org/browse/WFCORE-4532
> Project: WildFly Core
> Issue Type: Task
> Components: Security
> Reporter: Richard Opalka
> Assignee: Darran Lofthouse
> Priority: Critical
> Labels: jdk13
> Fix For: 9.0.2.Final
>
>
> Latest Open JDK 13 Early Access 25 introduced three new regressions in our test suite.
> Failing tests are:
> wildfly-core/elytron/src/test/java/org/wildfly/extension/elytron/TlsTestCase.java
> wildfly-core/testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/sasl/mgmt/KerberosHttpMgmtSaslTestCase.java
> wildfly-core/testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/sasl/mgmt/KerberosNativeMgmtSaslTestCase.java
> Could somebody from our security team have a look what is going on [~darran] ?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (LOGMGR-255) PeriodicRotatingFileHandler doesn't rotate log content when using Compression
by James Perkins (Jira)
[ https://issues.jboss.org/browse/LOGMGR-255?page=com.atlassian.jira.plugin... ]
James Perkins updated LOGMGR-255:
---------------------------------
Affects Version/s: 2.1.11.Final
2.0.11.Final
1.5.9.Final
> PeriodicRotatingFileHandler doesn't rotate log content when using Compression
> -----------------------------------------------------------------------------
>
> Key: LOGMGR-255
> URL: https://issues.jboss.org/browse/LOGMGR-255
> Project: JBoss Log Manager
> Issue Type: Bug
> Affects Versions: 1.5.9.Final, 2.0.11.Final, 2.1.11.Final
> Reporter: Alain Baxter
> Priority: Critical
>
> When configuring a PeriodicRotatingFileHandler where the suffix ends with .zip or .gz, as such:
> {noformat}
> <periodic-rotating-file-handler name="FILE" autoflush="true">
> <formatter>
> <named-formatter name="PATTERN"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="server.log"/>
> <suffix value=".yyyy-MM-dd-HH.gz"/>
> <append value="true"/>
> </periodic-rotating-file-handler>
> {noformat}
> This is supposed to compressed the rotated logs to save space. See https://issues.jboss.org/browse/LOGMGR-30
> What I'm seeing is that the rotation log file is successfully created and compressed at the periodic interval, however the log file content is not removed.
> This means that the log file itself continues to grow instead of rotating log content, and each rotation log contains the content from all the previous, so their size gets larger and larger:
> {noformat}
> -rw-r--r--. 1 jboss jboss 1779799 Jun 18 21:03 server.log
> -rw-r--r--. 1 jboss jboss 21831 Jun 18 19:00 server.log.2019-06-18-18.gz
> -rw-r--r--. 1 jboss jboss 55168 Jun 18 20:00 server.log.2019-06-18-19.gz
> -rw-r--r--. 1 jboss jboss 88021 Jun 18 21:00 server.log.2019-06-18-20.gz
> {noformat}
> *NOTE:* This issue would exist for SizeRotatingFileHandler and PeriodicSizeRotatingFileHandler
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (LOGMGR-255) PeriodicRotatingFileHandler doesn't rotate log content when using Compression
by James Perkins (Jira)
[ https://issues.jboss.org/browse/LOGMGR-255?page=com.atlassian.jira.plugin... ]
James Perkins commented on LOGMGR-255:
--------------------------------------
Perfect thank you [~cira-alain] and my assumption is you are correct. I'll work on a fix for this today as it seems like a fairly serious issue.
> PeriodicRotatingFileHandler doesn't rotate log content when using Compression
> -----------------------------------------------------------------------------
>
> Key: LOGMGR-255
> URL: https://issues.jboss.org/browse/LOGMGR-255
> Project: JBoss Log Manager
> Issue Type: Bug
> Reporter: Alain Baxter
> Priority: Major
>
> When configuring a PeriodicRotatingFileHandler where the suffix ends with .zip or .gz, as such:
> {noformat}
> <periodic-rotating-file-handler name="FILE" autoflush="true">
> <formatter>
> <named-formatter name="PATTERN"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="server.log"/>
> <suffix value=".yyyy-MM-dd-HH.gz"/>
> <append value="true"/>
> </periodic-rotating-file-handler>
> {noformat}
> This is supposed to compressed the rotated logs to save space. See https://issues.jboss.org/browse/LOGMGR-30
> What I'm seeing is that the rotation log file is successfully created and compressed at the periodic interval, however the log file content is not removed.
> This means that the log file itself continues to grow instead of rotating log content, and each rotation log contains the content from all the previous, so their size gets larger and larger:
> {noformat}
> -rw-r--r--. 1 jboss jboss 1779799 Jun 18 21:03 server.log
> -rw-r--r--. 1 jboss jboss 21831 Jun 18 19:00 server.log.2019-06-18-18.gz
> -rw-r--r--. 1 jboss jboss 55168 Jun 18 20:00 server.log.2019-06-18-19.gz
> -rw-r--r--. 1 jboss jboss 88021 Jun 18 21:00 server.log.2019-06-18-20.gz
> {noformat}
> *NOTE:* This issue would exist for SizeRotatingFileHandler and PeriodicSizeRotatingFileHandler
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (LOGMGR-255) PeriodicRotatingFileHandler doesn't rotate log content when using Compression
by James Perkins (Jira)
[ https://issues.jboss.org/browse/LOGMGR-255?page=com.atlassian.jira.plugin... ]
James Perkins updated LOGMGR-255:
---------------------------------
Priority: Critical (was: Major)
> PeriodicRotatingFileHandler doesn't rotate log content when using Compression
> -----------------------------------------------------------------------------
>
> Key: LOGMGR-255
> URL: https://issues.jboss.org/browse/LOGMGR-255
> Project: JBoss Log Manager
> Issue Type: Bug
> Reporter: Alain Baxter
> Priority: Critical
>
> When configuring a PeriodicRotatingFileHandler where the suffix ends with .zip or .gz, as such:
> {noformat}
> <periodic-rotating-file-handler name="FILE" autoflush="true">
> <formatter>
> <named-formatter name="PATTERN"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="server.log"/>
> <suffix value=".yyyy-MM-dd-HH.gz"/>
> <append value="true"/>
> </periodic-rotating-file-handler>
> {noformat}
> This is supposed to compressed the rotated logs to save space. See https://issues.jboss.org/browse/LOGMGR-30
> What I'm seeing is that the rotation log file is successfully created and compressed at the periodic interval, however the log file content is not removed.
> This means that the log file itself continues to grow instead of rotating log content, and each rotation log contains the content from all the previous, so their size gets larger and larger:
> {noformat}
> -rw-r--r--. 1 jboss jboss 1779799 Jun 18 21:03 server.log
> -rw-r--r--. 1 jboss jboss 21831 Jun 18 19:00 server.log.2019-06-18-18.gz
> -rw-r--r--. 1 jboss jboss 55168 Jun 18 20:00 server.log.2019-06-18-19.gz
> -rw-r--r--. 1 jboss jboss 88021 Jun 18 21:00 server.log.2019-06-18-20.gz
> {noformat}
> *NOTE:* This issue would exist for SizeRotatingFileHandler and PeriodicSizeRotatingFileHandler
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-11213) On release of batch it still contained JDBC statements logged
by Cody Lerum (Jira)
[ https://issues.jboss.org/browse/WFLY-11213?page=com.atlassian.jira.plugin... ]
Cody Lerum commented on WFLY-11213:
-----------------------------------
[~gbadner] Just an FYI that the
{code}
INFO [org.hibernate.engine.jdbc.batch.internal.AbstractBatchImpl] (default task-136) HHH000010: On release of batch it still contained JDBC statements
{code}
Still logs in Wildfly 17 Final
> On release of batch it still contained JDBC statements logged
> -------------------------------------------------------------
>
> Key: WFLY-11213
> URL: https://issues.jboss.org/browse/WFLY-11213
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 14.0.1.Final
> Environment: Java 8_181
> Wildfly 14.0.1.Final
> Reporter: Cody Lerum
> Assignee: Scott Marlow
> Priority: Major
>
> After updating from Wildfly 11 (Hibernate 5.1.10) to Wildfly 14.0.1 (Hibernate 5.3.6) I've started seeing the following log messages
> I’m starting to see the log message
> {code:java}
> 2018-10-17 20:12:47,571 INFO [org.hibernate.engine.jdbc.batch.internal.AbstractBatchImpl] (default task-54) HHH000010: On release of batch it still contained JDBC statements
> 2018-10-17 20:12:47,572 ERROR [org.hibernate.engine.jdbc.batch.internal.AbstractBatchImpl] (default task-54) HHH000352: Unable to release batch statement...
> {code}
> I’ve debugged where that is getting logged and all I can find is a single statement at the time.
> insert into EventLog (entityId, entityType, ipAddress, message, time, user, id) values (?, ?, ?, ?, ?, ?, ?)
> The only insert that is being created is actually being persisted to the database so this may be a spurious message.
> From my early debugging this appears to happen when 1 entity is persisted which does not need an immediate inset (due to having a generated pk) and then in another method of the same transaction an entity is persisted that does need an immediate insert because of a auto increment pk.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (LOGMGR-255) PeriodicRotatingFileHandler doesn't rotate log content when using Compression
by Alain Baxter (Jira)
[ https://issues.jboss.org/browse/LOGMGR-255?page=com.atlassian.jira.plugin... ]
Alain Baxter commented on LOGMGR-255:
-------------------------------------
I'm using JBoss EAP 7.2.
I have done some additional testing after looking at https://github.com/jamezp/jboss-logmanager/blob/2.2/src/test/java/org/jbo... and noticing that it only tests with append = false.
When I modify my configuration to this that the rollover works correctly, however with append = true it does not, so the issue seems to be around this parameter with respect to compressing the rotated logs.
My suspicion is that without compression the code does a Files.move which removes the original log file, thus the Handler by default would create a new file, however with compressing, the code uses Input and Output stream to copy/compress the content of the original log file, but leaves the original log file unchanged. See: https://github.com/jboss-logging/jboss-logmanager/blob/2.2/src/main/java/... starting from line 153 and following through the archiveGzip, archiveZip, and move methods. Thus the Handler would continue to append content to the same log file with compression configured on rotation.
> PeriodicRotatingFileHandler doesn't rotate log content when using Compression
> -----------------------------------------------------------------------------
>
> Key: LOGMGR-255
> URL: https://issues.jboss.org/browse/LOGMGR-255
> Project: JBoss Log Manager
> Issue Type: Bug
> Reporter: Alain Baxter
> Priority: Major
>
> When configuring a PeriodicRotatingFileHandler where the suffix ends with .zip or .gz, as such:
> {noformat}
> <periodic-rotating-file-handler name="FILE" autoflush="true">
> <formatter>
> <named-formatter name="PATTERN"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="server.log"/>
> <suffix value=".yyyy-MM-dd-HH.gz"/>
> <append value="true"/>
> </periodic-rotating-file-handler>
> {noformat}
> This is supposed to compressed the rotated logs to save space. See https://issues.jboss.org/browse/LOGMGR-30
> What I'm seeing is that the rotation log file is successfully created and compressed at the periodic interval, however the log file content is not removed.
> This means that the log file itself continues to grow instead of rotating log content, and each rotation log contains the content from all the previous, so their size gets larger and larger:
> {noformat}
> -rw-r--r--. 1 jboss jboss 1779799 Jun 18 21:03 server.log
> -rw-r--r--. 1 jboss jboss 21831 Jun 18 19:00 server.log.2019-06-18-18.gz
> -rw-r--r--. 1 jboss jboss 55168 Jun 18 20:00 server.log.2019-06-18-19.gz
> -rw-r--r--. 1 jboss jboss 88021 Jun 18 21:00 server.log.2019-06-18-20.gz
> {noformat}
> *NOTE:* This issue would exist for SizeRotatingFileHandler and PeriodicSizeRotatingFileHandler
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (LOGMGR-255) PeriodicRotatingFileHandler doesn't rotate log content when using Compression
by Alain Baxter (Jira)
[ https://issues.jboss.org/browse/LOGMGR-255?page=com.atlassian.jira.plugin... ]
Alain Baxter edited comment on LOGMGR-255 at 6/19/19 12:26 PM:
---------------------------------------------------------------
I'm using JBoss EAP 7.2.
I have done some additional testing after looking at https://github.com/jamezp/jboss-logmanager/blob/2.2/src/test/java/org/jbo... and noticing that it only tests with append = false.
When I modify my configuration to this then the rollover works correctly, however with append = true it does not, so the issue seems to be around this parameter with respect to compressing the rotated logs.
My suspicion is that without compression the code does a Files.move which removes the original log file, thus the Handler by default would create a new file, however with compressing, the code uses Input and Output stream to copy/compress the content of the original log file, but leaves the original log file unchanged. See: https://github.com/jboss-logging/jboss-logmanager/blob/2.2/src/main/java/... starting from line 153 and following through the archiveGzip, archiveZip, and move methods. Thus the Handler would continue to append content to the same log file with compression configured on rotation.
was (Author: cira-alain):
I'm using JBoss EAP 7.2.
I have done some additional testing after looking at https://github.com/jamezp/jboss-logmanager/blob/2.2/src/test/java/org/jbo... and noticing that it only tests with append = false.
When I modify my configuration to this that the rollover works correctly, however with append = true it does not, so the issue seems to be around this parameter with respect to compressing the rotated logs.
My suspicion is that without compression the code does a Files.move which removes the original log file, thus the Handler by default would create a new file, however with compressing, the code uses Input and Output stream to copy/compress the content of the original log file, but leaves the original log file unchanged. See: https://github.com/jboss-logging/jboss-logmanager/blob/2.2/src/main/java/... starting from line 153 and following through the archiveGzip, archiveZip, and move methods. Thus the Handler would continue to append content to the same log file with compression configured on rotation.
> PeriodicRotatingFileHandler doesn't rotate log content when using Compression
> -----------------------------------------------------------------------------
>
> Key: LOGMGR-255
> URL: https://issues.jboss.org/browse/LOGMGR-255
> Project: JBoss Log Manager
> Issue Type: Bug
> Reporter: Alain Baxter
> Priority: Major
>
> When configuring a PeriodicRotatingFileHandler where the suffix ends with .zip or .gz, as such:
> {noformat}
> <periodic-rotating-file-handler name="FILE" autoflush="true">
> <formatter>
> <named-formatter name="PATTERN"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="server.log"/>
> <suffix value=".yyyy-MM-dd-HH.gz"/>
> <append value="true"/>
> </periodic-rotating-file-handler>
> {noformat}
> This is supposed to compressed the rotated logs to save space. See https://issues.jboss.org/browse/LOGMGR-30
> What I'm seeing is that the rotation log file is successfully created and compressed at the periodic interval, however the log file content is not removed.
> This means that the log file itself continues to grow instead of rotating log content, and each rotation log contains the content from all the previous, so their size gets larger and larger:
> {noformat}
> -rw-r--r--. 1 jboss jboss 1779799 Jun 18 21:03 server.log
> -rw-r--r--. 1 jboss jboss 21831 Jun 18 19:00 server.log.2019-06-18-18.gz
> -rw-r--r--. 1 jboss jboss 55168 Jun 18 20:00 server.log.2019-06-18-19.gz
> -rw-r--r--. 1 jboss jboss 88021 Jun 18 21:00 server.log.2019-06-18-20.gz
> {noformat}
> *NOTE:* This issue would exist for SizeRotatingFileHandler and PeriodicSizeRotatingFileHandler
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFCORE-4532) Investigate new JDK 13 regressions
by Richard Opalka (Jira)
[ https://issues.jboss.org/browse/WFCORE-4532?page=com.atlassian.jira.plugi... ]
Richard Opalka edited comment on WFCORE-4532 at 6/19/19 11:33 AM:
------------------------------------------------------------------
Since I am not the security expert and this issue is out of my expertise could anybody from our security team investigate this new regression?
Maybe this issue is also affecting KerberosHttpMgmtSaslTestCase & KerberosNativeMgmtSaslTestCase failing tests?
Open JDK 13 is now entering round up phase 1.
If this is a new regression in latest JDK it would be great
to report it as soon as possible to get it fixed in final JDK 13 release.
was (Author: ropalka):
Since I am not the security expert and this issue is out of my expertise could anybody from our security team investigate this new regression?
Maybe this issue is also affecting KerberosHttpMgmtSaslTestCase & KerberosNativeMgmtSaslTestCase failing tests?
Open JDK 13 is now entering round up phase 1.
If this is a new regression in latest JDK it would be great
to report it as soon as possible so it might be fixed in final JDK 13 release.
> Investigate new JDK 13 regressions
> ----------------------------------
>
> Key: WFCORE-4532
> URL: https://issues.jboss.org/browse/WFCORE-4532
> Project: WildFly Core
> Issue Type: Task
> Components: Security
> Reporter: Richard Opalka
> Assignee: Darran Lofthouse
> Priority: Critical
> Labels: jdk13
> Fix For: 9.0.2.Final
>
>
> Latest Open JDK 13 Early Access 25 introduced three new regressions in our test suite.
> Failing tests are:
> wildfly-core/elytron/src/test/java/org/wildfly/extension/elytron/TlsTestCase.java
> wildfly-core/testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/sasl/mgmt/KerberosHttpMgmtSaslTestCase.java
> wildfly-core/testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/sasl/mgmt/KerberosNativeMgmtSaslTestCase.java
> Could somebody from our security team have a look what is going on [~darran] ?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFCORE-4532) Investigate new JDK 13 regressions
by Richard Opalka (Jira)
[ https://issues.jboss.org/browse/WFCORE-4532?page=com.atlassian.jira.plugi... ]
Richard Opalka commented on WFCORE-4532:
----------------------------------------
Since I am not the security expert and this issue is out of my expertise could anybody from our security team investigate this new regression?
Maybe this issue is also affecting KerberosHttpMgmtSaslTestCase & KerberosNativeMgmtSaslTestCase failing tests?
Open JDK 13 is now entering round up phase 1.
If this is a new regression in latest JDK it would be great
to report it as soon as possible so it might be fixed in final JDK 13 release.
> Investigate new JDK 13 regressions
> ----------------------------------
>
> Key: WFCORE-4532
> URL: https://issues.jboss.org/browse/WFCORE-4532
> Project: WildFly Core
> Issue Type: Task
> Components: Security
> Reporter: Richard Opalka
> Assignee: Darran Lofthouse
> Priority: Critical
> Labels: jdk13
> Fix For: 9.0.2.Final
>
>
> Latest Open JDK 13 Early Access 25 introduced three new regressions in our test suite.
> Failing tests are:
> wildfly-core/elytron/src/test/java/org/wildfly/extension/elytron/TlsTestCase.java
> wildfly-core/testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/sasl/mgmt/KerberosHttpMgmtSaslTestCase.java
> wildfly-core/testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/sasl/mgmt/KerberosNativeMgmtSaslTestCase.java
> Could somebody from our security team have a look what is going on [~darran] ?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFCORE-4532) Investigate new JDK 13 regressions
by Richard Opalka (Jira)
[ https://issues.jboss.org/browse/WFCORE-4532?page=com.atlassian.jira.plugi... ]
Richard Opalka updated WFCORE-4532:
-----------------------------------
Labels: jdk13 (was: )
> Investigate new JDK 13 regressions
> ----------------------------------
>
> Key: WFCORE-4532
> URL: https://issues.jboss.org/browse/WFCORE-4532
> Project: WildFly Core
> Issue Type: Task
> Components: Security
> Reporter: Richard Opalka
> Assignee: Darran Lofthouse
> Priority: Critical
> Labels: jdk13
> Fix For: 9.0.2.Final
>
>
> Latest Open JDK 13 Early Access 25 introduced three new regressions in our test suite.
> Failing tests are:
> wildfly-core/elytron/src/test/java/org/wildfly/extension/elytron/TlsTestCase.java
> wildfly-core/testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/sasl/mgmt/KerberosHttpMgmtSaslTestCase.java
> wildfly-core/testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/sasl/mgmt/KerberosNativeMgmtSaslTestCase.java
> Could somebody from our security team have a look what is going on [~darran] ?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months