[JBoss JIRA] (AS7-4858) jconsole.sh does not start on Mac OSX
by Jim Tyrrell (JIRA)
Jim Tyrrell created AS7-4858:
--------------------------------
Summary: jconsole.sh does not start on Mac OSX
Key: AS7-4858
URL: https://issues.jboss.org/browse/AS7-4858
Project: Application Server 7
Issue Type: Feature Request
Components: Server
Reporter: Jim Tyrrell
Assignee: Jason Greene
jconsole.sh does not work on Mac OSX:
Jim-Tyrrells-MacBook-Pro-2:bin jimtyrrell$ ./jconsole.sh
CLASSPATH /lib/jconsole.jar:/lib/tools.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/remoting3/remoting-jmx/main/remoting-jmx-1.0.3.CR1-redhat-0-todo.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/remoting3/main/jboss-remoting-3.2.4.GA-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/logging/main/jboss-logging-3.1.0.GA-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/xnio/main/xnio-api-3.0.3.GA-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/xnio/nio/main/xnio-nio-3.0.3.GA-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/sasl/main/jboss-sasl-1.0.0.Final-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/marshalling/main/jboss-marshalling-1.3.13.GA-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/marshalling/river/main/jboss-marshalling-river-1.3.13.GA-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/as/cli/main/jboss-as-cli-7.1.1.Final-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/staxmapper/main/staxmapper-1.1.0.Final-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/as/protocol/main/jboss-as-protocol-7.1.1.Final-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/dmr/main/jboss-dmr-1.1.1.Final-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/as/controller-client/main/jboss-as-controller-client-7.1.1.Final-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/threads/main/jboss-threads-2.0.0.GA-redhat-1.jar:/Users/jimtyrrell/Servers/eap6beta2/jboss-eap-6.0/modules/org/jboss/as/controller/main/jboss-as-controller-7.1.1.Final-redhat-1.jar
Exception in thread "main" java.lang.NoClassDefFoundError: sun/tools/jconsole/JConsole
Caused by: java.lang.ClassNotFoundException: sun.tools.jconsole.JConsole
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
--
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
13 years, 9 months
[JBoss JIRA] (AS7-4769) Remove no users redirect from /management context
by Darran Lofthouse (JIRA)
Darran Lofthouse created AS7-4769:
-------------------------------------
Summary: Remove no users redirect from /management context
Key: AS7-4769
URL: https://issues.jboss.org/browse/AS7-4769
Project: Application Server 7
Issue Type: Task
Components: Domain Management, Security
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1
For AS 7.1.0 we secured the server by default, to make getting started easier we added an automatic redirect on the http interface if a user attempts to connect but no users have been defined, currently this redirect is on both /console and /management
We need to remove the redirect on /management as utilities connecting to this context may not be web browsers with an ability to do anything about the redirect - instead we should most likely leave the http 401 in place to request authentication and possibly include some text in the response to indicate no users are defined yet.
--
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
13 years, 9 months
[JBoss JIRA] (AS7-4750) Starting a default ha configuration yields a hornetq error
by Heiko Braun (JIRA)
Heiko Braun created AS7-4750:
--------------------------------
Summary: Starting a default ha configuration yields a hornetq error
Key: AS7-4750
URL: https://issues.jboss.org/browse/AS7-4750
Project: Application Server 7
Issue Type: Bug
Components: Domain Management, JMS
Reporter: Heiko Braun
Assignee: Brian Stansberry
./bin/standalone.sh --server-config=standalone-full-ha.xml
leads to (after a while)
{noformat}
14:33:05,263 ERROR [org.hornetq.core.server.cluster.impl.BroadcastGroupImpl] (Thread-2 (HornetQ-scheduled-threads-25881841)) Failed to broadcast connector configs: java.io.IOException: Network is unreachable
at java.net.PlainDatagramSocketImpl.send(Native Method) [classes.jar:1.6.0_31]
at java.net.DatagramSocket.send(DatagramSocket.java:625) [classes.jar:1.6.0_31]
{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
13 years, 9 months
[JBoss JIRA] (JGRP-1485) JOIN attempts timing out indefinitely
by David Hotham (JIRA)
David Hotham created JGRP-1485:
----------------------------------
Summary: JOIN attempts timing out indefinitely
Key: JGRP-1485
URL: https://issues.jboss.org/browse/JGRP-1485
Project: JGroups
Issue Type: Bug
Affects Versions: 3.0.10
Reporter: David Hotham
Assignee: Bela Ban
The good news is that my testing is currently avoiding JGRP-1451 type issues. (I'm running with the latest master, plus my pull request 54).
The bad news is, that seems to have unblocked me to find the next problem...
I'm running the usual stress test where I kill and restart members, and verify that the group heals itself. I've managed to get into a situation where:
- A, B, and C all have no view at all (they're all repeatedly sending JOINs that time out)
- D has got stuck with a view {B,C,D,A,C} (in which every member except D is in fact a dead instance).
So what's happening on each of A, B and C is:
- perform discovery
- decide based on information from D that the long-dead B is coordinator
- send a JOIN to that dead B
- this times out
- repeat
Meanwhile D's FD is repeatedly broadcasting that A is suspect, but no-one pays any attention.
In an ideal world, I'd think that it ought to be up to D to spot that something has gone wrong. Eg after a long enough period of reporting that A is suspect without seeing any change of view, it could deduce that there's a problem and become a singleton; or something like that. Then a merge should sort everything out in due course.
I'm actually experimenting with a workaround in which we only allow JOIN attempts to time out some maximum number of times; and if they time out too often the member becomes a singleton. ie I'm making a fix that allows A, B and C to proceed. Then I again expect a merge to sort everything out. This looks a lot easier to code up, and seems a plausible thing to want to do anyway.
I have the test running and will see how this goes overnight. If it looks to work I'll submit a pull request; else I'll think again.
--
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
13 years, 9 months
[JBoss JIRA] (AS7-4217) RemoteConnectionFactory is not found when looking up in a remote client
by Ondřej Chaloupka (JIRA)
Ondřej Chaloupka created AS7-4217:
-------------------------------------
Summary: RemoteConnectionFactory is not found when looking up in a remote client
Key: AS7-4217
URL: https://issues.jboss.org/browse/AS7-4217
Project: Application Server 7
Issue Type: Bug
Components: Application Client, JMS
Affects Versions: 7.1.1.Final
Reporter: Ondřej Chaloupka
Assignee: jaikiran pai
I do lookup for RemoteConnectionFactory firstly locally in container and secondary via remote client. Then the second (remote one) lookup for RemoteConnectionFactory fails with exception:
{code}
javax.naming.NamingException: Failed to lookup [Root exception is java.io.NotSerializableException: org.hornetq.api.core.client.loadbalance.RoundRobinConnectionLoadBalancingPolicy]
at org.jboss.naming.remote.client.ClientUtil.namingException(ClientUtil.java:36)
at org.jboss.naming.remote.protocol.v1.Protocol$1.execute(Protocol.java:104)
at org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1.lookup(RemoteNamingStoreV1.java:79)
at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:79)
at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:83)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at org.jboss.as.test.integration.ee.remotelookup.LookupTestCase.test2(LookupTestCase.java:81)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68)
Caused by: java.io.NotSerializableException: org.hornetq.api.core.client.loadbalance.RoundRobinConnectionLoadBalancingPolicy
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:891)
at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:998)
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
at org.jboss.naming.remote.protocol.v1.Protocol$1$2.write(Protocol.java:138)
at org.jboss.naming.remote.protocol.v1.WriteUtil.write(WriteUtil.java:61)
at org.jboss.naming.remote.protocol.v1.Protocol$1.handleServerMessage(Protocol.java:128)
at org.jboss.naming.remote.protocol.v1.RemoteNamingServerV1$MessageReciever$1.run(RemoteNamingServerV1.java:73)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: an exception which occurred:
in field loadBalancingPolicy
in field serverLocator
in object org.hornetq.jms.client.HornetQJMSConnectionFactory@d67f82
{code}
Please check my test reproducer: https://github.com/ochaloup/jboss-as/commit/1a1605f6ad4e860789d704d682ff6...
The exception is thrown on line: https://github.com/ochaloup/jboss-as/blob/1a1605f6ad4e860789d704d682ff6e6...
Tested with standalone-full.xml. Command to run the test: ./integration-tests.sh clean install -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.ee.remotelookup.*
--
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
13 years, 10 months
[JBoss JIRA] (AS7-5084) Wrong text when add-user.sh adds a password for a slave HC
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-5084:
-------------------------------------
Summary: Wrong text when add-user.sh adds a password for a slave HC
Key: AS7-5084
URL: https://issues.jboss.org/browse/AS7-5084
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Affects Versions: 7.1.2.Final (EAP)
Reporter: Brian Stansberry
Assignee: Darran Lofthouse
Priority: Minor
Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1
About to add user 'bstansberry' for realm 'ManagementRealm'
...
Is this new user going to be used for one AS process to connect to another AS process e.g. slave domain controller?
yes/no?
That "e.g. slave domain controller" is poorly worded. Better is "e.g. a slave host controller connecting to the master domain controller?"
Is there any other use case this question is handling? If not, let's just be simple and direct, e.g.:
"Is this new user going to be used for a slave host controller connecting to the master domain controller?"
--
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
13 years, 10 months