[JBoss JIRA] (AS7-3800) JBOSS_BASE_DIR is checked in standalone.sh but not used to set -Djboss.server.base.dir
by Stian Lund (JIRA)
Stian Lund created AS7-3800:
-------------------------------
Summary: JBOSS_BASE_DIR is checked in standalone.sh but not used to set -Djboss.server.base.dir
Key: AS7-3800
URL: https://issues.jboss.org/browse/AS7-3800
Project: Application Server 7
Issue Type: Bug
Components: Scripts, Server
Affects Versions: 7.1.0.Final
Environment: Linux, WIndows
Reporter: Stian Lund
Assignee: Brian Stansberry
Priority: Minor
In standalone/domain.sh JBOSS_BASE_DIR is checked for and and used to set vars JBOSS_LOG_DIR and JBOSS_CONFIG_DIR (introduced in 7.1 Final) but not actually used to set java property jboss.server.base.dir, resulting in $JBOSS_HOME/standalone(/domain) still being used for tmp and cache.
Workaround is to still have -Djboss.server.base.dir set in launch parameter or init-script. Still should be put into script like:
"-Djboss.server.base.dir=$JBOSS_BASE_DIR"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] (JGRP-1446) "viewChange" function doesnt work properly in ReplicatedHashMap.Notification<Object, Object>
by jerome tan (JIRA)
jerome tan created JGRP-1446:
--------------------------------
Summary: "viewChange" function doesnt work properly in ReplicatedHashMap.Notification<Object,Object>
Key: JGRP-1446
URL: https://issues.jboss.org/browse/JGRP-1446
Project: JGroups
Issue Type: Bug
Affects Versions: 3.0.9
Environment: Windows 7/JDK1.6.0_31
Reporter: jerome tan
Assignee: Bela Ban
When I ran the demo: ReplicatedHashMapDemo in the source code of version 3.0.9. The "viewChange" function did not always invoke when new members join.
In the demo, the title of window changes when new member joins, but actually it is:
When there is one member the title is: 'ReplicatedHashMapDemo: 1 server(s)'
When there is two members titles are: 'ReplicatedHashMapDemo: 1 server(s)','ReplicatedHashMapDemo: 2 server(s)'
When there is three members titles are: 'ReplicatedHashMapDemo: 3 server(s)','ReplicatedHashMapDemo: 2 server(s)','ReplicatedHashMapDemo: 3 server(s)'
I am not sure if this demo program can be run one sever with multiple instance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] (JGRP-1445) Null pointer exception in FLUSH.rejectFlush()
by David Hotham (JIRA)
David Hotham created JGRP-1445:
----------------------------------
Summary: Null pointer exception in FLUSH.rejectFlush()
Key: JGRP-1445
URL: https://issues.jboss.org/browse/JGRP-1445
Project: JGroups
Issue Type: Bug
Affects Versions: 3.1
Reporter: David Hotham
Assignee: Bela Ban
Continuing to test JGRP-1426 / JGRP-1443, I noticed this go past:
Exception in thread "Thread-10" java.lang.NullPointerException
at org.jgroups.protocols.pbcast.FLUSH.rejectFlush(FLUSH.java:566)
at org.jgroups.protocols.pbcast.FLUSH.access$100(FLUSH.java:42)
at org.jgroups.protocols.pbcast.FLUSH$2.run(FLUSH.java:824)
at java.lang.Thread.run(Thread.java:662)
So far as I can see, this one is fairly benign; but I figure that reporting it is the right thing to do.
Thanks!
David
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBRULES-2685) Performance degradation from 5.0.1 to 5.1.0
by Greg Barton (JIRA)
Performance degradation from 5.0.1 to 5.1.0
-------------------------------------------
Key: JBRULES-2685
URL: https://jira.jboss.org/browse/JBRULES-2685
Project: Drools
Issue Type: Quality Risk
Security Level: Public (Everyone can see)
Components: drools-core
Affects Versions: 5.1.0.FINAL
Environment: OSX 1.6.2
Reporter: Greg Barton
Assignee: Mark Proctor
Priority: Minor
Attachments: DroolsNested.tar.gz
I've observed a sizable (25%) performance degradation between the 5.0.1 and 5.1.0 releases. I've attached a sample project that tests the performance of matching nested objects. (ANd compares direct reference matching and the performance pitfalls of "from," but that's beside the current point.)
If you switch the pom.xml from using 5.0.1 to 5.1.0 for the drools dependencies you'll see 25% longer execution times on the tests. (mvn test)
Here's the test output:
5.0.1
reference.drl Count: 2000
reference.drl Time: 267ms
reference.drl Time per element: 0.1335ms
BAR Duplicates: 780
FOO Duplicates: 880
reference.drl Count: 20000
reference.drl Time: 1249ms
reference.drl Time per element: 0.06245ms
BAR Duplicates: 7702
FOO Duplicates: 8040
from.drl Count: 200
from.drl Time: 1139ms
from.drl Time per element: 5.695ms
BAR Duplicates: 112
FOO Duplicates: 102
reference.drl Count: 200
reference.drl Time: 5ms
reference.drl Time per element: 0.025ms
BAR Duplicates: 86
FOO Duplicates: 60
5.1.0
reference.drl Count: 2000
reference.drl Time: 300ms
reference.drl Time per element: 0.15ms
BAR Duplicates: 788
FOO Duplicates: 820
reference.drl Count: 20000
reference.drl Time: 1564ms
reference.drl Time per element: 0.0782ms
BAR Duplicates: 8142
FOO Duplicates: 7960
from.drl Count: 200
from.drl Time: 3543ms
from.drl Time per element: 17.715ms
BAR Duplicates: 68
FOO Duplicates: 90
reference.drl Count: 200
reference.drl Time: 13ms
reference.drl Time per element: 0.065ms
BAR Duplicates: 84
FOO Duplicates: 74
On the most taxing test (20k objects) 5.0.1 took 1249ms while 5.1.0 took 1564ms, and for larger tests the effect is more pronounced. This is primarily a test of == on object references.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] (AS7-4306) stop-context enable-context disable-context all return 'Operation handler failed: null' unless virtualhost='default-host'
by Simeon Pinder (JIRA)
Simeon Pinder created AS7-4306:
----------------------------------
Summary: stop-context enable-context disable-context all return 'Operation handler failed: null' unless virtualhost='default-host'
Key: AS7-4306
URL: https://issues.jboss.org/browse/AS7-4306
Project: Application Server 7
Issue Type: Bug
Components: CLI
Affects Versions: 7.1.1.Final
Environment: Standalone AS7 instance using -c standalone-ha.xml profile.
Using jboss-cli.sh to manage modcluster subsystem.
Using modcluster 1.2.0.Final
Reporter: Simeon Pinder
Assignee: Alexey Loubyansky
i)Setup httpd, modcluster and as7 standalone instance and deploy cluster enabled webapp so that requests for http://(as7 server):8080/app.html is correctly served up by http://(httpd server)/app.html.
ii)Log into AS7 and attempt to run stop-context | enable-context | disable-context via cli with a host OTHER than 'virtual-host' and the commands fail with the following:
/subsystem=modcluster/:disable-context(virtualhost=vitalstatistix.conchfritter.com,context=/helloworld)
{
"outcome" => "failed",
"failure-description" => "JBAS014749: Operation handler failed: null",
"rolled-back" => true
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] (AS7-4404) Servlet statistics don't work
by Tomaz Cerar (JIRA)
Tomaz Cerar created AS7-4404:
--------------------------------
Summary: Servlet statistics don't work
Key: AS7-4404
URL: https://issues.jboss.org/browse/AS7-4404
Project: Application Server 7
Issue Type: Bug
Components: Domain Management, Web
Affects Versions: 7.1.1.Final
Reporter: Tomaz Cerar
Assignee: Tomaz Cerar
Fix For: 7.1.2.Final-redhat1
Running:
{noformat}
/host=master/server=server-one/deployment=test.war/:read-resource(recursive=true,include-runtime=true)
{
"outcome" => "success",
"result" => undefined,
"failure-description" => undefined
}
{noformat}
results in
{noformat}
[Server:server-one] 16:03:50,320 ERROR [org.jboss.as.controller.management-operation] (host-controller-connection-threads - 8) JBAS014612: Operation ("read-attribute") failed - address: ([
[Server:server-one] ("deployment" => "test.war"),
[Server:server-one] ("subsystem" => "web"),
[Server:server-one] ("servlet" => "ArquillianServletRunner")
[Server:server-one] ]): java.lang.UnsupportedOperationException
[Server:server-one] at org.jboss.dmr.ModelNode.checkProtect(ModelNode.java:1560) [jboss-dmr-1.1.1.Final.jar:1.1.1.Final]
[Server:server-one] at org.jboss.dmr.ModelNode.get(ModelNode.java:795) [jboss-dmr-1.1.1.Final.jar:1.1.1.Final]
{noformat}
without runtime=true it works without any problems
same goes if you go to /host=master/server=server-one/deployment=test.war/servlet=ArquillianServletRunner and run ls
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] (AS7-3142) VirtualFile error messages
by Ben Software Engineer (Created) (JIRA)
VirtualFile error messages
--------------------------
Key: AS7-3142
URL: https://issues.jboss.org/browse/AS7-3142
Project: Application Server 7
Issue Type: Support Patch
Components: VFS
Affects Versions: 7.1.0.CR1b
Environment: Windows 7, JDK 6, Eclipse Indigo
Reporter: Ben Software Engineer
Assignee: John Bailey
I'm migrating a app from JBoss 5.0.1 to JBoss 7.1 and getting an error when starting deployment of the EAR. It is almost impossible for me to troubleshoot as the error message is to vague. Please add the virtual file name and any other information that would make this error useful, thank you.
[org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.subunit."xxx-ear.ear"."xxx.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."xxx-ear.ear"."xxx.war".PARSE: Failed to process phase PARSE of subdeployment "oflows.war" of deployment "xxx-ear.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121) [jboss-as-server-7.1.0.CR1b.jar:7.1.0.CR1b]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
Caused by: java.lang.IllegalArgumentException: Given parent is not an ancestor of this virtual file
at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:116)
at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:122)
at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:122)
at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:122)
at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:122)
at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:122)
at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:122)
at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:122)
at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:122)
at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:122)
at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:110)
at org.jboss.as.web.deployment.TldParsingDeploymentProcessor.processTlds(TldParsingDeploymentProcessor.java:105)
at org.jboss.as.web.deployment.TldParsingDeploymentProcessor.deploy(TldParsingDeploymentProcessor.java:81)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115) [jboss-as-server-7.1.0.CR1b.jar:7.1.0.CR1b]
... 5 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] (JBAS-9481) race condition can break HASingleton functionality
by Dennis Reed (JIRA)
Dennis Reed created JBAS-9481:
---------------------------------
Summary: race condition can break HASingleton functionality
Key: JBAS-9481
URL: https://issues.jboss.org/browse/JBAS-9481
Project: Application Server 3 4 5 and 6
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: JBossAS-5.1.0.GA
Reporter: Dennis Reed
Assignee: Paul Ferraro
Attachments: test.jar
HASingletonImpl#registerDRMListener has a race condition with partitionTopologyChanged, which can cause views to be processed
out of order, and HASingletons to be started when they should be stopped, or stopped when they should be started.
The problem is that the thread calling registerDRMListener (which calls partitionTopologyChanged) is not synchronized against other threads that call partitionTopologyChanged.
This was introduced by the fix for https://issues.jboss.org/browse/JBAS-2647.
To fix the issue, partitionTopology must process the view saved in viewReference in the correct order, and registerDRMListener's
call to partitionTopology must be synchronized against other threads calling it (without causing a regression of JBAS-2647).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years