[JBoss JIRA] (DROOLS-1386) NPE in org.drools.core.common.TupleSetsImpl.setNextTuple
by Arkady Syamtomov (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1386?page=com.atlassian.jira.plugi... ]
Arkady Syamtomov updated DROOLS-1386:
-------------------------------------
Affects Version/s: 7.0.0.Beta4
> NPE in org.drools.core.common.TupleSetsImpl.setNextTuple
> --------------------------------------------------------
>
> Key: DROOLS-1386
> URL: https://issues.jboss.org/browse/DROOLS-1386
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.5.0.Final, 7.0.0.Beta4
> Reporter: Arkady Syamtomov
> Assignee: Edson Tirelli
> Priority: Critical
>
> In our integration tests which were perfectly running with drools 6.3.0.Final, now we have failures with the following exception during the rules evaluation:
> java.lang.NullPointerException: null
> at org.drools.core.common.TupleSetsImpl.setNextTuple(TupleSetsImpl.java:349) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.common.TupleSetsImpl.removeUpdate(TupleSetsImpl.java:205) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.common.TupleSetsImpl.addDelete(TupleSetsImpl.java:110) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.reteoo.QueryElementNode$UnificationNodeViewChangedEventListener.rowRemoved(QueryElementNode.java:444) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.PhreakQueryTerminalNode.doLeftDeletes(PhreakQueryTerminalNode.java:154) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.PhreakQueryTerminalNode.doNode(PhreakQueryTerminalNode.java:46) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:282) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleNetworkEvaluator.evalStackEntry(RuleNetworkEvaluator.java:198) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:141) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:94) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:970) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1312) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1251) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1364) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1355) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1346) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:109) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:36) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:137) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:51) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:254) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (DROOLS-1386) NPE in org.drools.core.common.TupleSetsImpl.setNextTuple
by Arkady Syamtomov (JIRA)
Arkady Syamtomov created DROOLS-1386:
----------------------------------------
Summary: NPE in org.drools.core.common.TupleSetsImpl.setNextTuple
Key: DROOLS-1386
URL: https://issues.jboss.org/browse/DROOLS-1386
Project: Drools
Issue Type: Bug
Affects Versions: 6.5.0.Final
Reporter: Arkady Syamtomov
Assignee: Edson Tirelli
Priority: Critical
In our integration tests which were perfectly running with drools 6.3.0.Final, now we have failures with the following exception during the rules evaluation:
java.lang.NullPointerException: null
at org.drools.core.common.TupleSetsImpl.setNextTuple(TupleSetsImpl.java:349) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
at org.drools.core.common.TupleSetsImpl.removeUpdate(TupleSetsImpl.java:205) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
at org.drools.core.common.TupleSetsImpl.addDelete(TupleSetsImpl.java:110) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
at org.drools.core.reteoo.QueryElementNode$UnificationNodeViewChangedEventListener.rowRemoved(QueryElementNode.java:444) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
at org.drools.core.phreak.PhreakQueryTerminalNode.doLeftDeletes(PhreakQueryTerminalNode.java:154) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
at org.drools.core.phreak.PhreakQueryTerminalNode.doNode(PhreakQueryTerminalNode.java:46) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:282) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
at org.drools.core.phreak.RuleNetworkEvaluator.evalStackEntry(RuleNetworkEvaluator.java:198) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:141) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:94) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:970) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1312) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1251) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1364) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1355) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1346) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:109) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:36) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:137) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:51) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:254) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-7838) EJBClient user transaction is not propagated properly to the receiver
by Mate Varga (JIRA)
[ https://issues.jboss.org/browse/WFLY-7838?page=com.atlassian.jira.plugin.... ]
Mate Varga closed WFLY-7838.
----------------------------
Resolution: Won't Do
I have misunderstood how single-VM transaction management works.
> EJBClient user transaction is not propagated properly to the receiver
> ---------------------------------------------------------------------
>
> Key: WFLY-7838
> URL: https://issues.jboss.org/browse/WFLY-7838
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Environment: not relevant
> Reporter: Mate Varga
> Attachments: wf-txn-fix.patch
>
>
> Setup:
> - WF 10.1.0.Final
> - two deployments, one EAR and one WAR
> - EAR exposes EJB methods (SFSBs and SLSBs)
> - WAR uses wildfly-ejb-client-bom 10.1.0 to call remote EJBs
> Problem:
> The client uses bean-managed transactions. The problem is that transactions are not propagated properly to the EJB side, therefore instead of using the existing BMT, container will use CMT. The flow in detail:
> - LocalEjbReceiver#processInvocation receives an EJBClientInvocationContext
> - EJBClientInvocationContext contains contextData, which was populated by the client. contextData correctly contains the appropriate UserTransactionId
> - processInvocation extracts the transaction Id and puts it into the interceptorContext's context data (NOT into privateData)
> - later in the interceptor chain, control reaches EJBRemoteTransactionPropagatingInterceptor, which is responsible for checking whether there is an user transaction present.
> - it tries to fetch the transaction ID from the interceptorContext's privateData (NOT from contextData)
> - it does not find the userTransaction there
> It looks to me that either EJBRemoteTransactionPropagatingInterceptor should look look for the userTransaction in contextData, or LocalEjbReceiver should put the userTransaction ID into privateData.
> I've attached a patch that fixes the problem for me.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (DROOLS-1385) Access the rule from outsidefolder
by Mylammal AV (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1385?page=com.atlassian.jira.plugi... ]
Mylammal AV commented on DROOLS-1385:
-------------------------------------
Friends,Please comment your ideas
> Access the rule from outsidefolder
> ----------------------------------
>
> Key: DROOLS-1385
> URL: https://issues.jboss.org/browse/DROOLS-1385
> Project: Drools
> Issue Type: Feature Request
> Reporter: Mylammal AV
> Assignee: Edson Tirelli
> Priority: Blocker
>
> I am using Maven.And invoking rules we are using drools.If the rules.drl is present inside the project folder.. it is automatically searched and found the expected value.But my requirement is, I need to access rule - outside the class Folder. I thought we need to outside folder path in kmodule.xml,instead of giving package="*". But it is throwing " No files found for KieBase CrossPlan1, searching folder inside the project ".Is it possible to do this..
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (DROOLS-1385) Access the rule from outsidefolder
by Mylammal AV (JIRA)
Mylammal AV created DROOLS-1385:
-----------------------------------
Summary: Access the rule from outsidefolder
Key: DROOLS-1385
URL: https://issues.jboss.org/browse/DROOLS-1385
Project: Drools
Issue Type: Feature Request
Reporter: Mylammal AV
Assignee: Edson Tirelli
Priority: Blocker
I am using Maven.And invoking rules we are using drools.If the rules.drl is present inside the project folder.. it is automatically searched and found the expected value.But my requirement is, I need to access rule - outside the class Folder. I thought we need to outside folder path in kmodule.xml,instead of giving package="*". But it is throwing " No files found for KieBase CrossPlan1, searching folder inside the project ".Is it possible to do this..
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-7840) elytron: authentication-context validation errors
by Claudio Miranda (JIRA)
Claudio Miranda created WFLY-7840:
-------------------------------------
Summary: elytron: authentication-context validation errors
Key: WFLY-7840
URL: https://issues.jboss.org/browse/WFLY-7840
Project: WildFly
Issue Type: Bug
Reporter: Claudio Miranda
Assignee: Jason Greene
elytron resource authentication-context has attribute match-rules marked as required=false and nillable=true, but fail to add an authentication-context with no match-rules attribute
{code}
/profile=default/subsystem=elytron/authentication-context=test123:add
{
"outcome" => "failed",
"failure-description" => {"domain-failure-description" => "WFLYCTL0155: 'match-rules' may not be null"},
"rolled-back" => true
}
{code}
Resource description snippet
{code}
"match-rules" => {
"type" => LIST,
"description" => "The match-rules for this authentication context.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-7823) AMQP remote client failed to connect
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7823?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-7823:
------------------------------------
Component/s: JMS
(was: Application Client)
Assignee: Jeff Mesnil (was: Stuart Douglas)
> AMQP remote client failed to connect
> ------------------------------------
>
> Key: WFLY-7823
> URL: https://issues.jboss.org/browse/WFLY-7823
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.1.0.Final
> Environment: OS: Windows10 x64,
> Java: 1.8.0_102
> WildFly 10.1 Final (the same also on 11 night build) - standalone
> client: AmqpNetLite, v.1.2.2.0, Proton 0.14
> Reporter: Oleg Kozakevych
> Assignee: Jeff Mesnil
> Labels: amqp, artemis, wildfly
> Attachments: server.log, server_debug.log, standalone.xml
>
>
> AMQP remote client cannot connect to Artemis broker while it is embedded into WildFly.
> When client connects, it doesn't receive anything from the server. I turned on frame logging in AmqpNetLite and it show like following:
> {noformat}
> [03:58:25.015] SEND AMQP 3 1 0 0
> [03:58:25.062] SEND sasl-init(mechanism:PLAIN,initial-response:006775657374006775657374,hostname:127.0.0.1)
> {noformat}
> Server just does nothing, any traces, any response to client.
> I made changes as suggested by Justin in corresponding thread (https://developer.jboss.org/thread/269424)
> {noformat}
> The Artemis AMQP protocol implementation module (at <WFLY_HOME>/modules/system/layers/base/org/apache/activemq/artemis/protocol/amqp/main) needs a dependency on Netty in its module.xml (e.g. <module name="io.netty"/>).
> Artemis requires Proton-J 0.10 and Wildfly ships with 0.8 so you can copy proton-j-0.10.jar and proton-jms-0.10.jar from Artemis' /lib directory to <WFLY_HOME>/modules/system/layers/base/org/apache/qpid/proton/main and update the module.xml accordingly.
> {noformat}
> Then I turned debug traces and see following exception:
> {noformat}
> 13:01:00,713 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) java.nio.ReadOnlyBufferException
> 13:01:00,716 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at java.nio.ByteBuffer.array(ByteBuffer.java:996)
> 13:01:00,720 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.buffer.UnsafeByteBufUtil.setBytes(UnsafeByteBufUtil.java:368)
> 13:01:00,730 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.buffer.PooledUnsafeDirectByteBuf.setBytes(PooledUnsafeDirectByteBuf.java:205)
> 13:01:00,734 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:877)
> 13:01:00,745 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.outputBuffer(ProtonHandlerImpl.java:226)
> 13:01:00,749 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.context.AbstractConnectionContext.flushBytes(AbstractConnectionContext.java:145)
> 13:01:00,760 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.context.AbstractConnectionContext$LocalListener.onTransport(AbstractConnectionContext.java:160)
> 13:01:00,766 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.dispatch(ProtonHandlerImpl.java:349)
> 13:01:00,770 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.flush(ProtonHandlerImpl.java:257)
> 13:01:00,783 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.inputBuffer(ProtonHandlerImpl.java:158)
> 13:01:00,789 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.context.AbstractConnectionContext.inputBuffer(AbstractConnectionContext.java:81)
> 13:01:00,800 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.protocol.proton.ActiveMQProtonRemotingConnection.bufferReceived(ActiveMQProtonRemotingConnection.java:127)
> 13:01:00,807 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:619)
> 13:01:00,814 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68)
> 13:01:00,820 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318)
> 13:01:00,832 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304)
> 13:01:00,839 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.handler.codec.ByteToMessageDecoder.handlerRemoved(ByteToMessageDecoder.java:216)
> 13:01:00,849 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.callHandlerRemoved0(DefaultChannelPipeline.java:527)
> 13:01:00,855 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.callHandlerRemoved(DefaultChannelPipeline.java:521)
> 13:01:00,866 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.remove0(DefaultChannelPipeline.java:351)
> 13:01:00,871 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.remove(DefaultChannelPipeline.java:322)
> 13:01:00,882 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.remove(DefaultChannelPipeline.java:299)
> 13:01:00,887 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.protocol.ProtocolHandler$ProtocolDecoder.decode(ProtocolHandler.java:175)
> 13:01:00,902 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:360)
> 13:01:00,913 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:244)
> 13:01:00,920 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.protocol.ProtocolHandler$ProtocolDecoder.channelRead(ProtocolHandler.java:118)
> 13:01:00,931 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318)
> 13:01:00,937 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304)
> 13:01:00,949 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846)
> 13:01:00,954 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131)
> 13:01:00,965 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511)
> 13:01:00,969 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
> 13:01:00,981 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382)
> 13:01:00,986 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354)
> 13:01:00,998 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
> 13:01:01,003 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Configuration and server logs are attached.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-4510) "IJ000451: The connection manager is shutdown" after disabling/enabling a datasource
by Manoj Dixit (JIRA)
[ https://issues.jboss.org/browse/WFLY-4510?page=com.atlassian.jira.plugin.... ]
Manoj Dixit commented on WFLY-4510:
-----------------------------------
We are facing same issues in Jboss EAP 6.4. Please let me know the solution.
> "IJ000451: The connection manager is shutdown" after disabling/enabling a datasource
> ------------------------------------------------------------------------------------
>
> Key: WFLY-4510
> URL: https://issues.jboss.org/browse/WFLY-4510
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Environment: Windows 8.1 x64, JDK 1.8.0_20, Wildfly 8.2.0.Final
> Reporter: Renann Prado
> Assignee: James Perkins
> Fix For: 9.0.0.Beta1
>
>
> The below exception is thrown after the DataSource is disabled/enabled.
> I read that in Wildfly 9 onwards disabling/enabling a DataSource is deprecated, so *maybe* this problem won`t happen in next Wildfly version.
> {noformat}
> 2015-04-12 16:48:07,691 ERROR [io.undertow.request] (default task-8) UT005023: Exception handling request to /XXXXXe-web/NewServlet: javax.batch.operations.BatchRuntimeException: JBERET000622: Failed to obtain connection from org.jboss.jca.adapters.jdbc.WrapperDataSource@da89438, java:jboss/dasources/MySQL
> at org.jberet.repository.JdbcRepository.getConnection(JdbcRepository.java:802) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.repository.JdbcRepository.insertJobInstance(JdbcRepository.java:264) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.repository.AbstractRepository.createJobInstance(AbstractRepository.java:91) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.operations.JobOperatorImpl$1.invoke(JobOperatorImpl.java:82) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.operations.JobOperatorImpl$1.invoke(JobOperatorImpl.java:79) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.operations.JobOperatorImpl.invokeTransaction(JobOperatorImpl.java:295) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.operations.JobOperatorImpl.start(JobOperatorImpl.java:79) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at com.test.NewServlet.processRequest(NewServlet.java:64) [classes:]
> at com.test.NewServlet.doGet(NewServlet.java:95) [classes:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11]
> Caused by: java.sql.SQLException: javax.resource.ResourceException: IJ000451: The connection manager is shutdown: java:jboss/dasources/MySQL
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:154)
> at org.jberet.repository.JdbcRepository.getConnection(JdbcRepository.java:800) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> ... 36 more
> Caused by: javax.resource.ResourceException: IJ000451: The connection manager is shutdown: java:jboss/dasources/MySQL
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:371)
> at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:421)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:515)
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:146)
> ... 37 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (JGRP-2126) Table.removeMany() creates unneeded temporary list
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2126?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2126:
--------------------------------
Added Table.removeMany():
{code:java}
<R> R removeMany(final AtomicBoolean processing, boolean nullify, int max_results, Predicate<T> filter, Supplier<R> result_creator, BiConsumer<R,T> accumulator, Predicate<R> result_validator)
{code}, which accepts a result creator, accumulator and validator (similar to Stream.collect()).
Both NAKACK2 and UNICAST3 create a MessageBatch and use it to move messages from the table to the batch, avoiding a temporary list creation.
> Table.removeMany() creates unneeded temporary list
> --------------------------------------------------
>
> Key: JGRP-2126
> URL: https://issues.jboss.org/browse/JGRP-2126
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Labels: CR3
> Fix For: 4.0
>
>
> When a thread acquires the CAS in NAKACK2 or UNICAST3 to deliver messages, it calls Table.removeMany() which removes messages that satisfy a condition and return them as a list. Next, a MessageBatch is created off of that list and passed up.
> The creation of the temp list is unnecessary; instead create a properly sized MessageBatch and make Table.removeMany() add the messages directly into the batch.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months