[JBoss JIRA] (DROOLS-2409) Memory Leak in sliding window
by Mike Baranski (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2409?page=com.atlassian.jira.plugi... ]
Mike Baranski edited comment on DROOLS-2409 at 3/22/18 9:21 AM:
----------------------------------------------------------------
Agreed on the fact that this is not *really* a great real-world example. Perhaps better is a "batch" like example where we add maybe 200 records at a time and sleep in between:
{{for (i = 0; i < 10000000; i++) {
averageMeasurementService.addMeasurement(new Measurement(random.nextInt(100)));
if (i % 100000 == 0) {
System.out.println(i + " inserted into list of " + averageMeasurementService.getFactCount());
Thread.sleep(500l);
}
if (i % 200 == 0) {
Thread.sleep(100l);
}
}
}}
This sleeps 100 ms each 200 events, which drools seems to be able to handle OK for the first few million at least.
This starts to really degrade the performance:
```
for (i = 0; i < 10000000; i++) {
averageMeasurementService.addMeasurement(new Measurement(random.nextInt(100)));
if (i % 100000 == 0) {
System.out.println(i + " inserted into list of " + averageMeasurementService.getFactCount());
Thread.sleep(500l);
}
if (i % 200 == 0) {
Thread.sleep(10l);
}
}
```
In fact, with the above, it looks like maybe the event counter is overflowing:
{quote}
6200000 inserted into list of -1170
zzZZzz: 49.609819277108436
zzZZzz: 49.63111764705882
zzZZzz: 49.31702380952381
zzZZzz: 49.355625
6300000 inserted into list of 20459
zzZZzz: 49.52712348322627
zzZZzz: 49.58170454545454
6400000 inserted into list of 70065
{quote}
was (Author: mbaranski):
Agreed on the fact that this is not *really* a great real-world example. Perhaps better is a "batch" like example where we add maybe 200 records at a time and sleep in between:
```
for (i = 0; i < 10000000; i++) {
averageMeasurementService.addMeasurement(new Measurement(random.nextInt(100)));
if (i % 100000 == 0) {
System.out.println(i + " inserted into list of " + averageMeasurementService.getFactCount());
Thread.sleep(500l);
}
if (i % 200 == 0) {
Thread.sleep(100l);
}
}
```
This sleeps 100 ms each 200 events, which drools seems to be able to handle OK for the first few million at least.
This starts to really degrade the performance:
```
for (i = 0; i < 10000000; i++) {
averageMeasurementService.addMeasurement(new Measurement(random.nextInt(100)));
if (i % 100000 == 0) {
System.out.println(i + " inserted into list of " + averageMeasurementService.getFactCount());
Thread.sleep(500l);
}
if (i % 200 == 0) {
Thread.sleep(10l);
}
}
```
In fact, with the above, it looks like maybe the event counter is overflowing:
{quote}
6200000 inserted into list of -1170
zzZZzz: 49.609819277108436
zzZZzz: 49.63111764705882
zzZZzz: 49.31702380952381
zzZZzz: 49.355625
6300000 inserted into list of 20459
zzZZzz: 49.52712348322627
zzZZzz: 49.58170454545454
6400000 inserted into list of 70065
{quote}
> Memory Leak in sliding window
> -----------------------------
>
> Key: DROOLS-2409
> URL: https://issues.jboss.org/browse/DROOLS-2409
> Project: Drools
> Issue Type: Feature Request
> Components: core engine
> Affects Versions: 7.6.0.Final
> Environment: Mac with Java 1.8 using Spring Boot (see attached demo project)
> Reporter: Mike Baranski
> Assignee: Mario Fusco
> Priority: Critical
> Attachments: complete.tar.gz
>
>
> See attached project.
> `gradle test` causes an out of memory exception on my machine after ~2.6 million events. Events should be released for GC after 1 second, but that does not appear to be happening.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (DROOLS-2409) Memory Leak in sliding window
by Mike Baranski (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2409?page=com.atlassian.jira.plugi... ]
Mike Baranski edited comment on DROOLS-2409 at 3/22/18 9:21 AM:
----------------------------------------------------------------
Agreed on the fact that this is not *really* a great real-world example. Perhaps better is a "batch" like example where we add maybe 200 records at a time and sleep in between:
bq. for (i = 0; i < 10000000; i++) {
bq. averageMeasurementService.addMeasurement(new Measurement(random.nextInt(100)));
bq. if (i % 100000 == 0) {
bq. System.out.println(i + " inserted into list of " + averageMeasurementService.getFactCount());
bq. Thread.sleep(500l);
bq. }
bq. if (i % 200 == 0) {
bq. Thread.sleep(100l);
bq. }
bq. }
bq.
bq.
This sleeps 100 ms each 200 events, which drools seems to be able to handle OK for the first few million at least.
This starts to really degrade the performance:
```
for (i = 0; i < 10000000; i++) {
averageMeasurementService.addMeasurement(new Measurement(random.nextInt(100)));
if (i % 100000 == 0) {
System.out.println(i + " inserted into list of " + averageMeasurementService.getFactCount());
Thread.sleep(500l);
}
if (i % 200 == 0) {
Thread.sleep(10l);
}
}
```
In fact, with the above, it looks like maybe the event counter is overflowing:
{quote}
6200000 inserted into list of -1170
zzZZzz: 49.609819277108436
zzZZzz: 49.63111764705882
zzZZzz: 49.31702380952381
zzZZzz: 49.355625
6300000 inserted into list of 20459
zzZZzz: 49.52712348322627
zzZZzz: 49.58170454545454
6400000 inserted into list of 70065
{quote}
was (Author: mbaranski):
Agreed on the fact that this is not *really* a great real-world example. Perhaps better is a "batch" like example where we add maybe 200 records at a time and sleep in between:
{{for (i = 0; i < 10000000; i++) {
averageMeasurementService.addMeasurement(new Measurement(random.nextInt(100)));
if (i % 100000 == 0) {
System.out.println(i + " inserted into list of " + averageMeasurementService.getFactCount());
Thread.sleep(500l);
}
if (i % 200 == 0) {
Thread.sleep(100l);
}
}
}}
This sleeps 100 ms each 200 events, which drools seems to be able to handle OK for the first few million at least.
This starts to really degrade the performance:
```
for (i = 0; i < 10000000; i++) {
averageMeasurementService.addMeasurement(new Measurement(random.nextInt(100)));
if (i % 100000 == 0) {
System.out.println(i + " inserted into list of " + averageMeasurementService.getFactCount());
Thread.sleep(500l);
}
if (i % 200 == 0) {
Thread.sleep(10l);
}
}
```
In fact, with the above, it looks like maybe the event counter is overflowing:
{quote}
6200000 inserted into list of -1170
zzZZzz: 49.609819277108436
zzZZzz: 49.63111764705882
zzZZzz: 49.31702380952381
zzZZzz: 49.355625
6300000 inserted into list of 20459
zzZZzz: 49.52712348322627
zzZZzz: 49.58170454545454
6400000 inserted into list of 70065
{quote}
> Memory Leak in sliding window
> -----------------------------
>
> Key: DROOLS-2409
> URL: https://issues.jboss.org/browse/DROOLS-2409
> Project: Drools
> Issue Type: Feature Request
> Components: core engine
> Affects Versions: 7.6.0.Final
> Environment: Mac with Java 1.8 using Spring Boot (see attached demo project)
> Reporter: Mike Baranski
> Assignee: Mario Fusco
> Priority: Critical
> Attachments: complete.tar.gz
>
>
> See attached project.
> `gradle test` causes an out of memory exception on my machine after ~2.6 million events. Events should be released for GC after 1 second, but that does not appear to be happening.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (DROOLS-2409) Memory Leak in sliding window
by Mike Baranski (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2409?page=com.atlassian.jira.plugi... ]
Mike Baranski commented on DROOLS-2409:
---------------------------------------
Agreed on the fact that this is not *really* a great real-world example. Perhaps better is a "batch" like example where we add maybe 200 records at a time and sleep in between:
```
for (i = 0; i < 10000000; i++) {
averageMeasurementService.addMeasurement(new Measurement(random.nextInt(100)));
if (i % 100000 == 0) {
System.out.println(i + " inserted into list of " + averageMeasurementService.getFactCount());
Thread.sleep(500l);
}
if (i % 200 == 0) {
Thread.sleep(100l);
}
}
```
This sleeps 100 ms each 200 events, which drools seems to be able to handle OK for the first few million at least.
This starts to really degrade the performance:
```
for (i = 0; i < 10000000; i++) {
averageMeasurementService.addMeasurement(new Measurement(random.nextInt(100)));
if (i % 100000 == 0) {
System.out.println(i + " inserted into list of " + averageMeasurementService.getFactCount());
Thread.sleep(500l);
}
if (i % 200 == 0) {
Thread.sleep(10l);
}
}
```
In fact, with the above, it looks like maybe the event counter is overflowing:
{quote}
6200000 inserted into list of -1170
zzZZzz: 49.609819277108436
zzZZzz: 49.63111764705882
zzZZzz: 49.31702380952381
zzZZzz: 49.355625
6300000 inserted into list of 20459
zzZZzz: 49.52712348322627
zzZZzz: 49.58170454545454
6400000 inserted into list of 70065
{quote}
> Memory Leak in sliding window
> -----------------------------
>
> Key: DROOLS-2409
> URL: https://issues.jboss.org/browse/DROOLS-2409
> Project: Drools
> Issue Type: Feature Request
> Components: core engine
> Affects Versions: 7.6.0.Final
> Environment: Mac with Java 1.8 using Spring Boot (see attached demo project)
> Reporter: Mike Baranski
> Assignee: Mario Fusco
> Priority: Critical
> Attachments: complete.tar.gz
>
>
> See attached project.
> `gradle test` causes an out of memory exception on my machine after ~2.6 million events. Events should be released for GC after 1 second, but that does not appear to be happening.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10062) Application deployment fails with java.lang.NoClassDefFoundError: javax/enterprise/inject/Any$Literal
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-10062?page=com.atlassian.jira.plugin... ]
Martin Kouba updated WFLY-10062:
--------------------------------
Fix Version/s: 13.0.0.Beta1
> Application deployment fails with java.lang.NoClassDefFoundError: javax/enterprise/inject/Any$Literal
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-10062
> URL: https://issues.jboss.org/browse/WFLY-10062
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 12.0.0.Final
> Reporter: Rich DiCroce
> Assignee: Martin Kouba
> Fix For: 13.0.0.Beta1
>
>
> Application fails to deploy with the below stack trace. EE8 preview mode is NOT enabled, which appears to be the cause. cdi-api-2.0.jar contains the class, but cdi-api-1.2.jar does not.
> {quote}
> 10:27:34,790 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.unit."song-gaming-portal.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."song-gaming-portal.war".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1706)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1540)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_162]
> Caused by: java.lang.NoClassDefFoundError: javax/enterprise/inject/Any$Literal
> at org.jboss.weld.util.Observers.isContainerLifecycleObserverMethod(Observers.java:102) [weld-core-impl-3.0.3.Final.jar:3.0.3.Final]
> at org.jboss.weld.bootstrap.ExtensionBeanDeployer.createObserverMethod(ExtensionBeanDeployer.java:151) [weld-core-impl-3.0.3.Final.jar:3.0.3.Final]
> at org.jboss.weld.bootstrap.ExtensionBeanDeployer.createObserverMethods(ExtensionBeanDeployer.java:140) [weld-core-impl-3.0.3.Final.jar:3.0.3.Final]
> at org.jboss.weld.bootstrap.ExtensionBeanDeployer.deployBean(ExtensionBeanDeployer.java:101) [weld-core-impl-3.0.3.Final.jar:3.0.3.Final]
> at org.jboss.weld.bootstrap.ExtensionBeanDeployer.deployBeans(ExtensionBeanDeployer.java:75) [weld-core-impl-3.0.3.Final.jar:3.0.3.Final]
> at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:377) [weld-core-impl-3.0.3.Final.jar:3.0.3.Final]
> at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) [weld-core-impl-3.0.3.Final.jar:3.0.3.Final]
> at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:95)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1714)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1693)
> ... 6 more
> Caused by: java.lang.ClassNotFoundException: javax.enterprise.inject.Any$Literal from [Module "org.jboss.weld.core" from local module loader @2ea6137 (finder: local module finder @41ee392b (roots: D:\wildfly\wildfly-12.0.0.Final-GP\modules,D:\wildfly\wildfly-12.0.0.Final-GP\modules\system\layers\base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199) [jboss-modules.jar:1.7.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) [jboss-modules.jar:1.7.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) [jboss-modules.jar:1.7.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) [jboss-modules.jar:1.7.0.Final]
> ... 16 more
> {quote}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10031) Scripts throws "illegal reflective access" warning on JDK9
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-10031?page=com.atlassian.jira.plugin... ]
David Lloyd commented on WFLY-10031:
------------------------------------
That is fixed in JBoss Threads 2.3.2.Final which was brought into wildfly-core last week. If you update to the latest core you might get a different result.
> Scripts throws "illegal reflective access" warning on JDK9
> ----------------------------------------------------------
>
> Key: WFLY-10031
> URL: https://issues.jboss.org/browse/WFLY-10031
> Project: WildFly
> Issue Type: Bug
> Components: Scripts, Security
> Reporter: Marek Kopecký
> Assignee: James Perkins
> Priority: Blocker
>
> *Description of the issue:*
> Scripts throws "illegal reflective access" warning on JDK9/10/11.
> *How reproducible:*
> Always with JDK9, 10 and 11
> *Steps to Reproduce:*
> * ./jboss-cli.sh "echo test"
> * ./add-user.sh -u test4 -p Test123* -s
> * ./appclient.sh -v
> * ./wsconsume.sh
> * ./wsprovide.sh
> * ./domain.sh
> * ./standalone.sh
> *Actual results:*
> {noformat}
> [hudson@rhel7-large-9887 bin]$ java --version
> java 9.0.4
> Java(TM) SE Runtime Environment (build 9.0.4+11)
> Java HotSpot(TM) 64-Bit Server VM (build 9.0.4+11, mixed mode)
> [hudson@rhel7-large-9887 bin]$
> {noformat}
> {noformat}
> [hudson@rhel7-large-9887 bin]$ ./jboss-cli.sh "echo test"
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.jboss.logmanager.LogManager$2 (jar:file:/home/hudson/hudson_workspace/workspace/early-testing-scripts-unix/9774dccf/wildfly/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.0.9.Final.jar!/) to constructor java.util.logging.Level$KnownLevel(java.util.logging.Level)
> WARNING: Please consider reporting this to the maintainers of org.jboss.logmanager.LogManager$2
> WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> test
> [hudson@rhel7-large-9887 bin]$
> {noformat}
> {noformat}
> [hudson@rhel7-large-9887 bin]$ ./add-user.sh -u test4 -p Test123* -s
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.jboss.logmanager.LogManager$2 (jar:file:/home/hudson/hudson_workspace/workspace/early-testing-scripts-unix/9774dccf/wildfly/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.0.9.Final.jar!/) to constructor java.util.logging.Level$KnownLevel(java.util.logging.Level)
> WARNING: Please consider reporting this to the maintainers of org.jboss.logmanager.LogManager$2
> WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> [hudson@rhel7-large-9887 bin]$ cat ../standalone/configuration/mgmt-users.properties | tail -n 1
> test4=a95aa9d159b7afe0cc9d3795061551ad
> [hudson@rhel7-large-9887 bin]$
> {noformat}
> {noformat}
> [hudson@rhel7-large-9887 bin]$ ./appclient.sh -v
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.jboss.logmanager.LogManager$2 (jar:file:/home/hudson/hudson_workspace/workspace/early-testing-scripts-unix/9774dccf/wildfly/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.0.9.Final.jar!/) to constructor java.util.logging.Level$KnownLevel(java.util.logging.Level)
> WARNING: Please consider reporting this to the maintainers of org.jboss.logmanager.LogManager$2
> WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> 06:11:52,205 INFO [org.jboss.modules] (main) JBoss Modules version 1.7.0.Final
> WildFly Full 13.0.0.Alpha1-SNAPSHOT (WildFly Core 4.0.0.Final)
> [hudson@rhel7-large-9887 bin]$
> {noformat}
> *Expected results:*
> No warnings
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (ELY-1521) Coverity, SpnegoContext is Serializable; consider declaring a serialVersionUID
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-1521?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev reassigned ELY-1521:
----------------------------------
Assignee: Ilia Vassilev
> Coverity, SpnegoContext is Serializable; consider declaring a serialVersionUID
> ------------------------------------------------------------------------------
>
> Key: ELY-1521
> URL: https://issues.jboss.org/browse/ELY-1521
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms
> Affects Versions: 1.2.1.Final, 1.3.0.CR1
> Reporter: Martin Choma
> Assignee: Ilia Vassilev
>
> New class SpnegoContext is Serializable, but does not define serialVersionUID explicitely.
> {code}
> /src/main/java/org/wildfly/security/http/impl/SpnegoAuthenticationMechanism.java: 466 in ()
> 460 } catch (AuthenticationMechanismException e) {
> 461 throw e.toHttpAuthenticationException();
> 462 } catch (UnsupportedCallbackException ignored) {
> 463 }
> 464 }
> 465
> >>> CID 1465386: FindBugs: Bad practice (FB.SE_NO_SERIALVERSIONID)
> >>> org.wildfly.security.http.impl.SpnegoAuthenticationMechanism$SpnegoContext is Serializable; consider declaring a serialVersionUID.
> 466 private static class SpnegoContext implements Serializable {
> 467 transient GSSContext gssContext;
> 468 transient KerberosTicket kerberosTicket;
> 469 }
> 470
> {code}
> [1] https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-9107) Block non-SSL IIOP port when SSL transport is required
by Jan Stourac (JIRA)
[ https://issues.jboss.org/browse/WFLY-9107?page=com.atlassian.jira.plugin.... ]
Jan Stourac updated WFLY-9107:
------------------------------
Description:
When iiop configuration indicates SSL is required client should not be able to connect without SSL.
For example, with
{noformat}
<transport-config confidentiality="required" trust-in-target="supported"/>
{noformat}
connecting to {{corbaloc:iiop:1.2@<url>:3528/JBoss/Naming/root}} should not be possible
was:
When iiop configuration indicates SSL is required client should not be able to connect without SSL.
For example, with
{noformat}
<transport-config confidentiality="required" trust-in-target="supported"/>
{noformat}
connecting to {{monospaced}}corbaloc:iiop:1.2@<url>:3528/JBoss/Naming/root{{monospaced}} should not be possible
> Block non-SSL IIOP port when SSL transport is required
> ------------------------------------------------------
>
> Key: WFLY-9107
> URL: https://issues.jboss.org/browse/WFLY-9107
> Project: WildFly
> Issue Type: Enhancement
> Reporter: Tomasz Adamski
> Assignee: Tomasz Adamski
>
> When iiop configuration indicates SSL is required client should not be able to connect without SSL.
> For example, with
> {noformat}
> <transport-config confidentiality="required" trust-in-target="supported"/>
> {noformat}
> connecting to {{corbaloc:iiop:1.2@<url>:3528/JBoss/Naming/root}} should not be possible
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-9985) NPE in server log when Artemis trace logging is enabled
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-9985?page=com.atlassian.jira.plugin.... ]
Miroslav Novak commented on WFLY-9985:
--------------------------------------
Fixed upstream - see ARTEMIS-1743.
> NPE in server log when Artemis trace logging is enabled
> -------------------------------------------------------
>
> Key: WFLY-9985
> URL: https://issues.jboss.org/browse/WFLY-9985
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
>
> Artemis master (95b7438e7a7661692d5b78be944d05e254df9067) contains issue when trace logging is enabled.
> If large message is sent and Artemis trace logs are enabled then following NPE is logged in server log:
> {code}
> 09:42:14,005 WARN [org.apache.activemq.artemis.core.message.impl.CoreMessage] (default I/O-9) Error creating String for message: : java.lang.NullPointerException
> at org.apache.activemq.artemis.core.message.impl.CoreMessage.encode(CoreMessage.java:584)
> at org.apache.activemq.artemis.core.message.impl.CoreMessage.checkEncode(CoreMessage.java:248)
> at org.apache.activemq.artemis.core.message.impl.CoreMessage.getEncodeSize(CoreMessage.java:647)
> at org.apache.activemq.artemis.core.message.impl.CoreMessage.getPersistentSize(CoreMessage.java:1157)
> at org.apache.activemq.artemis.core.message.impl.CoreMessage.toString(CoreMessage.java:1132)
> at java.lang.String.valueOf(String.java:2994) [rt.jar:1.8.0_131]
> at java.lang.StringBuilder.append(StringBuilder.java:131) [rt.jar:1.8.0_131]
> at org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionSendLargeMessage.toString(SessionSendLargeMessage.java:73)
> at java.lang.String.valueOf(String.java:2994) [rt.jar:1.8.0_131]
> at java.lang.StringBuilder.append(StringBuilder.java:131) [rt.jar:1.8.0_131]
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:368)
> at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:646)
> at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:310)
> at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:297)
> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:413)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:265)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1359)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:935)
> at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:443)
> at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:379)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.6.1.Final.jar:3.6.1.Final]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.6.1.Final.jar:3.6.1.Final]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) [xnio-nio-3.6.1.Final.jar:3.6.1.Final]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591) [xnio-nio-3.6.1.Final.jar:3.6.1.Final]
> {code}
> Currently it appears that it has not impact on functionality but NPEs are flooding server log.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-9985) NPE in server log when Artemis trace logging is enabled
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-9985?page=com.atlassian.jira.plugin.... ]
Miroslav Novak updated WFLY-9985:
---------------------------------
Description:
Artemis master (95b7438e7a7661692d5b78be944d05e254df9067) contains issue when trace logging is enabled.
If large message is sent and Artemis trace logs are enabled then following NPE is logged in server log:
{code}
09:42:14,005 WARN [org.apache.activemq.artemis.core.message.impl.CoreMessage] (default I/O-9) Error creating String for message: : java.lang.NullPointerException
at org.apache.activemq.artemis.core.message.impl.CoreMessage.encode(CoreMessage.java:584)
at org.apache.activemq.artemis.core.message.impl.CoreMessage.checkEncode(CoreMessage.java:248)
at org.apache.activemq.artemis.core.message.impl.CoreMessage.getEncodeSize(CoreMessage.java:647)
at org.apache.activemq.artemis.core.message.impl.CoreMessage.getPersistentSize(CoreMessage.java:1157)
at org.apache.activemq.artemis.core.message.impl.CoreMessage.toString(CoreMessage.java:1132)
at java.lang.String.valueOf(String.java:2994) [rt.jar:1.8.0_131]
at java.lang.StringBuilder.append(StringBuilder.java:131) [rt.jar:1.8.0_131]
at org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionSendLargeMessage.toString(SessionSendLargeMessage.java:73)
at java.lang.String.valueOf(String.java:2994) [rt.jar:1.8.0_131]
at java.lang.StringBuilder.append(StringBuilder.java:131) [rt.jar:1.8.0_131]
at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:368)
at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:646)
at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:310)
at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:297)
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:413)
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:265)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1359)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:935)
at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:443)
at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:379)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.6.1.Final.jar:3.6.1.Final]
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.6.1.Final.jar:3.6.1.Final]
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) [xnio-nio-3.6.1.Final.jar:3.6.1.Final]
at org.xnio.nio.WorkerThread.run(WorkerThread.java:591) [xnio-nio-3.6.1.Final.jar:3.6.1.Final]
{code}
Currently it appears that it has not impact on functionality but NPEs are flooding server log.
was:
Artemis master (95b7438e7a7661692d5b78be944d05e254df9067) contains issue when trace logging is enabled.
Edit: This isssue is causing OutOfMemoryError for "Too many open files".
If large message is sent and Artemis trace logs are enabled then following NPE is logged in server log:
{code}
09:42:14,005 WARN [org.apache.activemq.artemis.core.message.impl.CoreMessage] (default I/O-9) Error creating String for message: : java.lang.NullPointerException
at org.apache.activemq.artemis.core.message.impl.CoreMessage.encode(CoreMessage.java:584)
at org.apache.activemq.artemis.core.message.impl.CoreMessage.checkEncode(CoreMessage.java:248)
at org.apache.activemq.artemis.core.message.impl.CoreMessage.getEncodeSize(CoreMessage.java:647)
at org.apache.activemq.artemis.core.message.impl.CoreMessage.getPersistentSize(CoreMessage.java:1157)
at org.apache.activemq.artemis.core.message.impl.CoreMessage.toString(CoreMessage.java:1132)
at java.lang.String.valueOf(String.java:2994) [rt.jar:1.8.0_131]
at java.lang.StringBuilder.append(StringBuilder.java:131) [rt.jar:1.8.0_131]
at org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionSendLargeMessage.toString(SessionSendLargeMessage.java:73)
at java.lang.String.valueOf(String.java:2994) [rt.jar:1.8.0_131]
at java.lang.StringBuilder.append(StringBuilder.java:131) [rt.jar:1.8.0_131]
at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:368)
at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:646)
at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:310)
at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:297)
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:413)
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:265)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1359)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:935)
at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:443)
at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:379)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.6.1.Final.jar:3.6.1.Final]
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.6.1.Final.jar:3.6.1.Final]
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) [xnio-nio-3.6.1.Final.jar:3.6.1.Final]
at org.xnio.nio.WorkerThread.run(WorkerThread.java:591) [xnio-nio-3.6.1.Final.jar:3.6.1.Final]
{code}
Currently it appears that it has not impact on functionality but NPEs are flooding server log.
> NPE in server log when Artemis trace logging is enabled
> -------------------------------------------------------
>
> Key: WFLY-9985
> URL: https://issues.jboss.org/browse/WFLY-9985
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
>
> Artemis master (95b7438e7a7661692d5b78be944d05e254df9067) contains issue when trace logging is enabled.
> If large message is sent and Artemis trace logs are enabled then following NPE is logged in server log:
> {code}
> 09:42:14,005 WARN [org.apache.activemq.artemis.core.message.impl.CoreMessage] (default I/O-9) Error creating String for message: : java.lang.NullPointerException
> at org.apache.activemq.artemis.core.message.impl.CoreMessage.encode(CoreMessage.java:584)
> at org.apache.activemq.artemis.core.message.impl.CoreMessage.checkEncode(CoreMessage.java:248)
> at org.apache.activemq.artemis.core.message.impl.CoreMessage.getEncodeSize(CoreMessage.java:647)
> at org.apache.activemq.artemis.core.message.impl.CoreMessage.getPersistentSize(CoreMessage.java:1157)
> at org.apache.activemq.artemis.core.message.impl.CoreMessage.toString(CoreMessage.java:1132)
> at java.lang.String.valueOf(String.java:2994) [rt.jar:1.8.0_131]
> at java.lang.StringBuilder.append(StringBuilder.java:131) [rt.jar:1.8.0_131]
> at org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionSendLargeMessage.toString(SessionSendLargeMessage.java:73)
> at java.lang.String.valueOf(String.java:2994) [rt.jar:1.8.0_131]
> at java.lang.StringBuilder.append(StringBuilder.java:131) [rt.jar:1.8.0_131]
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:368)
> at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:646)
> at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:310)
> at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:297)
> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:413)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:265)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1359)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:935)
> at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:443)
> at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:379)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.6.1.Final.jar:3.6.1.Final]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.6.1.Final.jar:3.6.1.Final]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) [xnio-nio-3.6.1.Final.jar:3.6.1.Final]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591) [xnio-nio-3.6.1.Final.jar:3.6.1.Final]
> {code}
> Currently it appears that it has not impact on functionality but NPEs are flooding server log.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month