[JBoss JIRA] (JGRP-2227) Use of AUTH does not result in a SecurityException, but instead nodes create separate clusters with the same name
by Robert Cernak (JIRA)
[ https://issues.jboss.org/browse/JGRP-2227?page=com.atlassian.jira.plugin.... ]
Robert Cernak reopened JGRP-2227:
---------------------------------
> Use of AUTH does not result in a SecurityException, but instead nodes create separate clusters with the same name
> -----------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2227
> URL: https://issues.jboss.org/browse/JGRP-2227
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.6
> Reporter: Robert Cernak
> Assignee: Bela Ban
> Fix For: 4.0.8
>
> Attachments: jgroupsLogs.zip
>
>
> I implemented method org.jgroups.auth.AuthToken#authenticate(AuthToken token, Message msg) in my class and its body contained only one line: return false;
> In this way authentication should be false and I should get SecurityException.
> When I started joining of nodes together to form a cluster, instead of getting SecurityException, nodes formed 2 different clusters with the same name.
> I am sure method was evaluated, since I tried to run it also with breakpoint, which was triggered during joining process.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (JGRP-2227) Use of AUTH does not result in a SecurityException, but instead nodes create separate clusters with the same name
by Robert Cernak (JIRA)
[ https://issues.jboss.org/browse/JGRP-2227?page=com.atlassian.jira.plugin.... ]
Robert Cernak updated JGRP-2227:
--------------------------------
Attachment: jgroupsLogs.zip
> Use of AUTH does not result in a SecurityException, but instead nodes create separate clusters with the same name
> -----------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2227
> URL: https://issues.jboss.org/browse/JGRP-2227
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.6
> Reporter: Robert Cernak
> Assignee: Bela Ban
> Fix For: 4.0.8
>
> Attachments: jgroupsLogs.zip
>
>
> I implemented method org.jgroups.auth.AuthToken#authenticate(AuthToken token, Message msg) in my class and its body contained only one line: return false;
> In this way authentication should be false and I should get SecurityException.
> When I started joining of nodes together to form a cluster, instead of getting SecurityException, nodes formed 2 different clusters with the same name.
> I am sure method was evaluated, since I tried to run it also with breakpoint, which was triggered during joining process.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (JGRP-2227) Use of AUTH does not result in a SecurityException, but instead nodes create separate clusters with the same name
by Robert Cernak (JIRA)
[ https://issues.jboss.org/browse/JGRP-2227?page=com.atlassian.jira.plugin.... ]
Robert Cernak commented on JGRP-2227:
-------------------------------------
issue still occurs with 4.0.8 version.
Steps to reproduce: Join 2 nodes to form cluster.
ER: When second node is joining to the cluster, and during join process node fails to authenticate, SecurityException should be thrown.
AR: 2 nodes form 2 separate clustres with the same name. No SecurityException was thrown
See attached jgroups logs [^jgroupsLogs.zip]
> Use of AUTH does not result in a SecurityException, but instead nodes create separate clusters with the same name
> -----------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2227
> URL: https://issues.jboss.org/browse/JGRP-2227
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.6
> Reporter: Robert Cernak
> Assignee: Bela Ban
> Fix For: 4.0.8
>
> Attachments: jgroupsLogs.zip
>
>
> I implemented method org.jgroups.auth.AuthToken#authenticate(AuthToken token, Message msg) in my class and its body contained only one line: return false;
> In this way authentication should be false and I should get SecurityException.
> When I started joining of nodes together to form a cluster, instead of getting SecurityException, nodes formed 2 different clusters with the same name.
> I am sure method was evaluated, since I tried to run it also with breakpoint, which was triggered during joining process.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (DROOLS-1795) [Guided Decision Table] Invalid error message when renaming bound variable name in conditional BRL column.
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1795?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-1795:
--------------------------------
Tester: Jozef Marko
> [Guided Decision Table] Invalid error message when renaming bound variable name in conditional BRL column.
> ----------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1795
> URL: https://issues.jboss.org/browse/DROOLS-1795
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Affects Versions: 7.0.0.Final
> Reporter: Mark Coble
> Assignee: Mark Coble
> Priority: Minor
> Fix For: 7.0.0.Final
>
> Attachments: guvnor-3507.png
>
>
> If a condition BRL column is added to a DT with bound variables that are used in an action column and that variable name is subsequently changed, the attached error message occurs when updating the action column with the new variable name. In the attached message the original variable name is 'app'. Hitting 'ok' returns you to the DT which has actually refactored the DT with the new variable name and validation is successful.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (DROOLS-1892) [Guided Decision Table] Stabilize and update tests that run test scenario
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1892?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-1892:
--------------------------------
Description:
Some decision table tests verify the constructed decision table by running the asset test scenario. Three of these tests are not stable and kind of obsolete. They need to be stabilized and updated.
Acceptance criteria:
The followings [tests|https://github.com/jboss-integration/bxms-qe-tests/tree/master/test...] pass on jenkins:
- org.jboss.qa.brms.authoring.dt.feature.WebDTWIDTest#testWID
- --org.jboss.qa.brms.authoring.dt.feature.DTTest#testDTExt--
- --org.jboss.qa.brms.authoring.dt.bugfix.WebDTWizardBugfixTest#testRowNumbers--
was:
Some decision table tests verify the constructed decision table by running the asset test scenario. Three of these tests are not stable and kind of obsolete. They need to be stabilized and updated.
Acceptance criteria:
The followings [tests|https://github.com/jboss-integration/bxms-qe-tests/tree/master/test...] pass on jenkins:
- org.jboss.qa.brms.authoring.dt.feature.WebDTWIDTest#testWID
- org.jboss.qa.brms.authoring.dt.feature.DTTest#testDTExt
- org.jboss.qa.brms.authoring.dt.bugfix.WebDTWizardBugfixTest#testRowNumbers
> [Guided Decision Table] Stabilize and update tests that run test scenario
> -------------------------------------------------------------------------
>
> Key: DROOLS-1892
> URL: https://issues.jboss.org/browse/DROOLS-1892
> Project: Drools
> Issue Type: Task
> Components: Guided Decision Table Editor
> Affects Versions: 7.1.0.Final
> Reporter: Jozef Marko
> Assignee: Jozef Marko
>
> Some decision table tests verify the constructed decision table by running the asset test scenario. Three of these tests are not stable and kind of obsolete. They need to be stabilized and updated.
> Acceptance criteria:
> The followings [tests|https://github.com/jboss-integration/bxms-qe-tests/tree/master/test...] pass on jenkins:
> - org.jboss.qa.brms.authoring.dt.feature.WebDTWIDTest#testWID
> - --org.jboss.qa.brms.authoring.dt.feature.DTTest#testDTExt--
> - --org.jboss.qa.brms.authoring.dt.bugfix.WebDTWizardBugfixTest#testRowNumbers--
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[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.
Edit: This isssue is causing
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.
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.
> Edit: This isssue is causing
> 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, 3 months
[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.
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.
was:
Artemis master (95b7438e7a7661692d5b78be944d05e254df9067) contains issue when trace logging is enabled.
Edit: This isssue is causing
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.
> 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.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months