[JBoss JIRA] (JGRP-1920) FC: Flag NO_FC is not applied on RPC calls/responses
by Karim AMMOUS (JIRA)
Karim AMMOUS created JGRP-1920:
----------------------------------
Summary: FC: Flag NO_FC is not applied on RPC calls/responses
Key: JGRP-1920
URL: https://issues.jboss.org/browse/JGRP-1920
Project: JGroups
Issue Type: Bug
Reporter: Karim AMMOUS
Assignee: Bela Ban
When we set Flag.NO_FC on an RPC call through "RequestOptions", we expect that both request and response will be not rate limited.
Currently, both request and response could be slow down by flow control protocols.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months
[JBoss JIRA] (JGRP-1910) MERGE3: Do not lose any members from view during a series of merges
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1910?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1910:
--------------------------------
You lost me here. Can you give a concrete example ? The current algorithm tries to use something akin to a Lamport time as view-id and discards views with view-id <= to the current view-id.
> MERGE3: Do not lose any members from view during a series of merges
> -------------------------------------------------------------------
>
> Key: JGRP-1910
> URL: https://issues.jboss.org/browse/JGRP-1910
> Project: JGroups
> Issue Type: Bug
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.6.3
>
> Attachments: SplitMergeFailFastTest.java, SplitMergeTest.java
>
>
> When connection between nodes is re-established, MERGE3 should merge the cluster together. This often does not involve a single MergeView but a series of such events. The problematic property of this protocol is that some of those views can lack certain members, though these are reachable.
> This causes problem in Infinispan since the cache cannot be fully rebalanced before another merge arrives, and all owners of certain segment can be gradually removed (and added again) to the view, while this is not detected as partition but crashed nodes -> losing all owners means data loss.
> Removing members from view should be the role of FDx protocols, not MERGEx.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months
[JBoss JIRA] (LOGMGR-120) Thread local log level overriding
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-120?page=com.atlassian.jira.plugin... ]
David Lloyd commented on LOGMGR-120:
------------------------------------
Thanks for the contribution. There are several problems with the approach you take though, particularly around performance. In addition, you are modifying the structure of the log record which is not advisable at present. Finally as I described above, the core of the logging system itself is the place that this modification should be happening, in the way that I describe, for the reasons I give above.
> Thread local log level overriding
> ---------------------------------
>
> Key: LOGMGR-120
> URL: https://issues.jboss.org/browse/LOGMGR-120
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Components: core
> Affects Versions: 1.5.2.Final
> Reporter: Matthew Robson
> Assignee: James Perkins
> Attachments: force_logging.patch
>
>
> Having the ability to force logs down to a filter no matter what the log level is set to.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months
[JBoss JIRA] (JGRP-1910) MERGE3: Do not lose any members from view during a series of merges
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/JGRP-1910?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on JGRP-1910:
-----------------------------------
Views should be partially ordered, the concrete technique (parent UUIDs or GCed graph etc...) is an implementation detail. If merge leader has seen views from several nodes, then the new view should be ordered after those views. If a node receives view that is not ordered after its current view, it should reject it and wait until it receives correct one. Blindly accepting any view that knocks on the door is not a good option for Infinispan.
> MERGE3: Do not lose any members from view during a series of merges
> -------------------------------------------------------------------
>
> Key: JGRP-1910
> URL: https://issues.jboss.org/browse/JGRP-1910
> Project: JGroups
> Issue Type: Bug
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.6.3
>
> Attachments: SplitMergeFailFastTest.java, SplitMergeTest.java
>
>
> When connection between nodes is re-established, MERGE3 should merge the cluster together. This often does not involve a single MergeView but a series of such events. The problematic property of this protocol is that some of those views can lack certain members, though these are reachable.
> This causes problem in Infinispan since the cache cannot be fully rebalanced before another merge arrives, and all owners of certain segment can be gradually removed (and added again) to the view, while this is not detected as partition but crashed nodes -> losing all owners means data loss.
> Removing members from view should be the role of FDx protocols, not MERGEx.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months
[JBoss JIRA] (LOGMGR-120) Thread local log level overriding
by Thiago Veronezi (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-120?page=com.atlassian.jira.plugin... ]
Thiago Veronezi updated LOGMGR-120:
-----------------------------------
Attachment: force_logging.patch
Hi guys,
This is the patch I have for this new feature. Can you guys take a look at it?
[^force_logging.patch]
Thanks!
Thiago.
> Thread local log level overriding
> ---------------------------------
>
> Key: LOGMGR-120
> URL: https://issues.jboss.org/browse/LOGMGR-120
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Components: core
> Affects Versions: 1.5.2.Final
> Reporter: Matthew Robson
> Assignee: James Perkins
> Attachments: force_logging.patch
>
>
> Having the ability to force logs down to a filter no matter what the log level is set to.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months
[JBoss JIRA] (ELY-165) Review both security providers, can we avoid 'this' escaping construction?
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-165:
------------------------------------
Summary: Review both security providers, can we avoid 'this' escaping construction?
Key: ELY-165
URL: https://issues.jboss.org/browse/ELY-165
Project: WildFly Elytron
Issue Type: Task
Components: API / SPI, Passwords, SASL
Reporter: Darran Lofthouse
Fix For: 1.0.0.Alpha1
It should be possible to use the put methods just using Strings for keys and values, this way the provider does not need to leak through a Service instance.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months
[JBoss JIRA] (JBASMP-68) execute-commands does not work for module command
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/JBASMP-68?page=com.atlassian.jira.plugin.... ]
James Perkins commented on JBASMP-68:
-------------------------------------
I haven't actually looked at it. Though if the {[JBOSS_HOME}} needs to be set for CLI I think it's a bug and should be fixed.
> execute-commands does not work for module command
> -------------------------------------------------
>
> Key: JBASMP-68
> URL: https://issues.jboss.org/browse/JBASMP-68
> Project: JBoss AS Maven Plugins
> Issue Type: Bug
> Affects Versions: 7.6.Final
> Reporter: Alfio Gloria
> Assignee: James Perkins
>
> I'm trying to remove a jboss module by means of maven.
> {code:xml}
> <configuration>
> <jbossHome>${project.build.directory}/server/jboss72</jbossHome>
> <execute-commands>
> <commands>
> <command>module remove --slot=main --name=system.layers.base.org.jboss.weld.core</command>
> </commands>
> </execute-commands>
> </configuration>
> {code}
> execute-commands fails with the following stack trace:
> {code}
> Failed to execute goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands (install-patched-weld) on project tools: Execution install-patched-weld of goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands failed: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands (install-patched-weld) on project tools: Execution install-patched-weld of goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands failed: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set.
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution install-patched-weld of goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands failed: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set.
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 more
> Caused by: java.lang.IllegalArgumentException: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set.
> at org.jboss.as.plugin.cli.Commands.executeCommands(Commands.java:180)
> at org.jboss.as.plugin.cli.Commands.execute(Commands.java:134)
> at org.jboss.as.plugin.cli.ExecuteCommands.execute(ExecuteCommands.java:71)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
> ... 20 more
> Caused by: org.jboss.as.cli.CommandLineException: JBOSS_HOME environment variable is not set.
> at org.jboss.as.cli.handlers.module.ASModuleHandler.getModulesDir(ASModuleHandler.java:362)
> at org.jboss.as.cli.handlers.module.ASModuleHandler.removeModule(ASModuleHandler.java:326)
> at org.jboss.as.cli.handlers.module.ASModuleHandler.doHandle(ASModuleHandler.java:214)
> at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:86)
> at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:581)
> at org.jboss.as.plugin.cli.Commands.executeCommands(Commands.java:176)
> ... 23 more
> {code}
> (tested with the last snapshot too)
> The problem comes from jboss-as-cli that needs the JBOSS_HOME to be set in order to add or remove modules. This is not a requirement for other commands such as deploy.
> There are some points of confusion:
> # JBOSS_HOME is set in .bashrc but IDEs do not read .bashrc, thereby it can work in some cases but not in others;
> # usually there are more than one installation or jboss-as-maven-plugin can download the server;
> # jbossHome config parameter is not take into account;
> # what if I want to make operations on more the one server at the same time?
> At the moment I solved by patching jboss-as-cli using a system property instead of environment variable. I don't know how to solve without touching jboss-as-cli.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months
[JBoss JIRA] (WFLY-4285) NullPointerException in InfinispanBatcher.createBatch
by Michal Vinkler (JIRA)
[ https://issues.jboss.org/browse/WFLY-4285?page=com.atlassian.jira.plugin.... ]
Michal Vinkler closed WFLY-4285.
--------------------------------
Verified with the current WildFly master branch build.
> NullPointerException in InfinispanBatcher.createBatch
> -----------------------------------------------------
>
> Key: WFLY-4285
> URL: https://issues.jboss.org/browse/WFLY-4285
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 9.0.0.Alpha1
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
> Priority: Minor
> Attachments: clusterbench-ee7.ear
>
>
> When changing transaction mode to "NONE" for the cache containter "web" in standalone-ha.xml, starting the standalone server in the HA mode and deploying the "clusterbench" application (see the attachments), a NullPointerException occurs.
> Clusterbench git repo:
> https://github.com/clusterbench/clusterbench
> Stacktrace:
> {code}
> 11:13:17,546 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 63) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-passivating.war cache from web container
> 11:13:17,546 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 65) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-default.war cache from web container
> 11:13:17,546 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 66) WFLYCLINF0002: Started dist cache from ejb container
> 11:13:17,546 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 64) WFLYCLINF0002: Started dist cache from web container
> 11:13:17,554 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 66) MSC000001: Failed to start service jboss.clustering.registry.web.default: org.jboss.msc.service.StartException in service jboss.clustering.registry.web.default: java.lang.NullPointerException
> at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:107)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.NullPointerException
> at org.wildfly.clustering.ee.infinispan.InfinispanBatcher.createBatch(InfinispanBatcher.java:64)
> at org.wildfly.clustering.ee.infinispan.InfinispanBatcher.createBatch(InfinispanBatcher.java:41)
> at org.wildfly.clustering.server.registry.CacheRegistry.getLocalEntry(CacheRegistry.java:128)
> at org.wildfly.clustering.server.registry.CacheRegistry.<init>(CacheRegistry.java:76)
> at org.wildfly.clustering.server.registry.CacheRegistryFactory$1.<init>(CacheRegistryFactory.java:53)
> at org.wildfly.clustering.server.registry.CacheRegistryFactory.createRegistry(CacheRegistryFactory.java:53)
> at org.wildfly.clustering.server.registry.RegistryBuilder.start(RegistryBuilder.java:83)
> at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:102)
> ... 4 more
> 11:13:17,586 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 65) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 11:13:17,587 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 65) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 11:13:17,601 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 65) WFLYCLINF0002: Started clusterbench-ee7.ear/clusterbench-ee7-ejb.jar cache from ejb container
> 11:13:18,102 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "infinispan"),
> ("cache-container" => "web")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.clustering.registry.web.default" => "org.jboss.msc.service.StartException in service jboss.clustering.registry.web.default: java.lang.NullPointerException
> Caused by: java.lang.NullPointerException"}}
> 11:13:18,125 INFO [org.jboss.as.server] (ServerService Thread Pool -- 36) WFLYSRV0010: Deployed "clusterbench-ee7.ear" (runtime-name : "clusterbench-ee7.ear")
> 11:13:18,125 INFO [org.jboss.as.server] (ServerService Thread Pool -- 36) WFLYSRV0010: Deployed "sample.war" (runtime-name : "sample.war")
> 11:13:18,126 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0186: Services which failed to start: service jboss.clustering.registry.web.default: org.jboss.msc.service.StartException in service jboss.clustering.registry.web.default: java.lang.NullPointerException
> 11:13:18,146 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
> 11:13:18,147 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
> 11:13:18,147 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: WildFly Full 9.0.0.Alpha2-SNAPSHOT (WildFly Core 1.0.0.Alpha15) started (with errors) in 6312ms - Started 769 of 960 services (12 services failed or missing dependencies, 333 services are lazy, passive or on-demand)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months