[JBoss JIRA] (WFLY-5252) Fix MDB20TestCase
by Chen Maoqian (JIRA)
[ https://issues.jboss.org/browse/WFLY-5252?page=com.atlassian.jira.plugin.... ]
Chen Maoqian edited comment on WFLY-5252 at 4/14/16 9:39 PM:
-------------------------------------------------------------
Hi,I have run the test in last night with current wildfly master, but I can not find the error any more. In the recent pull request on GitHub, the failure also does not happen again. I will close this issue for now, If anyone sees this issue again, please reopen with a sever.log
Thanks.
was (Author: bayern39):
Hi,i have run the project on one night with the version 10.1.0.Final,but i can not find the error once.And in the github,the recently pull request also have not happen this error.so i think the issue has been fixed,if you can reproduce this problem ,please upload the attachment about the log,if so i will reopen this problem.Thanks for your attention!
> Fix MDB20TestCase
> -----------------
>
> Key: WFLY-5252
> URL: https://issues.jboss.org/browse/WFLY-5252
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 10.0.0.Beta2
> Reporter: Jeff Mesnil
> Assignee: Chen Maoqian
> Priority: Minor
> Fix For: 10.1.0.Final
>
>
> The MDB20TestCase is failing often on our test suite with the error:
> {noformat}
> java.lang.AssertionError: Reply message was null on reply queue: ActiveMQQueue[ejb2x/replyQueueB]
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:621)
> at org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20TopicTestCase.testEjb20TopicMDBs(MDB20TopicTestCase.java:118)
> {noformat}
> From the logs, only 1 of the MDB receives the message sent to the topic.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-5252) Fix MDB20TestCase
by Chen Maoqian (JIRA)
[ https://issues.jboss.org/browse/WFLY-5252?page=com.atlassian.jira.plugin.... ]
Chen Maoqian resolved WFLY-5252.
--------------------------------
Resolution: Cannot Reproduce
Hi,i have run the project on one night with the version 10.1.0.Final,but i can not find the error once.And in the github,the recently pull request also have not happen this error.so i think the issue has been fixed,if you can reproduce this problem ,please upload the attachment about the log,if so i will reopen this problem.Thanks for your attention!
> Fix MDB20TestCase
> -----------------
>
> Key: WFLY-5252
> URL: https://issues.jboss.org/browse/WFLY-5252
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 10.0.0.Beta2
> Reporter: Jeff Mesnil
> Assignee: Chen Maoqian
> Priority: Minor
> Fix For: 10.1.0.Final
>
>
> The MDB20TestCase is failing often on our test suite with the error:
> {noformat}
> java.lang.AssertionError: Reply message was null on reply queue: ActiveMQQueue[ejb2x/replyQueueB]
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:621)
> at org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20TopicTestCase.testEjb20TopicMDBs(MDB20TopicTestCase.java:118)
> {noformat}
> From the logs, only 1 of the MDB receives the message sent to the topic.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-5252) Fix MDB20TestCase
by Chen Maoqian (JIRA)
[ https://issues.jboss.org/browse/WFLY-5252?page=com.atlassian.jira.plugin.... ]
Chen Maoqian reassigned WFLY-5252:
----------------------------------
Assignee: Chen Maoqian
> Fix MDB20TestCase
> -----------------
>
> Key: WFLY-5252
> URL: https://issues.jboss.org/browse/WFLY-5252
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 10.0.0.Beta2
> Reporter: Jeff Mesnil
> Assignee: Chen Maoqian
> Priority: Minor
> Fix For: 10.1.0.Final
>
>
> The MDB20TestCase is failing often on our test suite with the error:
> {noformat}
> java.lang.AssertionError: Reply message was null on reply queue: ActiveMQQueue[ejb2x/replyQueueB]
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:621)
> at org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20TopicTestCase.testEjb20TopicMDBs(MDB20TopicTestCase.java:118)
> {noformat}
> From the logs, only 1 of the MDB receives the message sent to the topic.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1124) Unble to provision errors when creating KieContainor from KieServices in the Vert.X verticle
by xiaodong wang (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1124?page=com.atlassian.jira.plugi... ]
xiaodong wang commented on DROOLS-1124:
---------------------------------------
If I just create KieContainor from local repository in a static main(), it works fine.
I would assume my local repository is good.
> Unble to provision errors when creating KieContainor from KieServices in the Vert.X verticle
> --------------------------------------------------------------------------------------------
>
> Key: DROOLS-1124
> URL: https://issues.jboss.org/browse/DROOLS-1124
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.4.0.CR2
> Environment: OS: MacOX and 10.10.5
> Vert.X: 3.2.1
> Reporter: xiaodong wang
> Assignee: Edson Tirelli
>
> WARN Sisu - Error injecting: org.apache.maven.execution.DefaultMavenExecutionRequestPopulator
> com.google.inject.ProvisionException: Unable to provision, see the following errors:
> 1) No implementation for org.apache.maven.repository.RepositorySystem was bound.
> while locating org.apache.maven.execution.DefaultMavenExecutionRequestPopulator
> 1 error
> at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1018)
> at com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1044)
> at org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
> at com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:86)
> at com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:54)
> at com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
> at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:113)
> at org.eclipse.sisu.bean.BeanScheduler$Activator.onProvision(BeanScheduler.java:176)
> at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:122)
> at com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
> at com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
> at com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:46)
> at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
> at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1066)
> at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
> at com.google.inject.Scopes$1$1.get(Scopes.java:59)
> at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
> at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1009)
> at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1059)
> at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1005)
> at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:82)
> at org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:263)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:255)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:249)
> at org.kie.scanner.embedder.PlexusComponentProvider.lookup(PlexusComponentProvider.java:42)
> at org.kie.scanner.embedder.MavenEmbedder.buildMavenExecutionRequest(MavenEmbedder.java:119)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:90)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:81)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:75)
> at org.kie.scanner.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:42)
> at org.kie.scanner.embedder.MavenProjectLoader.loadMavenProject(MavenProjectLoader.java:96)
> at org.kie.scanner.Aether.<init>(Aether.java:62)
> at org.kie.scanner.Aether.getAether(Aether.java:74)
> at org.kie.scanner.MavenRepository.getMavenRepository(MavenRepository.java:80)
> at org.kie.scanner.ArtifactResolver.<init>(ArtifactResolver.java:53)
> at org.kie.scanner.KieRepositoryScannerImpl.getArtifactResolver(KieRepositoryScannerImpl.java:102)
> at org.kie.scanner.KieRepositoryScannerImpl.loadArtifact(KieRepositoryScannerImpl.java:119)
> at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.loadKieModuleFromMavenRepo(KieRepositoryImpl.java:130)
> at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.getKieModule(KieRepositoryImpl.java:116)
> at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.getKieModule(KieRepositoryImpl.java:93)
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:115)
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:111)
> at com.cyngn.soothsayer.application.Server.init(Server.java:83)
> at io.vertx.core.impl.DeploymentManager.lambda$doDeploy$163(DeploymentManager.java:427)
> at io.vertx.core.impl.ContextImpl.lambda$wrapTask$18(ContextImpl.java:335)
> at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:358)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357)
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
> at java.lang.Thread.run(Thread.java:745)
> 14:22:39.388 [vert.x-eventloop-thread-1] ERROR o.kie.scanner.embedder.MavenEmbedder - Unable to build MavenEmbedder
> org.codehaus.plexus.component.repository.exception.ComponentLookupException: com.google.inject.ProvisionException: Unable to provision, see the following errors:
> 1) No implementation for org.apache.maven.repository.RepositorySystem was bound.
> while locating org.apache.maven.execution.DefaultMavenExecutionRequestPopulator
> at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]] (via modules: org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
> at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]] (via modules: org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.apache.maven.execution.MavenExecutionRequestPopulator
> 1 error
> role: org.apache.maven.execution.MavenExecutionRequestPopulator
> roleHint:
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:267)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:255)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:249)
> at org.kie.scanner.embedder.PlexusComponentProvider.lookup(PlexusComponentProvider.java:42)
> at org.kie.scanner.embedder.MavenEmbedder.buildMavenExecutionRequest(MavenEmbedder.java:119)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:90)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:81)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:75)
> at org.kie.scanner.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:42)
> at org.kie.scanner.embedder.MavenProjectLoader.loadMavenProject(MavenProjectLoader.java:96)
> at org.kie.scanner.Aether.<init>(Aether.java:62)
> at org.kie.scanner.Aether.getAether(Aether.java:74)
> at org.kie.scanner.MavenRepository.getMavenRepository(MavenRepository.java:80)
> at org.kie.scanner.ArtifactResolver.<init>(ArtifactResolver.java:53)
> at org.kie.scanner.KieRepositoryScannerImpl.getArtifactResolver(KieRepositoryScannerImpl.java:102)
> at org.kie.scanner.KieRepositoryScannerImpl.loadArtifact(KieRepositoryScannerImpl.java:119)
> at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.loadKieModuleFromMavenRepo(KieRepositoryImpl.java:130)
> at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.getKieModule(KieRepositoryImpl.java:116)
> at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.getKieModule(KieRepositoryImpl.java:93)
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:115)
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:111)
> at com.cyngn.soothsayer.application.Server.init(Server.java:83)
> at io.vertx.core.impl.DeploymentManager.lambda$doDeploy$163(DeploymentManager.java:427)
> at io.vertx.core.impl.ContextImpl.lambda$wrapTask$18(ContextImpl.java:335)
> at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:358)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357)
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1124) Unble to provision errors when creating KieContainor from KieServices in the Vert.X verticle
by xiaodong wang (JIRA)
xiaodong wang created DROOLS-1124:
-------------------------------------
Summary: Unble to provision errors when creating KieContainor from KieServices in the Vert.X verticle
Key: DROOLS-1124
URL: https://issues.jboss.org/browse/DROOLS-1124
Project: Drools
Issue Type: Bug
Components: kie server
Affects Versions: 6.4.0.CR2
Environment: OS: MacOX and 10.10.5
Vert.X: 3.2.1
Reporter: xiaodong wang
Assignee: Edson Tirelli
WARN Sisu - Error injecting: org.apache.maven.execution.DefaultMavenExecutionRequestPopulator
com.google.inject.ProvisionException: Unable to provision, see the following errors:
1) No implementation for org.apache.maven.repository.RepositorySystem was bound.
while locating org.apache.maven.execution.DefaultMavenExecutionRequestPopulator
1 error
at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1018)
at com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1044)
at org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
at com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:86)
at com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:54)
at com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:113)
at org.eclipse.sisu.bean.BeanScheduler$Activator.onProvision(BeanScheduler.java:176)
at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:122)
at com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
at com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
at com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:46)
at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1066)
at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
at com.google.inject.Scopes$1$1.get(Scopes.java:59)
at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1009)
at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1059)
at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1005)
at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:82)
at org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:263)
at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:255)
at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:249)
at org.kie.scanner.embedder.PlexusComponentProvider.lookup(PlexusComponentProvider.java:42)
at org.kie.scanner.embedder.MavenEmbedder.buildMavenExecutionRequest(MavenEmbedder.java:119)
at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:90)
at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:81)
at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:75)
at org.kie.scanner.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:42)
at org.kie.scanner.embedder.MavenProjectLoader.loadMavenProject(MavenProjectLoader.java:96)
at org.kie.scanner.Aether.<init>(Aether.java:62)
at org.kie.scanner.Aether.getAether(Aether.java:74)
at org.kie.scanner.MavenRepository.getMavenRepository(MavenRepository.java:80)
at org.kie.scanner.ArtifactResolver.<init>(ArtifactResolver.java:53)
at org.kie.scanner.KieRepositoryScannerImpl.getArtifactResolver(KieRepositoryScannerImpl.java:102)
at org.kie.scanner.KieRepositoryScannerImpl.loadArtifact(KieRepositoryScannerImpl.java:119)
at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.loadKieModuleFromMavenRepo(KieRepositoryImpl.java:130)
at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.getKieModule(KieRepositoryImpl.java:116)
at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.getKieModule(KieRepositoryImpl.java:93)
at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:115)
at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:111)
at com.cyngn.soothsayer.application.Server.init(Server.java:83)
at io.vertx.core.impl.DeploymentManager.lambda$doDeploy$163(DeploymentManager.java:427)
at io.vertx.core.impl.ContextImpl.lambda$wrapTask$18(ContextImpl.java:335)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:358)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357)
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
at java.lang.Thread.run(Thread.java:745)
14:22:39.388 [vert.x-eventloop-thread-1] ERROR o.kie.scanner.embedder.MavenEmbedder - Unable to build MavenEmbedder
org.codehaus.plexus.component.repository.exception.ComponentLookupException: com.google.inject.ProvisionException: Unable to provision, see the following errors:
1) No implementation for org.apache.maven.repository.RepositorySystem was bound.
while locating org.apache.maven.execution.DefaultMavenExecutionRequestPopulator
at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]] (via modules: org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]] (via modules: org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
while locating org.apache.maven.execution.MavenExecutionRequestPopulator
1 error
role: org.apache.maven.execution.MavenExecutionRequestPopulator
roleHint:
at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:267)
at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:255)
at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:249)
at org.kie.scanner.embedder.PlexusComponentProvider.lookup(PlexusComponentProvider.java:42)
at org.kie.scanner.embedder.MavenEmbedder.buildMavenExecutionRequest(MavenEmbedder.java:119)
at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:90)
at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:81)
at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:75)
at org.kie.scanner.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:42)
at org.kie.scanner.embedder.MavenProjectLoader.loadMavenProject(MavenProjectLoader.java:96)
at org.kie.scanner.Aether.<init>(Aether.java:62)
at org.kie.scanner.Aether.getAether(Aether.java:74)
at org.kie.scanner.MavenRepository.getMavenRepository(MavenRepository.java:80)
at org.kie.scanner.ArtifactResolver.<init>(ArtifactResolver.java:53)
at org.kie.scanner.KieRepositoryScannerImpl.getArtifactResolver(KieRepositoryScannerImpl.java:102)
at org.kie.scanner.KieRepositoryScannerImpl.loadArtifact(KieRepositoryScannerImpl.java:119)
at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.loadKieModuleFromMavenRepo(KieRepositoryImpl.java:130)
at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.getKieModule(KieRepositoryImpl.java:116)
at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.getKieModule(KieRepositoryImpl.java:93)
at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:115)
at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:111)
at com.cyngn.soothsayer.application.Server.init(Server.java:83)
at io.vertx.core.impl.DeploymentManager.lambda$doDeploy$163(DeploymentManager.java:427)
at io.vertx.core.impl.ContextImpl.lambda$wrapTask$18(ContextImpl.java:335)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:358)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357)
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1471) CLI class is mixing commands and operations
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1471?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise reassigned WFCORE-1471:
--------------------------------------------
Description:
CLI.cmd method logic is not in sync with the CLI syntax.
A fallback is implemented in order to route requests to cx.handle only if ctx.buildRequest(cliCommand) is failing.
For example this doesn't cope with reload vs :reload. In this case, buildRequest will succeed both for reload and :reload. CLI.cmd("reload") will end to be treated as CLI.cmd(":reload");
Furthermore batch and workflow are not supported by CLI.
I am suggesting to implement the following logic:
1) If batch is enabled or a workflow is enabled, route the command to handle
2) Parse the request.
3) If this is an operation, route to execute
4) Otherwise route to handle
was:
Creating and connecting a context although the remote server is not yet up and running has a side effect in this following case:
1) Create a fresh context
2) Embed a server
3) Reload it with management enabled
4) Create another Context and connect to embedded remote interface
==> All is fine
Add a step in between 1) an 2) the create and connect a context to the remote management interface (that obviously is not yet there) and step 3) will fail. Reloading the embedded server fails
The way to reload the embedded server has an impact. context.handle(...) will not be affected, context.getControllerClient().execute(...) is impacted.. So something wrong there to chase.
Summary: CLI class is mixing commands and operations (was: Side effect in CommandContext instances when connection to server is failing)
Assignee: Jean-Francois Denise (was: Alexey Loubyansky)
> CLI class is mixing commands and operations
> -------------------------------------------
>
> Key: WFCORE-1471
> URL: https://issues.jboss.org/browse/WFCORE-1471
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 3.0.0.Alpha1
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> CLI.cmd method logic is not in sync with the CLI syntax.
> A fallback is implemented in order to route requests to cx.handle only if ctx.buildRequest(cliCommand) is failing.
> For example this doesn't cope with reload vs :reload. In this case, buildRequest will succeed both for reload and :reload. CLI.cmd("reload") will end to be treated as CLI.cmd(":reload");
> Furthermore batch and workflow are not supported by CLI.
> I am suggesting to implement the following logic:
> 1) If batch is enabled or a workflow is enabled, route the command to handle
> 2) Parse the request.
> 3) If this is an operation, route to execute
> 4) Otherwise route to handle
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6522) Improve support for mutable session variables with non-tx session cache
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-6522:
----------------------------------
Summary: Improve support for mutable session variables with non-tx session cache
Key: WFLY-6522
URL: https://issues.jboss.org/browse/WFLY-6522
Project: WildFly
Issue Type: Feature Request
Components: Clustering
Affects Versions: 10.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Fix For: 10.1.0.Final
Currently, mutable session attributes require a transactional cache configuration in order to replicate properly. To support non-tx caches, we can record which mutable session attributes were accessed on a given session and re-set them at the end of the request.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6514) DistributableSingleSignOn register an SessionIdChangeListener for each SSO session
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6514?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-6514:
-------------------------------
Component/s: Clustering
> DistributableSingleSignOn register an SessionIdChangeListener for each SSO session
> ----------------------------------------------------------------------------------
>
> Key: WFLY-6514
> URL: https://issues.jboss.org/browse/WFLY-6514
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Juan AMAT
> Assignee: Paul Ferraro
> Priority: Blocker
>
> During performance testing on our app we noticed an continuous increase of CPU utilization while the load was constant.
> In turns out that for each session an undertow SessionListener was registered at login and was never unregistered (request.logout or session.invalidate).
> As a result all the operations on undertow SessionListeners are taking more CPU every time a listener is added as we loop over those listeners.
> First of all we should register only one (if needed) such SessionListener per webapp.
> But even in the current implementation, the listener was not unregistered when request.logout was called.
> It is unregistered when session.invalidate is called but then this is not the same listener that is provided and thus nothing is done.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years