March 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-3952) ClusteredBeanDeploymentTestCase is not executed

by Radoslav Husar (JIRA)

Radoslav Husar created AS7-3952: ----------------------------------- Summary: ClusteredBeanDeploymentTestCase is not executed Key: AS7-3952 URL: https://issues.jboss.org/browse/AS7-3952 Project: Application Server 7 Issue Type: Bug Components: Clustering, Test Suite Reporter: Radoslav Husar Assignee: Radoslav Husar Priority: Minor Fix For: 7.1.1.Final because of this https://github.com/jbossas/jboss-as/commit/53db4a1ce28f4979f976b852402e40... the ClusteredBeanDeploymentTestCase is not started -- 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, 1 month

1
1
0 / 0

[JBoss JIRA] (AS7-3784) Make the "default-stack" attribute a child of the groups subsystem configuration

by Heiko Braun (JIRA)

Heiko Braun created AS7-3784: -------------------------------- Summary: Make the "default-stack" attribute a child of the groups subsystem configuration Key: AS7-3784 URL: https://issues.jboss.org/browse/AS7-3784 Project: Application Server 7 Issue Type: Bug Components: Domain Management Reporter: Heiko Braun Assignee: Brian Stansberry Fix For: 7.1.1.Final {noformat} <subsystem xmlns="urn:jboss:domain:jgroups:1.1" default-stack="udp"/> {noformat} -- 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, 1 month

3
4
0 / 0

