[JBoss JIRA] (WFLY-2643) JBOSS_LOG_DIR is checked but not used to set jboss.server.log.dir
by Stian Lund (JIRA)
[ https://issues.jboss.org/browse/WFLY-2643?page=com.atlassian.jira.plugin.... ]
Stian Lund updated WFLY-2643:
-----------------------------
Description:
In standalone/domain start scripts (standalone.sh/bat) the value of environment variable JBOSS_LOG_DIR is checked for:
{code}
# determine the default log dir, if not set
if [ "x$JBOSS_LOG_DIR" = "x" ]; then
JBOSS_LOG_DIR="$JBOSS_BASE_DIR/log"
fi
{code}
However, this is not actually used to set the value of Java property jboss.server.log.dir.
{code}
-Djboss.home.dir=\"$JBOSS_HOME\" \
-Djboss.server.base.dir=\"$JBOSS_BASE_DIR\" \
"$SERVER_OPTS"
{code}
(It should be set at the same place)
This leads Jboss/Wildfly/EAP to assume the default value of $JBOSS_BASE_DIR/log.
This is a problem for those who want to override the location of the server.log files.
was:
In standalone/domain start scripts (standalone.sh/bat) the value of environment variable JBOSS_LOG_DIR is checked for:
# determine the default log dir, if not set
if [ "x$JBOSS_LOG_DIR" = "x" ]; then
JBOSS_LOG_DIR="$JBOSS_BASE_DIR/log"
fi
However, this is not actually used to set the value of Java property jboss.server.log.dir.
-Djboss.home.dir=\"$JBOSS_HOME\" \
-Djboss.server.base.dir=\"$JBOSS_BASE_DIR\" \
"$SERVER_OPTS"
(It should be set at the same place)
This leads Jboss/Wildfly/EAP to assume the default value of $JBOSS_BASE_DIR/log.
This is a problem for those who want to override the location of the server.log files.
> JBOSS_LOG_DIR is checked but not used to set jboss.server.log.dir
> -----------------------------------------------------------------
>
> Key: WFLY-2643
> URL: https://issues.jboss.org/browse/WFLY-2643
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging, Server
> Affects Versions: JBoss AS7 7.1.1.Final, 8.0.0.Beta1
> Environment: All
> Reporter: Stian Lund
> Assignee: James Perkins
> Labels: jbossas, logging, wildfly
>
> In standalone/domain start scripts (standalone.sh/bat) the value of environment variable JBOSS_LOG_DIR is checked for:
> {code}
> # determine the default log dir, if not set
> if [ "x$JBOSS_LOG_DIR" = "x" ]; then
> JBOSS_LOG_DIR="$JBOSS_BASE_DIR/log"
> fi
> {code}
> However, this is not actually used to set the value of Java property jboss.server.log.dir.
> {code}
> -Djboss.home.dir=\"$JBOSS_HOME\" \
> -Djboss.server.base.dir=\"$JBOSS_BASE_DIR\" \
> "$SERVER_OPTS"
> {code}
> (It should be set at the same place)
> This leads Jboss/Wildfly/EAP to assume the default value of $JBOSS_BASE_DIR/log.
> This is a problem for those who want to override the location of the server.log files.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (JGRP-1728) Allow testsuite parallelism to be controlled from build.xml alone
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1728?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1728:
--------------------------------
We might be able to get rid of the XML suite definition files altogether ! Below is a crude example of how to run target {{functional}} with 10 threads (hard-coded). This would of course have to be changed in the {{runtest}} macro itself, but this shows it actually works.
{code:xml}
<target name="run" depends="define-testng-task">
<testng classpathref="jg.classpath"
usedefaultlisteners="false"
groups="functional"
excludedgroups="broken"
timeOut="120000"
outputdir="@{outputdir}"
listeners="org.jgroups.util.JUnitXMLReporter"
timeout="${unittest.timeout}"
verbose="${test.verbose}" threadcount="10"
parallel="methods"
>
<classfileset dir="${compile.dir}"/>
<!--<xmlfileset dir="${testng.conf.dir}" includes="@{testng.xmlfile}"/>-->
<sysproperty key="test.suffix" value="@{testname.ext}"/>
<sysproperty key="INITIAL_MCAST_ADDR" value="@{initial.mcast.addr}"/>
<sysproperty key="INITIAL_MCAST_PORT" value="@{initial.mcast.port}"/>
<sysproperty key="INITIAL_TCP_PORT" value="@{initial.tcp.port}"/>
<sysproperty key="tcp.recv_buf_size" value="@{tcp.recv.buf.size}"/>
<sysproperty key="tcp.send_buf_size" value="@{tcp.send.buf.size}"/>
<jvmarg value="-Djgroups.bind_addr=${jgroups.bind_addr}"/>
<jvmarg value="-Djgroups.tcpping.initial_hosts=${jgroups.tcpping.initial_hosts}"/>
<jvmarg value="-Djgroups.tunnel.gossip_router_hosts=${jgroups.tunnel.gossip_router_hosts}"/>
<jvmarg value="-Dtests.tmp.dir=${tmp.dir}"/>
<jvmarg value="-Dlog4j.configuration=file:${conf.dir}/log4j.properties"/>
<jvmarg value="-Dlog4j.configurationFile=${conf.dir}/log4j2.xml"/>
<jvmarg value="-Djava.net.preferIPv4Stack=${java.net.preferIPv4Stack}"/>
<jvmarg value="-Djava.net.preferIPv6Addresses=${java.net.preferIPv6Addresses}"/>
<jvmarg value="-Xms400M"/>
<jvmarg value="-Xmx800M"/>
</testng>
</target>
{code}
> Allow testsuite parallelism to be controlled from build.xml alone
> -----------------------------------------------------------------
>
> Key: JGRP-1728
> URL: https://issues.jboss.org/browse/JGRP-1728
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.5
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> Directives controlling parallel execution of the JGroups testsuite can be specified at two levels: as parameters to the testng ant task (in build.xml), or as attributes of the suite element in the suite definition files (found in the conf/testng directory).
> At present, parallelism directives in the various suite definition files (functional.xml, udp.xml, tcp.xml, etc.) take precedence over any directives specified in testng ant tasks. In fact, the directives passed to runtest in build.xml are (incorrectly) not passed through to the testng ant task, so that parallelism is controlled solely from the suite definition files.
> Making use of parallel execution of test cases when running in the QA lab leads to a higher proportion of test failures, leading to a proliferation of JIRA/bugzilla issues. Therefore it is important that we be able to turn on (turn off) parallel execution of test cases through some simple specification of system properties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (WFLY-2638) jboss-javaee6-quickstarts on WildFly Beta2-SNAPSHOT - JSF fails with ViewExpiredException
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/WFLY-2638?page=com.atlassian.jira.plugin.... ]
Lukáš Fryč updated WFLY-2638:
-----------------------------
Attachment: jboss-javaee6-webapp.war
Attaching sample WAR and its source: https://github.com/lfryc/jboss-javaee6-webapp
> jboss-javaee6-quickstarts on WildFly Beta2-SNAPSHOT - JSF fails with ViewExpiredException
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-2638
> URL: https://issues.jboss.org/browse/WFLY-2638
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JSF
> Affects Versions: 8.0.0.CR1
> Environment: WildFly Beta2-SNAPSHOT (revision 95aa9c0ad64a2feccfc97ccb2c1194e9ac83872d )
> Reporter: Lukáš Fryč
> Assignee: Farah Juma
> Attachments: jboss-javaee6-webapp.war
>
>
> Steps to reproduce:
> 1. create a {{jboss-javaee6-webapp}} from [archetype|https://github.com/jboss-developer/jboss-eap-archetypes/tree/ma...] or via JBoss Tools Central (Create from scratch > Java EE Web Project)
> 2. navigate browser to application http://localhost:8080/jboss-javaee6-webapp/index.jsf
> 2. do any action leading to postback, such as clicking Register button
> Detailed debug log is here:
> https://gist.github.com/lfryc/53145a9cc5e568e5792e
> Stack trace:
> {code}
> Context Path:/jboss-javaee6-webapp
> Servlet Path:/index.jsf
> Path Info:null
> Query String:null
> Stack Trace
> javax.servlet.ServletException: viewId:/index.jsf - View /index.jsf could not be restored.
> javax.faces.webapp.FacesServlet.service(FacesServlet.java:659)
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87)
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
> io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65)
> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:238)
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:225)
> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:71)
> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:144)
> io.undertow.server.Connectors.executeRootHandler(Connectors.java:164)
> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:655)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> java.lang.Thread.run(Thread.java:744)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (WFLY-2641) ARQ upgrade likely to cause test failures
by Aslak Knutsen (JIRA)
[ https://issues.jboss.org/browse/WFLY-2641?page=com.atlassian.jira.plugin.... ]
Aslak Knutsen commented on WFLY-2641:
-------------------------------------
1.1.3.Final-SNAPSHOT == 1.1.2.Final
> ARQ upgrade likely to cause test failures
> ------------------------------------------
>
> Key: WFLY-2641
> URL: https://issues.jboss.org/browse/WFLY-2641
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Thomas Diesler
> Assignee: Aslak Knutsen
> Priority: Critical
> Fix For: 8.0.0.CR1
>
>
> {code}
> testSimpleBundleWithWabExtension(org.jboss.test.osgi.example.webapp.WebAppTestCase) Time elapsed: 0.028 sec <<< ERROR!
> java.lang.NullPointerException: null
> at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:290)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (JGRP-1728) Allow testsuite parallelism to be controlled from build.xml alone
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1728?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1728:
--------------------------------
Sorry, my comment was a bit premature; seems that the value (e.g. for {{thread-count}}) in build.xml does *not* override the (default value of 1) in {{functional.xml}}....
> Allow testsuite parallelism to be controlled from build.xml alone
> -----------------------------------------------------------------
>
> Key: JGRP-1728
> URL: https://issues.jboss.org/browse/JGRP-1728
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.5
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> Directives controlling parallel execution of the JGroups testsuite can be specified at two levels: as parameters to the testng ant task (in build.xml), or as attributes of the suite element in the suite definition files (found in the conf/testng directory).
> At present, parallelism directives in the various suite definition files (functional.xml, udp.xml, tcp.xml, etc.) take precedence over any directives specified in testng ant tasks. In fact, the directives passed to runtest in build.xml are (incorrectly) not passed through to the testng ant task, so that parallelism is controlled solely from the suite definition files.
> Making use of parallel execution of test cases when running in the QA lab leads to a higher proportion of test failures, leading to a proliferation of JIRA/bugzilla issues. Therefore it is important that we be able to turn on (turn off) parallel execution of test cases through some simple specification of system properties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (JGRP-1728) Allow testsuite parallelism to be controlled from build.xml alone
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1728?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1728:
--------------------------------
Wouldn't a simple solution be to remove the {{thread-count}} and {{parallel}} directives from the XML files and only use the directives in build.xml ?
I tried this with target {{functional}} and it worked without issues...
> Allow testsuite parallelism to be controlled from build.xml alone
> -----------------------------------------------------------------
>
> Key: JGRP-1728
> URL: https://issues.jboss.org/browse/JGRP-1728
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.5
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> Directives controlling parallel execution of the JGroups testsuite can be specified at two levels: as parameters to the testng ant task (in build.xml), or as attributes of the suite element in the suite definition files (found in the conf/testng directory).
> At present, parallelism directives in the various suite definition files (functional.xml, udp.xml, tcp.xml, etc.) take precedence over any directives specified in testng ant tasks. In fact, the directives passed to runtest in build.xml are (incorrectly) not passed through to the testng ant task, so that parallelism is controlled solely from the suite definition files.
> Making use of parallel execution of test cases when running in the QA lab leads to a higher proportion of test failures, leading to a proliferation of JIRA/bugzilla issues. Therefore it is important that we be able to turn on (turn off) parallel execution of test cases through some simple specification of system properties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (WFLY-2640) Unable to add cached-connection-manager after removing it once
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/WFLY-2640?page=com.atlassian.jira.plugin.... ]
Jesper Pedersen reassigned WFLY-2640:
-------------------------------------
Assignee: Stefano Maestri (was: Jesper Pedersen)
> Unable to add cached-connection-manager after removing it once
> --------------------------------------------------------------
>
> Key: WFLY-2640
> URL: https://issues.jboss.org/browse/WFLY-2640
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Affects Versions: 8.0.0.Beta1
> Reporter: Masafumi Miura
> Assignee: Stefano Maestri
>
> {{<cached-connection-manager>}} is enabled in jca subsystem by default:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:jca:1.1">
> ...
> <cached-connection-manager />
> </subsystem>
> {code}
> However, it is unable to re-enable {{<cached-connection-manager>}} once it is disabled. CLI command fails to add it due to duplicate resource.
> {code}
> [standalone@localhost:9990 /] /subsystem=jca/cached-connection-manager=cached-connection-manager:remove
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> [standalone@localhost:9990 /] :reload
> {
> "outcome" => "success",
> "result" => undefined
> }
> [standalone@localhost:9990 /] /subsystem=jca/cached-connection-manager=cached-connection-manager:add
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014803: Duplicate resource [
> (\"subsystem\" => \"jca\"),
> (\"cached-connection-manager\" => \"cached-connection-manager\")
> ]",
> "rolled-back" => true
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (JGRP-1743) NAKACK*: log a warning if xmit_table gets large
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1743?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1743.
----------------------------
Resolution: Rejected
I'm afraid I'll have to reject this for the following reasons:
- Setting a threshold to trigger a warning is almost always wrong: either the warning never triggers if the threshold is too high or it always triggers it the threshold is too low
- There may be cases where NAKACK2 storing 1 million (small) messages is perfectly valid
- I don't think this is JGroups functionality, but management functionality, e.g. this could be done by periodically running a JMX/probe operation to fetch the number of messages (or total size) in all cluster nodes
> NAKACK*: log a warning if xmit_table gets large
> -----------------------------------------------
>
> Key: JGRP-1743
> URL: https://issues.jboss.org/browse/JGRP-1743
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 3.4.1
> Reporter: Dennis Reed
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> There have been some cases where NAKACK* accumulates large number of messages, causing OutOfMemoryErrors.
> Large numbers of messages in NAKACK* would almost always indicate a problem, which the user should be aware of.
> Logging a warning if the number of messages in NAKACK passes a configurable threshold would let the user investigate and take action sooner before a catastrophic OutOfMemoryError, or other issues occur.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (WFLY-2643) JBOSS_LOG_DIR is checked but not used to set jboss.server.log.dir
by Stian Lund (JIRA)
Stian Lund created WFLY-2643:
--------------------------------
Summary: JBOSS_LOG_DIR is checked but not used to set jboss.server.log.dir
Key: WFLY-2643
URL: https://issues.jboss.org/browse/WFLY-2643
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Logging, Server
Affects Versions: 8.0.0.Beta1, JBoss AS7 7.1.1.Final
Environment: All
Reporter: Stian Lund
Assignee: James Perkins
In standalone/domain start scripts (standalone.sh/bat) the value of environment variable JBOSS_LOG_DIR is checked for:
# determine the default log dir, if not set
if [ "x$JBOSS_LOG_DIR" = "x" ]; then
JBOSS_LOG_DIR="$JBOSS_BASE_DIR/log"
fi
However, this is not actually used to set the value of Java property jboss.server.log.dir.
-Djboss.home.dir=\"$JBOSS_HOME\" \
-Djboss.server.base.dir=\"$JBOSS_BASE_DIR\" \
"$SERVER_OPTS"
(It should be set at the same place)
This leads Jboss/Wildfly/EAP to assume the default value of $JBOSS_BASE_DIR/log.
This is a problem for those who want to override the location of the server.log files.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months