[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
12 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
12 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
12 years, 2 months
[JBoss JIRA] (JBRULES-3406) Planner: a Solution without a @PlanningEntityCollectionProperty or @PlanningEntityProperty should fail fast with a decent error message.
by Geoffrey De Smet (JIRA)
Geoffrey De Smet created JBRULES-3406:
-----------------------------------------
Summary: Planner: a Solution without a @PlanningEntityCollectionProperty or @PlanningEntityProperty should fail fast with a decent error message.
Key: JBRULES-3406
URL: https://issues.jboss.org/browse/JBRULES-3406
Project: Drools
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: drools-planner
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
Fix For: 5.4.0.CR1
"
I accidently denoted the wrong class with the annotator
@PlanningEntityCollectionProperty ; a class which was NOT a planning entity.
Apparently, Drools Planner does not attempt to check for such a possibility,
hence I get:
{code}
Exception in thread "main" java.lang.NullPointerException
at
org.drools.planner.core.domain.solution.SolutionDescriptor.getAllFacts(SolutionDescriptor.java:135)
at
org.drools.planner.core.solution.director.DefaultSolutionDirector.getWorkingFacts(DefaultSolutionDirector.java:129)
at
org.drools.planner.core.solution.director.DefaultSolutionDirector.resetWorkingMemory(DefaultSolutionDirector.java:123)
at
org.drools.planner.core.solution.director.DefaultSolutionDirector.setWorkingSolution(DefaultSolutionDirector.java:97)
at
org.drools.planner.core.solver.DefaultSolver.setPlanningProblem(DefaultSolver.java:97)
at in.co.technovia.examduties.ExamDutiesApp.main(ExamDutiesApp.java:47)
{code}
Please check for such a possibility in future versions of Drools Planner and
emit a more meaningful error message.
"
--
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
12 years, 2 months
[JBoss JIRA] (AS7-4011) TS: Bad approach used as fallback mechanism for gathering IP address
by Pavel Janousek (JIRA)
[ https://issues.jboss.org/browse/AS7-4011?page=com.atlassian.jira.plugin.s... ]
Pavel Janousek moved JBPAPP-8338 to AS7-4011:
---------------------------------------------
Project: Application Server 7 (was: JBoss Enterprise Application Platform)
Key: AS7-4011 (was: JBPAPP-8338)
Workflow: GIT Pull Request workflow (was: jira)
Affects Version/s: 7.1.1.Final
(was: EAP 6.0.0 ER 2)
Component/s: Test Suite
(was: Testsuite)
(was: IPv6 support)
Security: (was: JBoss Internal)
Docs QE Status: (was: NEW)
> 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: Bug
> Components: Test Suite
> Affects Versions: 7.1.1.Final
> Reporter: Pavel Janousek
> Assignee: Ondrej Zizka
> Priority: Blocker
>
> 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
12 years, 2 months
[JBoss JIRA] (AS7-4005) mod_cluster error on boot "ERROR [org.jboss.as.modcluster] (MSC service thread 1-5) JBAS011703: Mod_cluster requires Advertise but Multicast interface is not available"
by Radoslav Husar (JIRA)
Radoslav Husar created AS7-4005:
-----------------------------------
Summary: mod_cluster error on boot "ERROR [org.jboss.as.modcluster] (MSC service thread 1-5) JBAS011703: Mod_cluster requires Advertise but Multicast interface is not available"
Key: AS7-4005
URL: https://issues.jboss.org/browse/AS7-4005
Project: Application Server 7
Issue Type: Bug
Components: Clustering
Affects Versions: No Release
Reporter: Radoslav Husar
Assignee: Paul Ferraro
Fix For: 7.1.1.Final
{noformat}
05:41:40,201 INFO [org.jboss.as.mail.extension] (MSC service thread 1-5) JBAS015400: Bound mail session [java:jboss/mail/Default]
05:41:40,233 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) JBAS015537: Activating WebServices Extension
05:41:40,253 INFO [org.jboss.as.security] (MSC service thread 1-4) JBAS013100: Current PicketBox version=4.0.6.final-redhat-1
05:41:40,603 ERROR [org.jboss.as.modcluster] (MSC service thread 1-5) JBAS011703: Mod_cluster requires Advertise but Multicast interface is not available
05:41:40,604 INFO [org.jboss.as.modcluster] (MSC service thread 1-5) JBAS011704: Mod_cluster uses default load balancer provider
05:41:40,724 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-7) Starting Coyote HTTP/1.1 on http--127.0.0.1-8080
05:41:40,730 INFO [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-2) JBoss Web Services - Stack CXF Server 4.0.1.GA-redhat-1
05:41:40,743 INFO [org.jboss.modcluster.ModClusterService] (MSC service thread 1-5) Initializing mod_cluster 1.2.0.Final-redhat-1
05:41:40,819 INFO [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (MSC service thread 1-5) Listening to proxy advertisements on 224.0.1.105:23364
05:41:40,843 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 39) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be pasivated.
{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
12 years, 2 months
[JBoss JIRA] (AS7-3964) Running IPv6 clustering tests results in [UDP] failed sending message to cluster (69 bytes): java.lang.Exception: dest=/ff0e:0:0:0:0:0:e600:4:45688 (72 bytes), cause: java.io.IOException: Network is unreachable
by Radoslav Husar (JIRA)
Radoslav Husar created AS7-3964:
-----------------------------------
Summary: Running IPv6 clustering tests results in [UDP] failed sending message to cluster (69 bytes): java.lang.Exception: dest=/ff0e:0:0:0:0:0:e600:4:45688 (72 bytes), cause: java.io.IOException: Network is unreachable
Key: AS7-3964
URL: https://issues.jboss.org/browse/AS7-3964
Project: Application Server 7
Issue Type: Task
Components: Clustering, Test Suite
Affects Versions: 7.1.0.Final
Reporter: Radoslav Husar
Assignee: Paul Ferraro
Fix For: 7.1.1.Final
Attachments: ipv6log.txt
Binding to IPv6 address is OK but multicast communication fails.
We need to figure out whats causing this, should be just missing configuration.
{noformat}
04:06:22,794 INFO [stdout] (pool-19-thread-1)
04:06:22,801 INFO [stdout] (pool-19-thread-1) -------------------------------------------------------------------
04:06:22,802 INFO [stdout] (pool-19-thread-1) GMS: address=node-udp-1/ejb, cluster=ejb, physical address=0:0:0:0:0:0:0:1:55300
04:06:22,802 INFO [stdout] (pool-19-thread-1) -------------------------------------------------------------------
04:06:22,811 SEVERE [org.jgroups.protocols.UDP] (pool-19-thread-1) failed sending message to cluster (107 bytes): java.lang.Exception: dest=/ff0e:0:0:0:0:0:e600:4:45688 (110 bytes), cause: java.io.IOException: Network is unreachable
04:06:22,836 INFO [stdout] (pool-14-thread-1)
04:06:22,845 INFO [stdout] (pool-14-thread-1) -------------------------------------------------------------------
04:06:22,846 INFO [stdout] (pool-14-thread-1) GMS: address=node-udp-1/web, cluster=web, physical address=0:0:0:0:0:0:0:1:55300
04:06:22,846 INFO [stdout] (pool-14-thread-1) -------------------------------------------------------------------
04:06:22,860 SEVERE [org.jgroups.protocols.UDP] (pool-14-thread-1) failed sending message to cluster (107 bytes): java.lang.Exception: dest=/ff0e:0:0:0:0:0:e600:4:45688 (110 bytes), cause: java.io.IOException: Network is unreachable
04:06:23,577 SEVERE [org.jgroups.protocols.UDP] (Timer-4,<ADDR>) failed sending message to cluster (69 bytes): java.lang.Exception: dest=/ff0e:0:0:0:0:0:e600:4:45688 (72 bytes), cause: java.io.IOException: Network is unreachable
04:06:24,405 SEVERE [org.jgroups.protocols.UDP] (Timer-2,<ADDR>) failed sending message to cluster (69 bytes): java.lang.Exception: dest=/ff0e:0:0:0:0:0:e600:4:45688 (72 bytes), cause: java.io.IOException: Network is unreachable
04:06:25,795 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-5) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be pasivated.
04:06:25,810 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-2) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be pasivated.
04:06:25,829 INFO [org.infinispan.config.ConfigurationValidatingVisitor] (pool-15-thread-1) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be pasivated.
04:06:26,044 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (pool-15-thread-1) ISPN000078: Starting JGroups Channel
04:06:26,044 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (pool-20-thread-1) ISPN000078: Starting JGroups Channel
04:06:26,059 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (pool-15-thread-1) ISPN000094: Received new cluster view: [node-udp-1/web|0] [node-udp-1/web]
04:06:26,059 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (pool-20-thread-1) ISPN000094: Received new cluster view: [node-udp-1/ejb|0] [node-udp-1/ejb]
04:06:26,061 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (pool-15-thread-1) ISPN000079: Cache local address is node-udp-1/web, physical addresses are [0:0:0:0:0:0:0:1:55300]
04:06:26,062 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (pool-20-thread-1) ISPN000079: Cache local address is node-udp-1/ejb, physical addresses are [0:0:0:0:0:0:0:1:55300]
04:06:26,130 INFO [org.infinispan.factories.GlobalComponentRegistry] (pool-15-thread-1) ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.1.FINAL
04:06:26,131 INFO [org.infinispan.factories.GlobalComponentRegistry] (pool-20-thread-1) ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.1.FINAL
{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
12 years, 2 months