[JBoss JIRA] (AS7-4001) Bad reference to XSL transformation files in module jboss-as-testsuite-benchmark and jboss-as-testsuite-stress
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/AS7-4001?page=com.atlassian.jira.plugin.s... ]
Ondrej Zizka resolved AS7-4001.
-------------------------------
Resolution: Duplicate Issue
JBPAPP-8312
> Bad reference to XSL transformation files in module jboss-as-testsuite-benchmark and jboss-as-testsuite-stress
> --------------------------------------------------------------------------------------------------------------
>
> Key: AS7-4001
> URL: https://issues.jboss.org/browse/AS7-4001
> Project: Application Server 7
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 7.1.1.Final
> Reporter: Pavel Janousek
> Assignee: Ondrej Zizka
> Priority: Critical
>
> Transformation procedure is invoked, but it seems like bad configuration path or not correctly done clean-up in previous step. I caught this problem via warning:
> {code}
> [INFO] --- xml-maven-plugin:1.0:transform (ts.config-as.ip) @ jboss-as-testsuite-stress ---
> [WARNING] The directory /mnt/hudson_workspace/workspace/AS7-TS-linux-ipv6-experiments/testsuite/stress/target/jbossas/standalone/configuration, which is a base directory of a ValidationSet or TransformationSet, does not exist.
> [WARNING] No files found for transformation by stylesheet /mnt/hudson_workspace/workspace/AS7-TS-linux-ipv6-experiments/testsuite/stress/../integration/src/test/xslt/changeIPAddresses.xsl
> [WARNING] The directory /mnt/hudson_workspace/workspace/AS7-TS-linux-ipv6-experiments/testsuite/stress/target/jbossas/standalone/configuration, which is a base directory of a ValidationSet or TransformationSet, does not exist.
> [WARNING] No files found for transformation by stylesheet /mnt/hudson_workspace/workspace/AS7-TS-linux-ipv6-experiments/testsuite/stress/../integration/src/test/xslt/addJmsDestinations.xsl
> {code}
> Further investigation says /build/target/... isn't copied to these modules at all.
> You can see this problem [there|https://hudson.qa.jboss.com/hudson/job/AS7-TS-linux-ipv6-experiment...].
--
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, 2 months
[JBoss JIRA] (AS7-4001) Bad reference to XSL transformation files in module jboss-as-testsuite-benchmark and jboss-as-testsuite-stress
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/AS7-4001?page=com.atlassian.jira.plugin.s... ]
Ondrej Zizka updated AS7-4001:
------------------------------
Priority: Critical (was: Blocker)
> Bad reference to XSL transformation files in module jboss-as-testsuite-benchmark and jboss-as-testsuite-stress
> --------------------------------------------------------------------------------------------------------------
>
> Key: AS7-4001
> URL: https://issues.jboss.org/browse/AS7-4001
> Project: Application Server 7
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 7.1.1.Final
> Reporter: Pavel Janousek
> Assignee: Ondrej Zizka
> Priority: Critical
>
> Transformation procedure is invoked, but it seems like bad configuration path or not correctly done clean-up in previous step. I caught this problem via warning:
> {code}
> [INFO] --- xml-maven-plugin:1.0:transform (ts.config-as.ip) @ jboss-as-testsuite-stress ---
> [WARNING] The directory /mnt/hudson_workspace/workspace/AS7-TS-linux-ipv6-experiments/testsuite/stress/target/jbossas/standalone/configuration, which is a base directory of a ValidationSet or TransformationSet, does not exist.
> [WARNING] No files found for transformation by stylesheet /mnt/hudson_workspace/workspace/AS7-TS-linux-ipv6-experiments/testsuite/stress/../integration/src/test/xslt/changeIPAddresses.xsl
> [WARNING] The directory /mnt/hudson_workspace/workspace/AS7-TS-linux-ipv6-experiments/testsuite/stress/target/jbossas/standalone/configuration, which is a base directory of a ValidationSet or TransformationSet, does not exist.
> [WARNING] No files found for transformation by stylesheet /mnt/hudson_workspace/workspace/AS7-TS-linux-ipv6-experiments/testsuite/stress/../integration/src/test/xslt/addJmsDestinations.xsl
> {code}
> Further investigation says /build/target/... isn't copied to these modules at all.
> You can see this problem [there|https://hudson.qa.jboss.com/hudson/job/AS7-TS-linux-ipv6-experiment...].
--
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, 2 months
[JBoss JIRA] (AS7-4011) TS: Bad approach used as fallback mechanism for gathering IP address
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/AS7-4011?page=com.atlassian.jira.plugin.s... ]
Ondrej Zizka commented on AS7-4011:
-----------------------------------
Stuart:
{quote}
The fallbacks are there for cases when no other stack is specified. As of today the test suite should honour all setting specified by the node0 and node1 addresses. If you are running under another network stack and have configured the build properly then these fallbacks should never be hit, they will only be used in the normal mvn install case with not other addresses set.
To be honest this sort of fallback should probably be implemented in the pom, so that the system properties are always defined. Feel free to volunteer to fix it.
{quote}
> TS: Bad approach used as fallback mechanism for gathering IP address
> --------------------------------------------------------------------
>
> Key: AS7-4011
> URL: https://issues.jboss.org/browse/AS7-4011
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 7.1.1.Final
> Reporter: Pavel Janousek
> Assignee: Ondrej Zizka
> Priority: Minor
>
> There are several places in TS where we can see similar code like this:
> {code}
> static final String someIPproperty = System.getProperty("<some key>", "localhost");
> {code}
> or
> {code}
> static final String someIPproperty = System.getProperty("<some key>", "127.0.0.1");
> {code}
> As you can see above, this fallback mechanism is bound in this case (key value isn't found) to IPv4 only IP address at all. This approach is bad because we can run in other network stack - IPv6 is presented in these days - and in this case the such testcase fails with some strange error due to this issue.
> I think we have two option how to resolve this issue:
> # Don't use fallback mechanism at all and fix (= remove) them in present testcases
> # Create auxiliary class which return 127.0.0.1 or ::1 string (but not string "localhost" because we can't be sure how it is translated (*))
> (*) common setup in Linux is to translate localhost -> 127.0.0.1 and localhost6 -> ::1
> Ad 1) I prefer this option because some forget/miss setting is very easy to catch
> Ad 2) This auxiliary class should need to make some magic decision in which IP network stack mode we are now running and return IPv4 or IPv6 lookpack address accordingly.
> I've been asking for decision in jboss-as7-dev mailing list [[1|http://lists.jboss.org/pipermail/jboss-as7-dev/2012-March/005449.html]] and we should wait for feedback from developers for final decision how to fix this issue.
> [1] http://lists.jboss.org/pipermail/jboss-as7-dev/2012-March/005449.html
--
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, 2 months
[JBoss JIRA] (AS7-4011) TS: Bad approach used as fallback mechanism for gathering IP address
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/AS7-4011?page=com.atlassian.jira.plugin.s... ]
Ondrej Zizka commented on AS7-4011:
-----------------------------------
Kabir:
{quote}
> Ad 1) I prefer this option because some forget/miss setting is very easy to catch
I don't like this one - having to remember to set all the addresses while developing will be annoying :-)
{quote}
> TS: Bad approach used as fallback mechanism for gathering IP address
> --------------------------------------------------------------------
>
> Key: AS7-4011
> URL: https://issues.jboss.org/browse/AS7-4011
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 7.1.1.Final
> Reporter: Pavel Janousek
> Assignee: Ondrej Zizka
> Priority: Minor
>
> There are several places in TS where we can see similar code like this:
> {code}
> static final String someIPproperty = System.getProperty("<some key>", "localhost");
> {code}
> or
> {code}
> static final String someIPproperty = System.getProperty("<some key>", "127.0.0.1");
> {code}
> As you can see above, this fallback mechanism is bound in this case (key value isn't found) to IPv4 only IP address at all. This approach is bad because we can run in other network stack - IPv6 is presented in these days - and in this case the such testcase fails with some strange error due to this issue.
> I think we have two option how to resolve this issue:
> # Don't use fallback mechanism at all and fix (= remove) them in present testcases
> # Create auxiliary class which return 127.0.0.1 or ::1 string (but not string "localhost" because we can't be sure how it is translated (*))
> (*) common setup in Linux is to translate localhost -> 127.0.0.1 and localhost6 -> ::1
> Ad 1) I prefer this option because some forget/miss setting is very easy to catch
> Ad 2) This auxiliary class should need to make some magic decision in which IP network stack mode we are now running and return IPv4 or IPv6 lookpack address accordingly.
> I've been asking for decision in jboss-as7-dev mailing list [[1|http://lists.jboss.org/pipermail/jboss-as7-dev/2012-March/005449.html]] and we should wait for feedback from developers for final decision how to fix this issue.
> [1] http://lists.jboss.org/pipermail/jboss-as7-dev/2012-March/005449.html
--
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, 2 months
[JBoss JIRA] (AS7-4011) TS: Bad approach used as fallback mechanism for gathering IP address
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/AS7-4011?page=com.atlassian.jira.plugin.s... ]
Ondrej Zizka updated AS7-4011:
------------------------------
Issue Type: Feature Request (was: Bug)
Priority: Minor (was: Blocker)
> TS: Bad approach used as fallback mechanism for gathering IP address
> --------------------------------------------------------------------
>
> Key: AS7-4011
> URL: https://issues.jboss.org/browse/AS7-4011
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 7.1.1.Final
> Reporter: Pavel Janousek
> Assignee: Ondrej Zizka
> Priority: Minor
>
> There are several places in TS where we can see similar code like this:
> {code}
> static final String someIPproperty = System.getProperty("<some key>", "localhost");
> {code}
> or
> {code}
> static final String someIPproperty = System.getProperty("<some key>", "127.0.0.1");
> {code}
> As you can see above, this fallback mechanism is bound in this case (key value isn't found) to IPv4 only IP address at all. This approach is bad because we can run in other network stack - IPv6 is presented in these days - and in this case the such testcase fails with some strange error due to this issue.
> I think we have two option how to resolve this issue:
> # Don't use fallback mechanism at all and fix (= remove) them in present testcases
> # Create auxiliary class which return 127.0.0.1 or ::1 string (but not string "localhost" because we can't be sure how it is translated (*))
> (*) common setup in Linux is to translate localhost -> 127.0.0.1 and localhost6 -> ::1
> Ad 1) I prefer this option because some forget/miss setting is very easy to catch
> Ad 2) This auxiliary class should need to make some magic decision in which IP network stack mode we are now running and return IPv4 or IPv6 lookpack address accordingly.
> I've been asking for decision in jboss-as7-dev mailing list [[1|http://lists.jboss.org/pipermail/jboss-as7-dev/2012-March/005449.html]] and we should wait for feedback from developers for final decision how to fix this issue.
> [1] http://lists.jboss.org/pipermail/jboss-as7-dev/2012-March/005449.html
--
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, 2 months
[JBoss JIRA] (AS7-4010) Slave HC unable to connect ro remote domain controller
by Dominik Pospisil (JIRA)
Dominik Pospisil created AS7-4010:
-------------------------------------
Summary: Slave HC unable to connect ro remote domain controller
Key: AS7-4010
URL: https://issues.jboss.org/browse/AS7-4010
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Affects Versions: 7.1.1.Final
Reporter: Dominik Pospisil
Assignee: Brian Stansberry
It seems to me that it is impossible to configure slave HC to connect to master DC using configured secret key.
When slave HC is trying to reach remote DC it fails with:
[Host Controller] 13:11:55,573 ERROR [org.jboss.remoting.remote.connection] (Remoting "f16:MANAGEMENT" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
[Host Controller] 13:11:55,606 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010901: Could not connect to master. Aborting. Error was: java.lang.IllegalStateException: JBAS010942: Unable to connect due to authentication failure.
[Host Controller] 13:11:55,690 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015950: JBoss AS 7.1.1.Final-SNAPSHOT "Thunder" stopped in 38ms
I am using stock domain.xml, host-master.xml and host-slave.xml updated according this documentation:
https://docs.jboss.org/author/display/AS71/Securing+the+Management+Interf...
1) I have added slave/slavepassword user to ManagementRealm
2) U have updated host-slave.xml to identify as "slave"
3) I have generated base64 encoded "slavepassword" passphrase and added as a secret key to host-slave.xml
--
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, 2 months
[JBoss JIRA] (AS7-3884) Load testing application with Jmeter & jboss remoting throws exception saying "Too many channels open"
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/AS7-3884?page=com.atlassian.jira.plugin.s... ]
jaikiran pai commented on AS7-3884:
-----------------------------------
{quote}
JNDI should not be creating a new channel per context
{quote}
Yeah, that's a good point. The initial context actually caches connections (per URI, connection options and other key combination). So it should just create a channel for the cached connection once and reuse it. I'll come up with a patch and get it reviewed by John.
> Load testing application with Jmeter & jboss remoting throws exception saying "Too many channels open"
> ------------------------------------------------------------------------------------------------------
>
> Key: AS7-3884
> URL: https://issues.jboss.org/browse/AS7-3884
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB, Naming
> Affects Versions: 7.1.0.Final
> Environment: windows 64 bit
> Reporter: Prasad Deshpande
> Assignee: jaikiran pai
>
> I've created a sampler for JMeter for load testing application. When I ran that with say around 30 threads with rampup time 80 seconds, after a while I kept getting exception specified in https://community.jboss.org/thread/195709?tstart=0. I later tried to close InitialContext in teardown methods, but wasn't really helpful. I looked at no. of InitialContext intances present in the VM using visualvm heapdump & found that just before throwing exception, it was 24 & after throwing exception for all threads, it did reach to 30, but it wasn't useful..
> Please note that, I'm creating InitialContext with passing following parameters to it:
> java.naming.factory.url.pkgs=org.jboss.ejb.client.naming
> java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
> java.naming.provider.url=remote://localhost:4447
> jboss.naming.client.ejb.context=true
> Here is the code for Java Sampler
> {code}
> package com;
> import org.apache.jmeter.config.Arguments;
> import org.apache.jmeter.protocol.java.sampler.AbstractJavaSamplerClient;
> import org.apache.jmeter.protocol.java.sampler.JavaSamplerContext;
> import org.apache.jmeter.samplers.SampleResult;
> import com.banctec.caseware.client.api.API;
> import com.banctec.caseware.client.api.RemoteClientAPI;
> import com.banctec.caseware.resources.CaseResource;
> import com.banctec.caseware.resources.LoginResource;
> import com.banctec.caseware.resources.Resource;
> public class EJBTest extends AbstractJavaSamplerClient {
> private API api = null;
> private Long typeId;
> private int setupTestCalled = 0;
> private int teardownTestCalled = 0;
> private int runTestCalled = 0;
>
> public Arguments getDefaultParameters() {
> Arguments defaultParameters = new Arguments();
> defaultParameters.addArgument("typeId", "1");
> defaultParameters.addArgument("RunLoop", "200");
> defaultParameters.addArgument("username", "abc");
> defaultParameters.addArgument("password", "abc");
> return defaultParameters;
> }
>
> public void setupTest(JavaSamplerContext context) {
> try {
> typeId = context.getLongParameter("typeId");
> api = new RemoteClientAPI();//this is where InitialContext gets created
> LoginResource loginResource = new LoginResource(context.getParameter("username"), context.getParameter("password"));
> loginResource.setUseDefaultRole(Boolean.valueOf(true));
> api.login(new Resource[] { loginResource });
> }catch (Exception e) {
> e.printStackTrace();
> }
> System.out.println(" Number of times setupTest called "+(++setupTestCalled));
> }
>
> public void teardownTest(JavaSamplerContext context) {
> try{
> if (api != null) {
> api.logout();//In this method InitialContext.close() get's called
> }
> }catch (Exception e) {
> e.printStackTrace();
> }
> System.out.println(" Number of times teardownTest called "+(++teardownTestCalled));
> }
>
> public SampleResult runTest(JavaSamplerContext context) {
> SampleResult result = new SampleResult();
> boolean success = true;
> int loopCount = context.getIntParameter("RunLoop");
> result.sampleStart();
> //Here goes the code that will call few business methods on remote EJB's in application
> // I've purposely removed this bit here..
> System.out.println(" Number of times runTest called "+(++runTestCalled));
> result.sampleEnd();
> result.setSuccessful(success);
> return result;
> }
> }
> {code}
--
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, 2 months
[JBoss JIRA] (AS7-3884) Load testing application with Jmeter & jboss remoting throws exception saying "Too many channels open"
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/AS7-3884?page=com.atlassian.jira.plugin.s... ]
David Lloyd commented on AS7-3884:
----------------------------------
JNDI should not be creating a new channel per context. All contexts should be sharing one channel otherwise there's no way to manage flow control for heavy traffic situations.
> Load testing application with Jmeter & jboss remoting throws exception saying "Too many channels open"
> ------------------------------------------------------------------------------------------------------
>
> Key: AS7-3884
> URL: https://issues.jboss.org/browse/AS7-3884
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB, Naming
> Affects Versions: 7.1.0.Final
> Environment: windows 64 bit
> Reporter: Prasad Deshpande
> Assignee: jaikiran pai
>
> I've created a sampler for JMeter for load testing application. When I ran that with say around 30 threads with rampup time 80 seconds, after a while I kept getting exception specified in https://community.jboss.org/thread/195709?tstart=0. I later tried to close InitialContext in teardown methods, but wasn't really helpful. I looked at no. of InitialContext intances present in the VM using visualvm heapdump & found that just before throwing exception, it was 24 & after throwing exception for all threads, it did reach to 30, but it wasn't useful..
> Please note that, I'm creating InitialContext with passing following parameters to it:
> java.naming.factory.url.pkgs=org.jboss.ejb.client.naming
> java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
> java.naming.provider.url=remote://localhost:4447
> jboss.naming.client.ejb.context=true
> Here is the code for Java Sampler
> {code}
> package com;
> import org.apache.jmeter.config.Arguments;
> import org.apache.jmeter.protocol.java.sampler.AbstractJavaSamplerClient;
> import org.apache.jmeter.protocol.java.sampler.JavaSamplerContext;
> import org.apache.jmeter.samplers.SampleResult;
> import com.banctec.caseware.client.api.API;
> import com.banctec.caseware.client.api.RemoteClientAPI;
> import com.banctec.caseware.resources.CaseResource;
> import com.banctec.caseware.resources.LoginResource;
> import com.banctec.caseware.resources.Resource;
> public class EJBTest extends AbstractJavaSamplerClient {
> private API api = null;
> private Long typeId;
> private int setupTestCalled = 0;
> private int teardownTestCalled = 0;
> private int runTestCalled = 0;
>
> public Arguments getDefaultParameters() {
> Arguments defaultParameters = new Arguments();
> defaultParameters.addArgument("typeId", "1");
> defaultParameters.addArgument("RunLoop", "200");
> defaultParameters.addArgument("username", "abc");
> defaultParameters.addArgument("password", "abc");
> return defaultParameters;
> }
>
> public void setupTest(JavaSamplerContext context) {
> try {
> typeId = context.getLongParameter("typeId");
> api = new RemoteClientAPI();//this is where InitialContext gets created
> LoginResource loginResource = new LoginResource(context.getParameter("username"), context.getParameter("password"));
> loginResource.setUseDefaultRole(Boolean.valueOf(true));
> api.login(new Resource[] { loginResource });
> }catch (Exception e) {
> e.printStackTrace();
> }
> System.out.println(" Number of times setupTest called "+(++setupTestCalled));
> }
>
> public void teardownTest(JavaSamplerContext context) {
> try{
> if (api != null) {
> api.logout();//In this method InitialContext.close() get's called
> }
> }catch (Exception e) {
> e.printStackTrace();
> }
> System.out.println(" Number of times teardownTest called "+(++teardownTestCalled));
> }
>
> public SampleResult runTest(JavaSamplerContext context) {
> SampleResult result = new SampleResult();
> boolean success = true;
> int loopCount = context.getIntParameter("RunLoop");
> result.sampleStart();
> //Here goes the code that will call few business methods on remote EJB's in application
> // I've purposely removed this bit here..
> System.out.println(" Number of times runTest called "+(++runTestCalled));
> result.sampleEnd();
> result.setSuccessful(success);
> return result;
> }
> }
> {code}
--
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, 2 months