[JBoss JIRA] (AS7-2779) Regression in AS7-1242 -- arquillian-service is only deployed to first container in group
by Radoslav Husar (Created) (JIRA)
Regression in AS7-1242 -- arquillian-service is only deployed to first container in group
-----------------------------------------------------------------------------------------
Key: AS7-2779
URL: https://issues.jboss.org/browse/AS7-2779
Project: Application Server 7
Issue Type: Bug
Components: Test Suite
Affects Versions: 7.1.0.Beta1
Reporter: Radoslav Husar
Assignee: Andrew Rubinger
Priority: Blocker
Fix For: 7.1.0.CR1
Blocker for clustering tests.
{code}
/*
* JBoss, Home of Professional Open Source.
* Copyright 2011, Red Hat, Inc., and individual contributors
* as indicated by the @author tags. See the copyright.txt file in the
* distribution for a full listing of individual contributors.
*
* This is free software; you can redistribute it and/or modify it
* under the terms of the GNU Lesser General Public License as
* published by the Free Software Foundation; either version 2.1 of
* the License, or (at your option) any later version.
*
* This software is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this software; if not, write to the Free
* Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
* 02110-1301 USA, or see the FSF site: http://www.fsf.org.
*/
package org.jboss.as.test.clustering.cluster;
import java.io.IOException;
import java.net.URL;
import java.util.Properties;
import javax.servlet.http.HttpServletResponse;
import org.apache.http.HttpResponse;
import org.apache.http.client.ClientProtocolException;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.impl.client.DefaultHttpClient;
import org.jboss.arquillian.container.test.api.Deployment;
import org.jboss.arquillian.container.test.api.OperateOnDeployment;
import org.jboss.arquillian.container.test.api.RunAsClient;
import org.jboss.arquillian.container.test.api.TargetsContainer;
import org.jboss.arquillian.junit.Arquillian;
import org.jboss.arquillian.test.api.ArquillianResource;
import org.jboss.as.test.clustering.single.web.SimpleServlet;
import org.jboss.shrinkwrap.api.Archive;
import org.jboss.shrinkwrap.api.ShrinkWrap;
import org.jboss.shrinkwrap.api.spec.WebArchive;
import org.junit.Assert;
import org.junit.BeforeClass;
import org.junit.Test;
import org.junit.runner.RunWith;
/**
* Validate the <distributable/> works for single node
* @author Paul Ferraro
*/
@RunWith(Arquillian.class)
@RunAsClient
public class ClusteredWebTestCase {
@BeforeClass
public static void printSysProps() {
Properties sysprops = System.getProperties() ;
// System.out.println("system properties:\n" + sysprops) ;
}
@Deployment(name="deployment-0")
@TargetsContainer("clustering-udp-0")
public static Archive<?> deployment() {
WebArchive war = ShrinkWrap.create(WebArchive.class, "distributable.war");
war.addClass(SimpleServlet.class);
war.addAsWebInfResource(ClusteredWebTestCase.class.getPackage(), "web.xml");
System.out.println(war.toString(true));
return war;
}
@Deployment(name="deployment-1")
@TargetsContainer("clustering-udp-1")
public static Archive<?> deployment2() {
WebArchive war = ShrinkWrap.create(WebArchive.class, "distributable.war");
war.addClass(SimpleServlet.class);
war.addAsWebInfResource(ClusteredWebTestCase.class.getPackage(), "web.xml");
System.out.println(war.toString(true));
return war;
}
@Test
@OperateOnDeployment("deployment-1")
public void test((a)ArquillianResource(SimpleServlet.class)URL baseURL) throws ClientProtocolException, IOException {
DefaultHttpClient client = new DefaultHttpClient();
// returns the URL of the deployment (http://127.0.0.1:8180/distributable)
String url = baseURL.toString();
System.out.println("URL = " + url);
try {
HttpResponse response = client.execute(new HttpGet(url+"simple"));
Assert.assertEquals(HttpServletResponse.SC_OK, response.getStatusLine().getStatusCode());
Assert.assertEquals(Integer.parseInt(response.getFirstHeader("value").getValue()), 1);
Assert.assertFalse(Boolean.valueOf(response.getFirstHeader("serialized").getValue()));
response.getEntity().getContent().close();
response = client.execute(new HttpGet(url+"simple"));
Assert.assertEquals(HttpServletResponse.SC_OK, response.getStatusLine().getStatusCode());
Assert.assertEquals(Integer.parseInt(response.getFirstHeader("value").getValue()), 2);
// This won't be true unless we have somewhere to which to replicate
Assert.assertFalse(Boolean.valueOf(response.getFirstHeader("serialized").getValue()));
response.getEntity().getContent().close();
} finally {
client.getConnectionManager().shutdown();
}
}
}
{code}
ARQ XML
{code}
<?xml version="1.0" encoding="UTF-8"?>
<arquillian xmlns="http://www.jboss.org/arquillian-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.jboss.org/arquillian-1.0 http://jboss.org/schema/arquillian/arquillian-1.0.xsd">
<container qualifier="clustering-udp-single" default="true">
<configuration>
<property name="jbossHome">${basedir}/target/clustering-udp-0</property>
<property name="javaVmArguments">${server.jvm.args} -Djboss.inst=${basedir}/target/clustering-udp-0</property>
<property name="serverConfig">${server.config:standalone.xml}</property>
</configuration>
</container>
<group qualifier="clustering-udp">
<container qualifier="clustering-udp-0" default="true">
<configuration>
<property name="jbossHome">${basedir}/target/clustering-udp-0</property>
<property name="javaVmArguments">${server.jvm.args} -Djboss.inst=${basedir}/target/clustering-udp-0</property>
<property name="serverConfig">${server.config:standalone-ha.xml}</property>
</configuration>
</container>
<container qualifier="clustering-udp-1" default="false">
<configuration>
<property name="jbossHome">${basedir}/target/clustering-udp-1</property>
<property name="javaVmArguments">${server.jvm.args} -Djboss.inst=${basedir}/target/clustering-udp-1 -Djboss.port.offset=100</property>
<property name="serverConfig">${server.config:standalone-ha.xml}</property>
<property name="managementPort">10099</property>
</configuration>
</container>
</group>
</arquillian>
{code}
server.log
{code}
15:53:30,663 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) Starting deployment of "distributable.war"
15:53:30,887 INFO [org.jboss.as.server.controller] (pool-1-thread-1) Deployment of "distributable.war" was rolled back with failure message {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"distributable.war\".POST_MODULEjboss.module.spec.service.\"deployment.arquillian-service\".mainMissing[jboss.deployment.unit.\"distributable.war\".POST_MODULEjboss.module.spec.service.\"deployment.arquillian-service\".main]","jboss.module.service.\"deployment.distributable.war\".mainjboss.module.spec.service.\"deployment.arquillian-service\".mainMissing[jboss.module.service.\"deployment.distributable.war\".mainjboss.module.spec.service.\"deployment.arquillian-service\".main]"]}
15:53:30,896 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) Stopped deployment distributable.war in 9ms
15:53:30,897 INFO [org.jboss.as.controller] (pool-1-thread-1) JBAS014774: Service status report
JBAS014775: New missing/unsatisfied dependencies:
service jboss.module.spec.service."deployment.arquillian-service".main (missing) dependents: [service jboss.deployment.unit."distributable.war".POST_MODULE, service jboss.module.service."deployment.distributable.war".main]
15:53:30,983 ERROR [org.jboss.as.controller] (pool-1-thread-1) JBAS014612: Operation ("undeploy") failed - address: ([("deployment" => "distributable.war")]): java.util.NoSuchElementException: No child 'runtime-name' exists
at org.jboss.dmr.ModelValue.requireChild(ModelValue.java:362) [jboss-dmr-1.1.0.Final.jar:]
at org.jboss.dmr.ModelNode.require(ModelNode.java:812) [jboss-dmr-1.1.0.Final.jar:]
at org.jboss.as.server.deployment.DeploymentUndeployHandler.execute(DeploymentUndeployHandler.java:58)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:322) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:216) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:152) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.CompositeOperationHandler.execute(CompositeOperationHandler.java:84) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:322) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:216) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:152) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.ModelControllerImpl$DefaultPrepareStepHandler.execute(ModelControllerImpl.java:426) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:322) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:216) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:152) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doProcessRequest(ModelControllerClientOperationHandler.java:158) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$100(ModelControllerClientOperationHandler.java:89) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.call(ModelControllerClientOperationHandler.java:118) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.call(ModelControllerClientOperationHandler.java:116) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_29]
at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_29]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_29]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_29]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_29]
15:53:31,157 INFO [org.apache.catalina.core.StandardContext] (MSC service thread 1-1) Container org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/] has not been started
15:53:31,159 INFO [org.jboss.as.deployment.connector] (MSC service thread 1-1) JBAS010410: Unbound JCA ConnectionFactory [java:/JmsXA]
{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, 3 months
[JBoss JIRA] (AS7-2903) Cluster suspected to perform 100x slower than unclustered
by Radoslav Husar (Created) (JIRA)
Cluster suspected to perform 100x slower than unclustered
---------------------------------------------------------
Key: AS7-2903
URL: https://issues.jboss.org/browse/AS7-2903
Project: Application Server 7
Issue Type: Bug
Components: Clustering
Affects Versions: No Release
Environment: eaebc8a0041e2c7bd9b7de93ea2d2bf87701abff
Reporter: Radoslav Husar
Assignee: Paul Ferraro
Priority: Critical
Fix For: 7.1.0.CR1
Cluster performs 100x slower than unclustered when using HTTP session replication benchmark in our perf lab. Throughput with 200 clients drops from 49,851.0 r/s to 425.3 samples/s when using clustering in standalone-ha.xml server configuration. I cannot guarantee the runs, this might be a result of a hidden networking issue in the lab.
Here are some sample runs:
*Unclustered*
{noformat}
Nodes: 2, Sessions: 100, active: 100, samples: 680317, throughput 45,346.9 samples/s, 0.2 MB/s, mean response: 2 ms, sampling errors: 0, invalid samples: 0, valid samples: 680317 (100%)
Nodes: 2, Sessions: 200, active: 200, samples: 747890, throughput 49,851.0 samples/s, 0.2 MB/s, mean response: 3 ms, sampling errors: 0, invalid samples: 0, valid samples: 747890 (100%)
Nodes: 2, Sessions: 300, active: 300, samples: 722338, throughput 48,149.4 samples/s, 0.2 MB/s, mean response: 6 ms, sampling errors: 0, invalid samples: 0, valid samples: 722338 (100%)
Nodes: 2, Sessions: 400, active: 400, samples: 702323, throughput 46,813.7 samples/s, 0.2 MB/s, mean response: 8 ms, sampling errors: 0, invalid samples: 0, valid samples: 702323 (100%)
Nodes: 2, Sessions: 500, active: 500, samples: 690571, throughput 46,028.9 samples/s, 0.2 MB/s, mean response: 10 ms, sampling errors: 0, invalid samples: 0, valid samples: 690571 (100%)
Nodes: 2, Sessions: 600, active: 600, samples: 689405, throughput 45,949.6 samples/s, 0.2 MB/s, mean response: 13 ms, sampling errors: 0, invalid samples: 0, valid samples: 689405 (100%)
Nodes: 2, Sessions: 700, active: 700, samples: 681118, throughput 45,400.3 samples/s, 0.2 MB/s, mean response: 15 ms, sampling errors: 0, invalid samples: 0, valid samples: 681118 (100%)
Nodes: 2, Sessions: 800, active: 800, samples: 685431, throughput 45,684.7 samples/s, 0.2 MB/s, mean response: 16 ms, sampling errors: 0, invalid samples: 0, valid samples: 685431 (100%)
Nodes: 2, Sessions: 900, active: 900, samples: 668869, throughput 44,580.9 samples/s, 0.2 MB/s, mean response: 20 ms, sampling errors: 0, invalid samples: 0, valid samples: 668869 (100%)
Nodes: 2, Sessions: 1000, active: 1000, samples: 675849, throughput 45,046.1 samples/s, 0.2 MB/s, mean response: 21 ms, sampling errors: 0, invalid samples: 0, valid samples: 675849 (100%)
{noformat}
*Clustered*
{noformat}
Nodes: 2, Sessions: 100, active: 100, samples: 7350, throughput 489.9 samples/s, 0.0 MB/s, mean response: 196 ms, sampling errors: 0, invalid samples: 49, valid samples: 7301 (99%)
Nodes: 2, Sessions: 200, active: 200, samples: 6380, throughput 425.3 samples/s, 0.0 MB/s, mean response: 458 ms, sampling errors: 0, invalid samples: 362, valid samples: 6018 (94%)
Nodes: 2, Sessions: 300, active: 300, samples: 5821, throughput 382.4 samples/s, 0.0 MB/s, mean response: 748 ms, sampling errors: 0, invalid samples: 484, valid samples: 5337 (91%)
Nodes: 2, Sessions: 400, active: 262, samples: 3846, throughput 256.3 samples/s, 0.0 MB/s, mean response: 1056 ms, sampling errors: 0, invalid samples: 333, valid samples: 3513 (91%)
Nodes: 2, Sessions: 500, active: 452, samples: 6389, throughput 425.6 samples/s, 0.0 MB/s, mean response: 1104 ms, sampling errors: 0, invalid samples: 565, valid samples: 5824 (91%)
Nodes: 2, Sessions: 600, active: 55, samples: 985, throughput 65.7 samples/s, 0.0 MB/s, mean response: 1590 ms, sampling errors: 457, invalid samples: 55, valid samples: 473 (48%)
{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, 3 months
[JBoss JIRA] (AS7-2898) Broken JGroups in clustering RuntimeException: class for magic number 22551 not found
by Radoslav Husar (Created) (JIRA)
Broken JGroups in clustering RuntimeException: class for magic number 22551 not found
-------------------------------------------------------------------------------------
Key: AS7-2898
URL: https://issues.jboss.org/browse/AS7-2898
Project: Application Server 7
Issue Type: Bug
Components: Clustering
Affects Versions: No Release
Environment: eaebc8a0041e2c7bd9b7de93ea2d2bf87701abff
Reporter: Radoslav Husar
Assignee: Paul Ferraro
{code}
[JBossINF] 09:28:49,124 SEVERE [org.jgroups.protocols.UDP] (Incoming-9,null) failed handling incoming message: java.lang.RuntimeException: class for magic number 22551 not found
[JBossINF] at org.jgroups.util.Util.readOtherAddress(Util.java:847) [jgroups-3.0.0.Final.jar:]
[JBossINF] at org.jgroups.util.Util.readAddress(Util.java:811) [jgroups-3.0.0.Final.jar:]
[JBossINF] at org.jgroups.util.Util.readAddresses(Util.java:896) [jgroups-3.0.0.Final.jar:]
[JBossINF] at org.jgroups.protocols.pbcast.GMS$GmsHeader.readFrom(GMS.java:1163) [jgroups-3.0.0.Final.jar:]
[JBossINF] at org.jgroups.Message.readHeader(Message.java:837) [jgroups-3.0.0.Final.jar:]
[JBossINF] at org.jgroups.Message.readFrom(Message.java:727) [jgroups-3.0.0.Final.jar:]
[JBossINF] at org.jgroups.protocols.TP.readMessage(TP.java:1326) [jgroups-3.0.0.Final.jar:]
[JBossINF] at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1690) [jgroups-3.0.0.Final.jar:]
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_29]
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_29]
[JBossINF] at java.lang.Thread.run(Thread.java:662) [:1.6.0_29]
[JBossINF]
[JBossINF] 09:28:55,674 WARNING [org.jgroups.protocols.pbcast.NAKACK] (Incoming-11,null) perf20/web: dropped message 1 from perf21/web (sender not in table [perf20/web, perf01/web, perf03/web]), view=[perf01/web|12] [perf01/web, perf03/web, perf20/web]
[JBossINF] 09:28:56,666 SEVERE [org.jgroups.protocols.UDP] (OOB-18,null) failed handling incoming message: java.io.IOException: length has to be 4 or 16 bytes (was 1 bytes)
[JBossINF] at org.jgroups.stack.IpAddress.readFrom(IpAddress.java:190) [jgroups-3.0.0.Final.jar:]
[JBossINF] at org.jgroups.util.Util.readAddress(Util.java:808) [jgroups-3.0.0.Final.jar:]
[JBossINF] at org.jgroups.util.Util.readAddresses(Util.java:896) [jgroups-3.0.0.Final.jar:]
[JBossINF] at org.jgroups.protocols.PingData.readFrom(PingData.java:162) [jgroups-3.0.0.Final.jar:]
[JBossINF] at org.jgroups.util.Util.readStreamable(Util.java:936) [jgroups-3.0.0.Final.jar:]
[JBossINF] at org.jgroups.protocols.PingHeader.readFrom(PingHeader.java:88) [jgroups-3.0.0.Final.jar:]
[JBossINF] at org.jgroups.Message.readHeader(Message.java:837) [jgroups-3.0.0.Final.jar:]
[JBossINF] at org.jgroups.Message.readFrom(Message.java:727) [jgroups-3.0.0.Final.jar:]
[JBossINF] at org.jgroups.protocols.TP.readMessage(TP.java:1326) [jgroups-3.0.0.Final.jar:]
[JBossINF] at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1690) [jgroups-3.0.0.Final.jar:]
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_29]
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_29]
[JBossINF] at java.lang.Thread.run(Thread.java:662) [:1.6.0_29]
[JBossINF]
[JBossINF] 09:28:56,666 SEVERE [org.jgroups.protocols.UDP] (OOB-17,null) failed handling incoming message: java.io.IOException: length has to be 4 or 16 bytes (was 1 bytes)
[JBossINF] at org.jgroups.stack.IpAddress.readFrom(IpAddress.java:190) [jgroups-3.0.0.Final.jar:]
[JBossINF] at org.jgroups.util.Util.readAddress(Util.java:808) [jgroups-3.0.0.Final.jar:]
[JBossINF] at org.jgroups.util.Util.readAddresses(Util.java:896) [jgroups-3.0.0.Final.jar:]
[JBossINF] at org.jgroups.protocols.PingData.readFrom(PingData.java:162) [jgroups-3.0.0.Final.jar:]
[JBossINF] at org.jgroups.util.Util.readStreamable(Util.java:936) [jgroups-3.0.0.Final.jar:]
[JBossINF] at org.jgroups.protocols.PingHeader.readFrom(PingHeader.java:88) [jgroups-3.0.0.Final.jar:]
[JBossINF] at org.jgroups.Message.readHeader(Message.java:837) [jgroups-3.0.0.Final.jar:]
[JBossINF] at org.jgroups.Message.readFrom(Message.java:727) [jgroups-3.0.0.Final.jar:]
[JBossINF] at org.jgroups.protocols.TP.readMessage(TP.java:1326) [jgroups-3.0.0.Final.jar:]
[JBossINF] at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1690) [jgroups-3.0.0.Final.jar:]
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_29]
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_29]
[JBossINF] at java.lang.Thread.run(Thread.java:662) [:1.6.0_29]
{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, 3 months
[JBoss JIRA] Created: (JBAS-8135) By default use a common identifier anywhere a server "id" notion is exposed in the configuration
by Brian Stansberry (JIRA)
By default use a common identifier anywhere a server "id" notion is exposed in the configuration
------------------------------------------------------------------------------------------------
Key: JBAS-8135
URL: https://jira.jboss.org/browse/JBAS-8135
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 7.0.0.M1
This JIRA is based on feedback we received after the Andiamo BOF at JBoss World 2010:
>> * JBoss Transactions, jvm-route, jboss messaging all require a
>> unique identifier for them to behave properly in a clustered
>> environment. I would like one unique identifier for each server
>> configuration and for all services that need a unique identifier
>> to reference it by default. Then I don't have to worry about
>> unique identifiers when creating new servers.
(The jboss messaging bit is out of date with respect to AS 7, which will use HornetQ and thus has no ServerPeerId configuration required. But the basic point is spot-on.)
--
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, 3 months
[JBoss JIRA] (AS7-2604) Http API : jndi-view and dump-services operations showing errors, browser waiting indefinitely - need to return a proper error message
by Vimal Kansal (Created) (JIRA)
Http API : jndi-view and dump-services operations showing errors, browser waiting indefinitely - need to return a proper error message
--------------------------------------------------------------------------------------------------------------------------------------
Key: AS7-2604
URL: https://issues.jboss.org/browse/AS7-2604
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Reporter: Vimal Kansal
Assignee: Brian Stansberry
Yes please report this as a bug that we do not return a proper error message.
As to custom operations, for security reasons we have to make sure that GET can never mutate production state, since browsers operate on that assumption. For this reason we have limited GET to our universal read operations, and do not have support for custom operations. We could support an arbitrary runtime operation, but only IF we had a special flag that reported it as being read-only.
On 11/11/11 3:01 AM, Vimal Kansal wrote:
> So you mean to say, if I try executing a subsystem specific
> operation(i.e a get) on any other subsystem, I should get a similar
> error? Moreover, even with this jndi-view operation, browser just seems
> to be waiting for response to come back, it does not show any error
> message. I think we need a clear indication of what is supported and
> what is not supported. In our doc also we should try to clarify it that
> Http API is not an exact replica of what we can achieve through CLI.
> Ideally I would have loved to be able to do whatever I can do with CLI.
>
> On 11/11/2011 7:20 PM, Darran Lofthouse wrote:
>> Yes I don't think this is invalid, although I do see some problems
>> regarding how we could implement this. At the moment it is literally
>> just the global operations that we allow to be called but operations
>> like this are subsystem specific.
>>
>> Maybe get a feature request raised for this to be further considered.
>>
>> Regards,
>> Darran Lofthouse.
>>
>>
>> On 11/11/2011 08:15 AM, Vimal Kansal wrote:
>>> Thanks Darran. Semantically, don't you think dump-services is really a
>>> get(i.e read) operation?
>>>
>>> On 11/11/2011 7:13 PM, Darran Lofthouse wrote:
>>>> Hi Vimal,
>>>>
>>>> Using GET requests only a small subset of the read only operations are
>>>> available, this operation would need to be invoked as a POST request
>>>> from an external client.
>>>>
>>>> Regards,
>>>> Darran Lofthouse.
>>>>
>>>>
>>>> On 11/11/2011 04:20 AM, Vimal Kansal wrote:
>>>>> Hi,
>>>>>
>>>>> I am trying to use Http API to display the JNDI view (which I am ble to
>>>>> get via CLI alright) by pointing my browser as
>>>>> http://localhost:9990/management/subsystem/naming?operation=jndi-view
>>>>> and I get the following error :
>>>>>
>>>>> 15:16:53,086 ERROR [stderr] (HttpManagementService-threads - 1)
>>>>> Exception in thread "HttpManagementService-threads - 1"
>>>>> java.lang.ExceptionInInitializerError
>>>>> 15:16:53,087 ERROR [stderr] (HttpManagementService-threads - 1)
>>>>> at
>>>>> org.jboss.as.domain.http.server.DomainApiHandler.convertGetRequest(DomainApiHandler.java:422)
>>>>> 15:16:53,088 ERROR [stderr] (HttpManagementService-threads - 1)
>>>>> at
>>>>> org.jboss.as.domain.http.server.DomainApiHandler.processRequest(DomainApiHandler.java:263)
>>>>> 15:16:53,089 ERROR [stderr] (HttpManagementService-threads - 1)
>>>>> at
>>>>> org.jboss.as.domain.http.server.DomainApiHandler.handle(DomainApiHandler.java:191)
>>>>> 15:16:53,091 ERROR [stderr] (HttpManagementService-threads - 1)
>>>>> at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
>>>>> 15:16:53,093 ERROR [stderr] (HttpManagementService-threads - 1)
>>>>> at org.jboss.sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:69)
>>>>> 15:16:53,095 ERROR [stderr] (HttpManagementService-threads - 1)
>>>>> at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
>>>>> 15:16:53,096 ERROR [stderr] (HttpManagementService-threads - 1)
>>>>> at
>>>>> org.jboss.sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:689)
>>>>> 15:16:53,097 ERROR [stderr] (HttpManagementService-threads - 1)
>>>>> at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
>>>>> 15:16:53,098 ERROR [stderr] (HttpManagementService-threads - 1)
>>>>> at org.jboss.sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:661)
>>>>> 15:16:53,099 ERROR [stderr] (HttpManagementService-threads - 1)
>>>>> at
>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>>>>> 15:16:53,100 ERROR [stderr] (HttpManagementService-threads - 1)
>>>>> at
>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>>>>> 15:16:53,101 ERROR [stderr] (HttpManagementService-threads - 1)
>>>>> at java.lang.Thread.run(Thread.java:662)
>>>>> 15:16:53,102 ERROR [stderr] (HttpManagementService-threads - 1)
>>>>> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
>>>>> 15:16:53,103 ERROR [stderr] (HttpManagementService-threads - 1) Caused
>>>>> by: java.lang.IllegalArgumentException: Invalid bundle interface
>>>>> org.jboss.as.domain.http.server.HttpServerMessages (implementati
>>>>> on not found)
>>>>> 15:16:53,103 ERROR [stderr] (HttpManagementService-threads - 1)
>>>>> at org.jboss.logging.Messages.getBundle(Messages.java:81)
>>>>> 15:16:53,104 ERROR [stderr] (HttpManagementService-threads - 1)
>>>>> at org.jboss.logging.Messages.getBundle(Messages.java:46)
>>>>> 15:16:53,105 ERROR [stderr] (HttpManagementService-threads - 1)
>>>>> at
>>>>> org.jboss.as.domain.http.server.HttpServerMessages.<clinit>(HttpServerMessages.java:39)
>>>>> 15:16:53,106 ERROR [stderr] (HttpManagementService-threads - 1)
>>>>> ... 13 more
>>>>>
>>>>> Thx
>>>>>
>>>>> Vimal
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> jboss-as7-dev mailing list
>>>>> jboss-as7-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> jboss-as7-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
--
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, 3 months