[JBoss JIRA] Created: (JGRP-457) Optimization: make threads return immediately if NAKACK has another active thread for the same sender
by Bela Ban (JIRA)
Optimization: make threads return immediately if NAKACK has another active thread for the same sender
-----------------------------------------------------------------------------------------------------
Key: JGRP-457
URL: http://jira.jboss.com/jira/browse/JGRP-457
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Priority: Minor
Fix For: 2.5
In NAKACK, when a thread places a message for sender S into the NakReceiverWindow NRW, it subsequently acquires a lock on NRW (lock by sender) and removes as many messages as possible and passes them up.
If many threads do this at the same time, all threads but one are blocked, and - when finally unblocked - usually return. This causes context switches and possibly cache flushing, so a better way would be to have the threads check whether another thread is already removing messages using a CAS operation *before* acquiring the lock.
The effect should be that no threads will wait on the lock unnecessarily, and thus fewer context switches, and more threads available to the pool.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2 weeks, 5 days
[JBoss JIRA] (DROOLS-570) Rule inheritance fails when using or pattern binding
by Eugene Shvartsman (JIRA)
[ https://issues.jboss.org/browse/DROOLS-570?page=com.atlassian.jira.plugin... ]
Eugene Shvartsman commented on DROOLS-570:
------------------------------------------
Hey Davide,
Thanks for verifying this so quickly. Your 'mvel' work around seems to work perfectly so far(we'll see if it breaks anything).
Am I right in understanding that this issue is resolved in 6.1? So I can wait and upgrade to 6.1.Final when it comes out?
Thanks
> Rule inheritance fails when using or pattern binding
> ----------------------------------------------------
>
> Key: DROOLS-570
> URL: https://issues.jboss.org/browse/DROOLS-570
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Environment: Windows 7 VM. Running drools using a JUnit driver
> Reporter: Eugene Shvartsman
> Assignee: Mark Proctor
> Attachments: tester-module.7z
>
>
> I've found a certain combination of rules (when using inheritance) that causes drools to throw the following exception: http://pastebin.com/xxq5ZtAC
> The rules that cause this exception to occur can be found here: http://pastebin.com/wM6rWY8L
> I've simplified my original rules down to the lowest level of detail that still throws the exception. The exception is no longer thrown if I:
> 1. Don't use rule inheritance
> 2. Don't have an or statement
> 3. Don't reference an LHS defined variable in the RHS of ruleB
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 3 months
[JBoss JIRA] (WFLY-816) Boot log writer ignores -Djboss.server.base.dir
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-816?page=com.atlassian.jira.plugin.s... ]
James Perkins closed WFLY-816.
------------------------------
Resolution: Out of Date
Closing this as the boot.log has gone away.
> Boot log writer ignores -Djboss.server.base.dir
> -----------------------------------------------
>
> Key: WFLY-816
> URL: https://issues.jboss.org/browse/WFLY-816
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management, Logging
> Reporter: Heiko Rupp
> Assignee: James Perkins
> Labels: rhq
>
> When on OS/X you start a server with -Djboss.server.base.dir this directory is used for configuration and also server.log, but not to populate the boot.log, which is still written to standalone/logs/boot.log.
> This is bad, as it will overwrite a boot.log for a server configuration that is running in parallel without -Djboss.server.base.dir= flag.
> Actually the logging config also seems to point at the old place
> hrupp 78046 0,0 1,1 1537296 96228 s005 S+ 10:55am 0:03.70 /usr/bin/java -D[Standalone] -d32 -client -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Djboss.server.default.config=standalone.xml -Dorg.jboss.boot.log.file=/devel/jboss-as-7.1.1.Final/standalone/log/boot.log -Dlogging.configuration=file:/devel/jboss-as-7.1.1.Final/standalone/configuration/logging.properties -jar /devel/jboss-as-7.1.1.Final/jboss-modules.jar -mp /devel/jboss-as-7.1.1.Final/modules -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -Djboss.home.dir=/devel/jboss-as-7.1.1.Final -Djboss.server.base.dir=/devel/jboss-as-7.1.1.Final/standalone2
> Turns out that the magic to detect -Djboss.server.base.dir in standalone.sh only works for linux:
> if $linux; then
> # consolidate the server and command line opts
> SERVER_OPTS="$JAVA_OPTS $@"
> # process the standalone options
> for var in $SERVER_OPTS
> as readlink is using '-m' flag that does not exist on OS/X.
> That dependency on linux and readlink -m will probably render this -Djboss.server.base.dir feature invalid for AIX/HP-UX/Solaris etc.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 3 months
[JBoss JIRA] (JBASMP-64) undeploy-artifact fails with misleading error message
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/JBASMP-64?page=com.atlassian.jira.plugin.... ]
James Perkins closed JBASMP-64.
-------------------------------
Resolution: Done
> undeploy-artifact fails with misleading error message
> -----------------------------------------------------
>
> Key: JBASMP-64
> URL: https://issues.jboss.org/browse/JBASMP-64
> Project: JBoss AS Maven Plugins
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: wildfly-maven-plugin 1.0.1.Final
> WildFly 8.0.0.Final, Oracle Java 1.7.0_51, Ubuntu 13.10 64-bit
> Reporter: Harald Wellmann
> Assignee: James Perkins
>
> undeploy-artifact fails with the following exception (mvn -X):
> {noformat}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.wildfly.plugins:wildfly-maven-plugin:1.0.1.Final:undeploy-artifact (undeploy) on project deployment: com.example.myapp
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> 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:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.wildfly.plugin.common.DeploymentFailureException: com.example.myapp
> at org.wildfly.plugin.deployment.UndeployArtifactMojo.validate(UndeployArtifactMojo.java:92)
> at org.wildfly.plugin.deployment.AbstractDeployment.doExecute(AbstractDeployment.java:136)
> at org.wildfly.plugin.deployment.AbstractDeployment.execute(AbstractDeployment.java:111)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 3 months
[JBoss JIRA] (WFCORE-37) Batching logging profile creation CLI commands can cause errors
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-37?page=com.atlassian.jira.plugin.... ]
James Perkins moved WFLY-3089 to WFCORE-37:
-------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-37 (was: WFLY-3089)
Affects Version/s: (was: 8.0.0.Final)
Component/s: Logging
(was: Logging)
> Batching logging profile creation CLI commands can cause errors
> ---------------------------------------------------------------
>
> Key: WFCORE-37
> URL: https://issues.jboss.org/browse/WFCORE-37
> Project: WildFly Core
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging
> Reporter: Kyle Lape
> Assignee: James Perkins
>
> Given these set of commands:
> {noformat}
> /subsystem=logging/logging-profile=myLoggingProfile:add
> /subsystem=logging/logging-profile=myLoggingProfile/file-handler=myHandler:add(level=ALL,file={"relative-to" => "jboss.server.log.dir","path" => "myapp.log"})
> /subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:add
> /subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:add-handler(name=myHandler)
> /subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:change-root-log-level(level=INFO)
> {noformat}
> If I run those in a batch, I get an error:
> {noformat}13:32:52,478 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014613: Operation ("add-handler") failed - address: ([
> ("subsystem" => "logging"),
> ("logging-profile" => "myLoggingProfile"),
> ("root-logger" => "ROOT")
> ]) - failure description: "JBAS011536: Handler myHandler is already assigned."
> {noformat}
> If I run each one individually, I get no error.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 3 months
[JBoss JIRA] (DROOLS-570) Rule inheritance fails when using or pattern binding
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/DROOLS-570?page=com.atlassian.jira.plugin... ]
Davide Sottara commented on DROOLS-570:
---------------------------------------
Confirmed..
the problem happens during the generation of the second rule's consequence.
See org.drools.core.rule.builder.dialect.asm.ConsequenceGenerator#235: the method "getQueueIndex" has actually been renamed "getIndex".
Unfortunately 6.1 has just been released, so you will have to use a SNAPSHOT or apply the fix yourself and recompile the code.
A workaround, use mvel rather than java in the second rule adding the attribute:
{code}
dialect "mvel"
{code}
Thanks for reporting this
Davide
> Rule inheritance fails when using or pattern binding
> ----------------------------------------------------
>
> Key: DROOLS-570
> URL: https://issues.jboss.org/browse/DROOLS-570
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Environment: Windows 7 VM. Running drools using a JUnit driver
> Reporter: Eugene Shvartsman
> Assignee: Mark Proctor
> Attachments: tester-module.7z
>
>
> I've found a certain combination of rules (when using inheritance) that causes drools to throw the following exception: http://pastebin.com/xxq5ZtAC
> The rules that cause this exception to occur can be found here: http://pastebin.com/wM6rWY8L
> I've simplified my original rules down to the lowest level of detail that still throws the exception. The exception is no longer thrown if I:
> 1. Don't use rule inheritance
> 2. Don't have an or statement
> 3. Don't reference an LHS defined variable in the RHS of ruleB
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 3 months
[JBoss JIRA] (WFLY-3699) Missing param-name in a web.xml causes NullPointerException during deployment
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3699?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-3699:
------------------------------
Component/s: Web (Undertow)
> Missing param-name in a web.xml causes NullPointerException during deployment
> ------------------------------------------------------------------------------
>
> Key: WFLY-3699
> URL: https://issues.jboss.org/browse/WFLY-3699
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JSF, Web (Undertow)
> Affects Versions: 9.0.0.Beta1
> Reporter: Jay Kumar SenSharma
> Assignee: Farah Juma
>
> - While deploying a WAR, If the web.xml file is used which has context <param-value> defined, However it has missing <param-name> then it causes NullPointerException as following:
> {code}
> 00:12:09,583 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0027: Starting deployment of "ContextParamNullDemo.war" (runtime-name: "ContextParamNullDemo.war")
> 00:12:09,591 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."ContextParamNullDemo.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."ContextParamNullDemo.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "ContextParamNullDemo.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.jsf.deployment.JSFVersionProcessor.deploy(JSFVersionProcessor.java:91)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> ... 5 more
> 00:12:09,598 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "ContextParamNullDemo.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"ContextParamNullDemo.war\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ContextParamNullDemo.war\".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment \"ContextParamNullDemo.war\"
> Caused by: java.lang.NullPointerException"}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 3 months
[JBoss JIRA] (WFLY-3699) Missing param-name in a web.xml causes NullPointerException during deployment
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3699?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-3699:
-----------------------------------
This should fail the deployment during parsing of descriptors not so late on.
Fix will probably be needed in metadata
> Missing param-name in a web.xml causes NullPointerException during deployment
> ------------------------------------------------------------------------------
>
> Key: WFLY-3699
> URL: https://issues.jboss.org/browse/WFLY-3699
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JSF, Web (Undertow)
> Affects Versions: 9.0.0.Beta1
> Reporter: Jay Kumar SenSharma
> Assignee: Farah Juma
>
> - While deploying a WAR, If the web.xml file is used which has context <param-value> defined, However it has missing <param-name> then it causes NullPointerException as following:
> {code}
> 00:12:09,583 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0027: Starting deployment of "ContextParamNullDemo.war" (runtime-name: "ContextParamNullDemo.war")
> 00:12:09,591 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."ContextParamNullDemo.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."ContextParamNullDemo.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "ContextParamNullDemo.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.jsf.deployment.JSFVersionProcessor.deploy(JSFVersionProcessor.java:91)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> ... 5 more
> 00:12:09,598 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "ContextParamNullDemo.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"ContextParamNullDemo.war\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ContextParamNullDemo.war\".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment \"ContextParamNullDemo.war\"
> Caused by: java.lang.NullPointerException"}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 3 months