[JBoss JIRA] (SWSQE-3) Deploy Simple Service-Mesh Configuration
by Matt Mahoney (JIRA)
Matt Mahoney created SWSQE-3:
--------------------------------
Summary: Deploy Simple Service-Mesh Configuration
Key: SWSQE-3
URL: https://issues.jboss.org/browse/SWSQE-3
Project: Swift Sunshine QE
Issue Type: Task
Reporter: Matt Mahoney
Assignee: Michael Foley
Team Saturn Sprint-1 test requirement.
Create a simple Service Mesh which produces "real" data, which will be used for Service Graph validation.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2275) Null pointer exception when calling updateToVersion with existing data in a stateful KieSession
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2275?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-2275.
---------------------------------
Resolution: Done
Fixed
> Null pointer exception when calling updateToVersion with existing data in a stateful KieSession
> -----------------------------------------------------------------------------------------------
>
> Key: DROOLS-2275
> URL: https://issues.jboss.org/browse/DROOLS-2275
> Project: Drools
> Issue Type: Bug
> Environment: Wildfly 8.2.1, Standalone
> Reporter: Chad Poe
> Assignee: Mario Fusco
> Attachments: org.drools.test.beta-memory.zip
>
>
> This error was first discovered in a proprietary application that is running in wildfly 8.2.1. Up until now I was unable to reproduce outside of the mentioned environment. After narrowing down the exact conditions that cause the error to occur I was able to create a sample project that forces the issue to occur. Below is the stack trace:
> Caused by: java.lang.NullPointerException
> at org.drools.core.reteoo.BetaMemory.linkNode(BetaMemory.java:93)
> at org.drools.core.reteoo.BetaMemory.linkNode(BetaMemory.java:88)
> at org.drools.core.reteoo.SingleObjectSinkAdapter.staticDoLinkRiaNode(SingleObjectSinkAdapter.java:111)
> at org.drools.core.reteoo.SingleObjectSinkAdapter.doLinkRiaNode(SingleObjectSinkAdapter.java:93)
> at org.drools.core.reteoo.RiaPathMemory.doLinkRule(RiaPathMemory.java:52)
> at org.drools.core.reteoo.PathMemory.linkSegment(PathMemory.java:103)
> at org.drools.core.reteoo.SegmentMemory.notifyRuleLinkSegment(SegmentMemory.java:192)
> at org.drools.core.phreak.AddRemoveRule.addNewPaths(AddRemoveRule.java:452)
> at org.drools.core.phreak.AddRemoveRule.addRule(AddRemoveRule.java:123)
> at org.drools.core.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:189)
> at org.drools.core.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:133)
> at org.drools.core.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:110)
> at org.drools.core.impl.KnowledgeBaseImpl.internalAddRule(KnowledgeBaseImpl.java:1530)
> at org.drools.core.impl.KnowledgeBaseImpl.lambda$addRules$4(KnowledgeBaseImpl.java:1523)
> at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:734)
> at org.drools.core.impl.KnowledgeBaseImpl.addRules(KnowledgeBaseImpl.java:1521)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRete(KnowledgeBuilderImpl.java:1010)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildRules(KnowledgeBuilderImpl.java:2524)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildPackages(KnowledgeBuilderImpl.java:2450)
> at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:109)
> at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:99)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.rebuildAll(KieContainerImpl.java:473)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateKBase(KieContainerImpl.java:309)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.lambda$update$0(KieContainerImpl.java:260)
> at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:734)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:260)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:199)
> at org.drools.test.KieRuntimeManager.buildOnKfs(KieRuntimeManager.java:202)
> at org.drools.test.KieRuntimeManager.loadRule(KieRuntimeManager.java:147)
> at org.drools.test.DroolsReasonerContainer.loadRule(DroolsReasonerContainer.java:22)
> at org.drools.test.App.main(App.java:22)
> ... 6 more
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2275) Null pointer exception when calling updateToVersion with existing data in a stateful KieSession
by Chad Poe (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2275?page=com.atlassian.jira.plugi... ]
Chad Poe commented on DROOLS-2275:
----------------------------------
Issue is resolved in version 7.6.0.Final
> Null pointer exception when calling updateToVersion with existing data in a stateful KieSession
> -----------------------------------------------------------------------------------------------
>
> Key: DROOLS-2275
> URL: https://issues.jboss.org/browse/DROOLS-2275
> Project: Drools
> Issue Type: Bug
> Environment: Wildfly 8.2.1, Standalone
> Reporter: Chad Poe
> Assignee: Mario Fusco
> Attachments: org.drools.test.beta-memory.zip
>
>
> This error was first discovered in a proprietary application that is running in wildfly 8.2.1. Up until now I was unable to reproduce outside of the mentioned environment. After narrowing down the exact conditions that cause the error to occur I was able to create a sample project that forces the issue to occur. Below is the stack trace:
> Caused by: java.lang.NullPointerException
> at org.drools.core.reteoo.BetaMemory.linkNode(BetaMemory.java:93)
> at org.drools.core.reteoo.BetaMemory.linkNode(BetaMemory.java:88)
> at org.drools.core.reteoo.SingleObjectSinkAdapter.staticDoLinkRiaNode(SingleObjectSinkAdapter.java:111)
> at org.drools.core.reteoo.SingleObjectSinkAdapter.doLinkRiaNode(SingleObjectSinkAdapter.java:93)
> at org.drools.core.reteoo.RiaPathMemory.doLinkRule(RiaPathMemory.java:52)
> at org.drools.core.reteoo.PathMemory.linkSegment(PathMemory.java:103)
> at org.drools.core.reteoo.SegmentMemory.notifyRuleLinkSegment(SegmentMemory.java:192)
> at org.drools.core.phreak.AddRemoveRule.addNewPaths(AddRemoveRule.java:452)
> at org.drools.core.phreak.AddRemoveRule.addRule(AddRemoveRule.java:123)
> at org.drools.core.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:189)
> at org.drools.core.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:133)
> at org.drools.core.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:110)
> at org.drools.core.impl.KnowledgeBaseImpl.internalAddRule(KnowledgeBaseImpl.java:1530)
> at org.drools.core.impl.KnowledgeBaseImpl.lambda$addRules$4(KnowledgeBaseImpl.java:1523)
> at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:734)
> at org.drools.core.impl.KnowledgeBaseImpl.addRules(KnowledgeBaseImpl.java:1521)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRete(KnowledgeBuilderImpl.java:1010)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildRules(KnowledgeBuilderImpl.java:2524)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildPackages(KnowledgeBuilderImpl.java:2450)
> at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:109)
> at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:99)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.rebuildAll(KieContainerImpl.java:473)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateKBase(KieContainerImpl.java:309)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.lambda$update$0(KieContainerImpl.java:260)
> at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:734)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:260)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:199)
> at org.drools.test.KieRuntimeManager.buildOnKfs(KieRuntimeManager.java:202)
> at org.drools.test.KieRuntimeManager.loadRule(KieRuntimeManager.java:147)
> at org.drools.test.DroolsReasonerContainer.loadRule(DroolsReasonerContainer.java:22)
> at org.drools.test.App.main(App.java:22)
> ... 6 more
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3608) There is no way to define core pool size for io subsystem
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3608?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3608:
-------------------------------------
Issue Type: Feature Request (was: Enhancement)
Changing to Feature Request. New user configurable behavior is a feature.
> There is no way to define core pool size for io subsystem
> ---------------------------------------------------------
>
> Key: WFCORE-3608
> URL: https://issues.jboss.org/browse/WFCORE-3608
> Project: WildFly Core
> Issue Type: Feature Request
> Components: IO
> Affects Versions: 4.0.0.Alpha10
> Reporter: Richard Janík
> Assignee: Tomaz Cerar
>
> There is no way how to define core pool size for underlying thread pool in IO subsystem's worker ({{/subsystem=io/worker=*}}). It is only possible to set task-max-threads which defines max pool size for underlying thread pool.
> Suggestion for improvement: Add new attribute to set core pool size to IO subsystem worker
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (JGRP-2250) Stuck Threads - BLOCKED infinitely on - JGroups - org.jgroups.protocols.FlowControl$Credit.decrementIfEnoughCredits(FlowControl.java:567)
by Rohit Singh (JIRA)
[ https://issues.jboss.org/browse/JGRP-2250?page=com.atlassian.jira.plugin.... ]
Rohit Singh commented on JGRP-2250:
-----------------------------------
[~belaban] Please suggest, whether JGROUPS 3.5 or 3.6 is compatible with INFINISPAN 6.0.2.
> Stuck Threads - BLOCKED infinitely on - JGroups - org.jgroups.protocols.FlowControl$Credit.decrementIfEnoughCredits(FlowControl.java:567)
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2250
> URL: https://issues.jboss.org/browse/JGRP-2250
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.1
> Environment: Oracle Linux - Exalogic/Exadata stack
> AS: Weblogic 12.1.3
> DB: Oracle 12.1.0.2
> Reporter: Rohit Singh
> Assignee: Bela Ban
> Priority: Blocker
> Labels: Infinispan, JGroups
>
> Ours is a J2EE application (clustered across 4 nodes) internally using *{color:red}Infinispan Cache (Ver 6.0.2) with JGroups (Ver 3.4.1){color}* as transport layer of our cache.
> Application had been running perfectly fine, but suddenly on one node, one cache-put got stuck with below stack trace. *(Cause being blocked on org.jgroups.protocols.FlowControl$Credit.decrementIfEnoughCredits(FlowControl.java:567)).*
> Now all further puts are getting stuck - blocked - on the same line on the same node. Other nodes are working fine in this respect.
> Currently, while raising the issue, the threads are still in stuck state. And the first stuck thread is stuck from last 27 hours.
> Stack Trace:
> "[STUCK] ExecuteThread: '37' for queue: 'weblogic.kernel.Default (self-tuning)'" #107862 daemon prio=1 os_prio=0 tid=0x00007f5964373000 nid=0x75a9 in Object.wait() [0x00007f57d596b000]
> java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at *{color:red}org.jgroups.protocols.FlowControl$Credit.decrementIfEnoughCredits(FlowControl.java:567){color}*
> - locked <0x00007f5e64893168> (a org.jgroups.protocols.FlowControl$Credit)
> at org.jgroups.protocols.UFC.handleDownMessage(UFC.java:121)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:330)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:340)
> at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1024)
> at org.jgroups.JChannel.down(JChannel.java:760)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:683)
> at org.jgroups.blocks.RequestCorrelator.sendUnicastRequest(RequestCorrelator.java:202)
> at org.jgroups.blocks.UnicastRequest.sendRequest(UnicastRequest.java:43)
> at org.jgroups.blocks.Request.execute(Request.java:83)
> at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:399)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:353)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:521)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:281)
> at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.handleNonTxWriteCommand(BaseDistributionInterceptor.java:233)
> at org.infinispan.interceptors.distribution.NonTxDistributionInterceptor.visitPutKeyValueCommand(NonTxDistributionInterceptor.java:72)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:321)
> at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:402)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitPutKeyValueCommand(EntryWrappingInterceptor.java:164)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutKeyValueCommand(AbstractLockingInterceptor.java:68)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:219)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:141)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
> at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1306)
> at org.infinispan.CacheImpl.putInternal(CacheImpl.java:878)
> at org.infinispan.CacheImpl.put(CacheImpl.java:870)
> at org.infinispan.DecoratedCache.put(DecoratedCache.java:401)
> at com.nucleus.finnone.pro.cache.common.NeutrinoCache.put(NeutrinoCache.java:18)
> at com.nucleus.config.persisted.service.ConfigurationServiceImpl.getConfigurationGroupFor(ConfigurationServiceImpl.java:478)
> *Note: Seems related to below-*
> https://issues.jboss.org/browse/JGRP-1675
> https://issues.jboss.org/browse/ISPN-3645
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9829) EJB JNDI naming discrepancy between stdout and doc
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-9829?page=com.atlassian.jira.plugin.... ]
David Lloyd resolved WFLY-9829.
-------------------------------
Resolution: Rejected
The documentation names you refer to are the client-side names which are not covered in the EJB specification (which does not deal with remote JNDI). The names in the log are the server-side local names which can be looked up/injected using {{@Resource}} or similar local JNDI mechanisms. So there is no discrepancy here.
> EJB JNDI naming discrepancy between stdout and doc
> --------------------------------------------------
>
> Key: WFLY-9829
> URL: https://issues.jboss.org/browse/WFLY-9829
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 12.0.0.Alpha1
> Reporter: tommaso borgato
> Priority: Minor
>
> On documentation https://docs.jboss.org/author/display/WFLY/EJB+invocations+from+a+remote+... the EJB JNDI name starts with ejb:
> {code}
> ejb:/jboss-as-ejb-remote-app//CalculatorBean!org.jboss.as.quickstarts.ejb.remote.stateless.RemoteCalculator
> {code}
> When the server is started (./bin/standalone.sh --server-config=standalone-ha.xml) and the EJB application is deployed, the logs say:
> {code:tile stdout}
> 15:20:16,327 INFO [org.jboss.as.ejb3.deployment] (MSC service thread 1-6) WFLYEJB0473: JNDI bindings for session bean named 'CalculatorBean' in deployment unit 'deployment "ejb-server.war"' are as follows:
> java:global/jboss-as-ejb-remote-app/CalculatorBean!com.redhat.samples.ejb.stateless.LocalCalculator
> java:app/jboss-as-ejb-remote-app/CalculatorBean!com.redhat.samples.ejb.stateless.LocalCalculator
> java:module/CalculatorBean!com.redhat.samples.ejb.stateless.LocalCalculator
> java:global/jboss-as-ejb-remote-app/CalculatorBean!com.redhat.samples.ejb.stateless.RemoteCalculator
> java:app/jboss-as-ejb-remote-app/CalculatorBean!com.redhat.samples.ejb.stateless.RemoteCalculator
> java:module/CalculatorBean!com.redhat.samples.ejb.stateless.RemoteCalculator
> java:jboss/exported/jboss-as-ejb-remote-app/CalculatorBean!com.redhat.samples.ejb.stateless.RemoteCalculator
> {code}
> None of them matches the JNDI name mentioned in the documentation.
> The JNDI name in the documentation works correctly.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months