[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: ----------------------------------- Prasad, if in the meantime you want to test this fix, then you can get the snapshot jar from here https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo.... You'll have to update your client classpath to make sure that this new jar gets used. > 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: John Bailey > > 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, 1 month

1
0
0 / 0

[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 reassigned AS7-3884: --------------------------------- Assignee: John Bailey (was: jaikiran pai) Assigning this to John, so that he can close it once it's merged upstream. > 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: John Bailey > > 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, 1 month

1
0
0 / 0

[JBoss JIRA] (JBBUILD-715) Nexus validation should not allow artifacts that depend on untyped dependencies that do not exist as a jar type - becuase those artifacts cannot be used in a maven build (only in gradle)

by Geoffrey De Smet (JIRA)

Geoffrey De Smet created JBBUILD-715: ---------------------------------------- Summary: Nexus validation should not allow artifacts that depend on untyped dependencies that do not exist as a jar type - becuase those artifacts cannot be used in a maven build (only in gradle) Key: JBBUILD-715 URL: https://issues.jboss.org/browse/JBBUILD-715 Project: JBoss Build System Issue Type: Enhancement Components: Artifact Repositories Reporter: Geoffrey De Smet Priority: Critical This is a compatibility problem between Maven and Gradle. This artifact should not have nexus validation: org.jboss.jdocbook:jdocbook-core:jar:1.0.7 It depends on net.sf.docbook:docbook-xml but this does not exist: net.sf.docbook:docbook-xml:jar only this one exists: net.sf.docbook:docbook-xml:pom (or zip IIRC) Because jdocbook-core was build with gradle and gradle is smarter then maven, it figured out to resolve the type to pom/zip as needed. However, when I use jdocbook-core 1.0.7 from a maven build, it crashes: https://github.com/pressgang/maven-jdocbook-plugin/blob/master/pom.xml#L190 -- 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, 1 month

1
1
0 / 0

[JBoss JIRA] (JBRULES-3409) Planner Termination: calculation count

by Geoffrey De Smet (JIRA)

Geoffrey De Smet created JBRULES-3409: ----------------------------------------- Summary: Planner Termination: calculation count Key: JBRULES-3409 URL: https://issues.jboss.org/browse/JBRULES-3409 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-planner Reporter: Geoffrey De Smet Assignee: Geoffrey De Smet Priority: Minor The stepLimit tests are not reliable with limiting tests, it's better to limit the score calculation count. Rename and document stepLimit tests. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-3883) Remove security/auditing/form-auth.war

by Stuart Douglas (JIRA)

Stuart Douglas created AS7-3883: ----------------------------------- Summary: Remove security/auditing/form-auth.war Key: AS7-3883 URL: https://issues.jboss.org/browse/AS7-3883 Project: Application Server 7 Issue Type: Bug Components: Test Suite Affects Versions: 7.1.0.Final Reporter: Stuart Douglas Assignee: Jan Lanik Priority: Critical Fix For: 7.1.1.Final Deployments are build using shrinkwrap. They should not just be be pre-built and then dumped into the resources dir as a binary blob. -- 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, 1 month

2
2
0 / 0

[JBoss JIRA] (AS7-3648) WARNING from CommandAwareRpcDispatcher: Channel Muxer already has a default up handler installed but now it is being overridden

by Radoslav Husar (JIRA)

Radoslav Husar created AS7-3648: ----------------------------------- Summary: WARNING from CommandAwareRpcDispatcher: Channel Muxer already has a default up handler installed but now it is being overridden Key: AS7-3648 URL: https://issues.jboss.org/browse/AS7-3648 Project: Application Server 7 Issue Type: Feature Request Components: Clustering Affects Versions: 7.1.0.CR1, 7.1.0.Final Reporter: Radoslav Husar Assignee: Paul Ferraro Priority: Minor Fix For: 7.1.1.Final Full log: {noformat} WARNING [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (pool-22-thread-3) Channel Muxer already has a default up handler installed (org.jboss.as.clustering.jgroups.ClassLoaderAwareUpHandler@36cdb4f9) but now it is being overridden {noformat} As Paul explains it: Our ChannelService sets a default up handler for a channel which does TCCL swapping. If infinispan uses the channel, it sets its own up handler (overriding ours) and writes that warning to the log if one is already defined. -- 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, 1 month

2
1
0 / 0

[JBoss JIRA] (AS7-3889) Unable to pass smoke tests part of testsuite when specify -Dnode0=<something>

by Pavel Janousek (JIRA)

Pavel Janousek created AS7-3889: ----------------------------------- Summary: Unable to pass smoke tests part of testsuite when specify -Dnode0=<something> Key: AS7-3889 URL: https://issues.jboss.org/browse/AS7-3889 Project: Application Server 7 Issue Type: Bug Components: Test Suite Affects Versions: 7.1.1.Final Reporter: Pavel Janousek Assignee: Andrew Rubinger I'm unable to pass smoke tests part of testsuite. I hope you get the same result when try: {code} ./build.sh clean install [pass] ifconfig lo:1 127.0.0.2 [pass] ./integration-tests.sh install -Dnode0=127.0.0.2 {code} I got: {code} Tests in error: testMessagingClient(org.jboss.as.test.smoke.embedded.demos.client.jms.JmsClientTestCase): java.net.ConnectException: JBAS012144: Could not connect to remote://pjanouse.brq.redhat.com:9999. The connection timed out testMessagingClient(org.jboss.as.test.smoke.embedded.demos.client.messaging.MessagingClientTestCase): Cannot connect to server(s). Tried with all available servers. {code} Also in IPv6 mode like: {code} ./integration-tests.sh install -Dnode0=::1 -Dipv6 {code} I got error, but it differs from above: {code} Tests in error: org.jboss.as.test.smoke.embedded.demos.jms.JmsTestCase: destination address may not be null org.jboss.as.test.smoke.embedded.demos.client.jms.JmsClientTestCase: destination address may not be null org.jboss.as.test.smoke.embedded.demos.client.messaging.MessagingClientTestCase: destination address may not be null org.jboss.as.test.smoke.embedded.demos.messaging.MessagingTestCase: destination address may not be null {code} When I specify -Dnode0=127.0.0.1 as binding address, everything works fine... PS: This state is *after* merging O. Zizka's TS-refactor branch (commit d0f1f3cef0ed90d4b655e5aec15be7b00a373f5c). -- 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, 1 month

3
3
0 / 0

[JBoss JIRA] (AS7-4023) AS7 TS: Intermittent failures "No EJB receiver available" - JBossAppXMLSecurityTestCase, SimpleApplicationClientTestCase

by Ondrej Zizka (JIRA)

[ https://issues.jboss.org/browse/AS7-4023?page=com.atlassian.jira.plugin.s... ] Ondrej Zizka updated AS7-4023: ------------------------------ Affects Version/s: 7.1.1.Final Priority: Major (was: Minor) > AS7 TS: Intermittent failures "No EJB receiver available" - JBossAppXMLSecurityTestCase, SimpleApplicationClientTestCase > ------------------------------------------------------------------------------------------------------------------------ > > Key: AS7-4023 > URL: https://issues.jboss.org/browse/AS7-4023 > Project: Application Server 7 > Issue Type: Bug > Components: EJB, Test Suite > Affects Versions: 7.1.1.Final > Reporter: Ondrej Zizka > Labels: intermittent > > org.jboss.as.test.integration.ejb.security.jbossappxml.JBossAppXMLSecurityTestCase.testEJBRunAs > No EJB receiver available for handling [appName:myapp,modulename:jboss-app-xml-sec,distinctname:] combination > org.jboss.as.test.integration.ee.appclient.basic.SimpleApplicationClientTestCase.simpleAppClientTest > No EJB receiver available for handling [appName:simple-app-client-test,modulename:ejb,distinctname:] combination > https://hudson.qa.jboss.com/hudson/job/AS7-TS-valid-mvn-all-ipv6/36/testR... -- 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, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2012