[JBoss JIRA] (AS7-3575) Socket-binding-group add operation does not work
by Dominik Pospisil (JIRA)
Dominik Pospisil created AS7-3575:
-------------------------------------
Summary: Socket-binding-group add operation does not work
Key: AS7-3575
URL: https://issues.jboss.org/browse/AS7-3575
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Affects Versions: 7.1.0.Final
Reporter: Dominik Pospisil
Assignee: Brian Stansberry
The socket-binding-group add operation does not work. Add operation fails with the error:
11:25:35,087 ERROR [org.jboss.as.controller.management-operation] (management-handler-threads - 8) JBAS014612: Operation ("add") failed - address: ([("socket-binding-group" => "test-sockets")]): org.jboss.msc.service.DuplicateServiceException: Service jboss.socket-binding-manager is already registered
at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:154) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:227) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:560) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2228) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
Steps to reproduce:
1) start standalone server
2) connect via CLI
3)
[standalone@localhost:9999 /] /socket-binding-group=test-sockets:add(default-interface="public")
{
"outcome" => "failed",
"failure-description" => "JBAS014749: Operation handler failed: Service jboss.socket-binding-manager is already registered",
"rolled-back" => true
}
--
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, 8 months
[JBoss JIRA] (AS7-4571) client and server hang on remoting error
by Arto Huusko (JIRA)
Arto Huusko created AS7-4571:
--------------------------------
Summary: client and server hang on remoting error
Key: AS7-4571
URL: https://issues.jboss.org/browse/AS7-4571
Project: Application Server 7
Issue Type: Bug
Components: Remoting
Affects Versions: 7.1.1.Final
Reporter: Arto Huusko
Assignee: David Lloyd
When an unexpected error occurs in a remote client EJB invocation, the remoting system in both the client and the server hangs. An example of such unexpected error is that the client does not have access to a class used in the return value from the server.
An example stack trace of such invocation:
Caused by: java.lang.ClassNotFoundException: org.hibernate.collection.internal.PersistentSet
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)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:892)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1204)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1677)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1593)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1235)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadCollectionObject(RiverUnmarshaller.java:180)
at org.jboss.marshalling.river.RiverUnmarshaller.readCollectionData(RiverUnmarshaller.java:771)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:649)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
at org.jboss.ejb.client.remoting.MethodInvocationResponseHandler$MethodInvocationResultProducer.getResult(MethodInvocationResponseHandler.java:107)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:270)
at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:47)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:272)
at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:132)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:260)
at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:399)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:140)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104)
After that, relevant threads on the client look like:
"main" prio=10 tid=0x00007f6e5c007000 nid=0xefe in Object.wait() [0x00007f6e62be6000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000fe1a4b08> (a java.lang.Thread)
at java.lang.Thread.join(Thread.java:1186)
- locked <0x00000000fe1a4b08> (a java.lang.Thread)
at java.lang.Thread.join(Thread.java:1239)
at java.lang.ApplicationShutdownHooks.runHooks(ApplicationShutdownHooks.java:79)
at java.lang.ApplicationShutdownHooks$1.run(ApplicationShutdownHooks.java:24)
at java.lang.Shutdown.runHooks(Shutdown.java:79)
at java.lang.Shutdown.sequence(Shutdown.java:123)
at java.lang.Shutdown.exit(Shutdown.java:168)
- locked <0x00000000f31219d0> (a java.lang.Class for java.lang.Shutdown)
at java.lang.Runtime.exit(Runtime.java:90)
at java.lang.System.exit(System.java:904)
at ExampleApp(ExampleApp.java:133)
"Thread-1" prio=10 tid=0x00007f6e5c1f2000 nid=0xf12 in Object.wait() [0x00007f6e60846000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000fe149190> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at org.jboss.remoting3.spi.AbstractHandleableCloseable.close(AbstractHandleableCloseable.java:177)
- locked <0x00000000fe149190> (a java.lang.Object)
at org.jboss.ejb.client.remoting.AutoConnectionCloser.safeClose(AutoConnectionCloser.java:92)
at org.jboss.ejb.client.remoting.AutoConnectionCloser.closeAll(AutoConnectionCloser.java:79)
- locked <0x00000000fe1a4bb0> (a java.util.ArrayList)
at org.jboss.ejb.client.remoting.AutoConnectionCloser.run(AutoConnectionCloser.java:55)
at java.lang.Thread.run(Thread.java:662)
"Remoting "config-based-ejb-client-endpoint" task-4" daemon prio=10 tid=0x00007f6e18052800 nid=0xf10 waiting on condition [0x00007f6e60947000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000fe130130> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at org.xnio.LimitedBlockingQueue.take(LimitedBlockingQueue.java:95)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
"Remoting "config-based-ejb-client-endpoint" task-3" daemon prio=10 tid=0x00007f6e18050800 nid=0xf0f waiting on condition [0x00007f6e60a48000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000fe130130> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at org.xnio.LimitedBlockingQueue.take(LimitedBlockingQueue.java:95)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
"Remoting "config-based-ejb-client-endpoint" task-2" daemon prio=10 tid=0x00007f6e1804d000 nid=0xf0e waiting on condition [0x00007f6e60b49000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000fe130130> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at org.xnio.LimitedBlockingQueue.take(LimitedBlockingQueue.java:95)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
"Remoting "config-based-ejb-client-endpoint" task-1" daemon prio=10 tid=0x00007f6e1804b800 nid=0xf0d waiting on condition [0x00007f6e60c4a000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000fe130130> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at org.xnio.LimitedBlockingQueue.take(LimitedBlockingQueue.java:95)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
"Remoting "config-based-ejb-client-endpoint" write-1" daemon prio=10 tid=0x00007f6e5c1e1800 nid=0xf0c runnable [0x00007f6e60d4b000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
- locked <0x00000000fe148330> (a sun.nio.ch.Util$2)
- locked <0x00000000fe148340> (a java.util.Collections$UnmodifiableSet)
- locked <0x00000000fe1482e8> (a sun.nio.ch.EPollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:84)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:153)
"Remoting "config-based-ejb-client-endpoint" read-1" daemon prio=10 tid=0x00007f6e5c1bc800 nid=0xf0b runnable [0x00007f6e60e4c000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
- locked <0x00000000fe130298> (a sun.nio.ch.Util$2)
- locked <0x00000000fe1302a8> (a java.util.Collections$UnmodifiableSet)
- locked <0x00000000fe130250> (a sun.nio.ch.EPollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:84)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:153)
And on the server:
"EJB default - 6" prio=10 tid=0x00007fcacc0cd800 nid=0xe3c in Object.wait() [0x00007fcb119d8000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000f9c73080> (a org.jboss.remoting3.remote.OutboundMessage)
at java.lang.Object.wait(Object.java:485)
at org.jboss.remoting3.remote.OutboundMessage$1.accept(OutboundMessage.java:91)
- locked <0x00000000f9c73080> (a org.jboss.remoting3.remote.OutboundMessage)
at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:125)
at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:113)
at org.xnio.streams.BufferPipeOutputStream.getBuffer(BufferPipeOutputStream.java:77)
at org.xnio.streams.BufferPipeOutputStream.write(BufferPipeOutputStream.java:86)
- locked <0x00000000f9c730b8> (a org.xnio.streams.BufferPipeOutputStream)
at org.jboss.remoting3.remote.OutboundMessage.write(OutboundMessage.java:168)
at java.io.DataOutputStream.write(DataOutputStream.java:71)
- locked <0x00000000f9c73060> (a java.io.DataOutputStream)
at org.jboss.as.ejb3.remote.protocol.versionone.AbstractMessageHandler$1.write(AbstractMessageHandler.java:188)
at java.io.OutputStream.write(OutputStream.java:99)
at org.jboss.marshalling.OutputStreamByteOutput.write(OutputStreamByteOutput.java:56)
at org.jboss.marshalling.SimpleDataOutput.write(SimpleDataOutput.java:83)
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:302)
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.doWriteObject(RiverMarshaller.java:585)
at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.writeMethodInvocationResponse(MethodInvocationMessageHandler.java:338)
at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$500(MethodInvocationMessageHandler.java:64)
at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:226)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
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)
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
"Remoting "vlinux" read-1" prio=10 tid=0x00007fcadc08e800 nid=0xd33 waiting for monitor entry [0x00007fcb116cf000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.xnio.streams.BufferPipeOutputStream.close(BufferPipeOutputStream.java:156)
- waiting to lock <0x00000000f9c730b8> (a org.xnio.streams.BufferPipeOutputStream)
at org.xnio.IoUtils.safeClose(IoUtils.java:137)
at org.jboss.remoting3.remote.OutboundMessage.closeAsync(OutboundMessage.java:158)
at org.jboss.remoting3.remote.RemoteConnectionChannel.handleAsyncClose(RemoteConnectionChannel.java:502)
at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:259)
at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
When the server is in this state, new remoting invocations on the server can not be made. The remote client stalls for a short time, and then times out with "No EJB receiver available for handling".
The server and client are so wedged that the only way to shut them down on linux is kill -9.
--
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, 8 months
[JBoss JIRA] (AS7-3805) Empty Module Index File Errors - 7.1.0.FINAL shipping an incomplete set
by Ed Roberts (JIRA)
Ed Roberts created AS7-3805:
-------------------------------
Summary: Empty Module Index File Errors - 7.1.0.FINAL shipping an incomplete set
Key: AS7-3805
URL: https://issues.jboss.org/browse/AS7-3805
Project: Application Server 7
Issue Type: Quality Risk
Components: MSC
Affects Versions: 7.1.0.Final
Environment: Windows XP
JDK 1.6.0_27
Reporter: Ed Roberts
Assignee: David Lloyd
Priority: Minor
Yesterday I was chasing my tail after installing the latest 7.1.0.Final release of JBoss AS.
I overlayed the install with some additional batch files which aim to start a specific configuration of a standalone
server instance. There is a good chance that I stopped the process before it had fully completed, because I
observed an error and wanted to rectify it. Nevertheless, it appears that it has uncovered a problem that
could cost someone an indefinite amount of time to realise how to resolve it.
When subsequently running my batch file, and even the domain.bat, they failed with both the console and the log showing an exception
indicating that the configuration had parse errors for the jsr77, modcluster and messaging extensions.
2012-02-17 10:31:33,983 ERROR [org.jboss.as.controller](Controller Boot Thread) JBAS014601: Error booting the container: java.lang.RuntimeException: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:161)
at java.lang.Thread.run(Thread.java:662)
Caused by: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:125)
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:187)
at org.jboss.as.server.ServerService.boot(ServerService.java:261)
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:155)
... 1 more
Caused by: javax.xml.stream.XMLStreamException: Failed to load module org.jboss.as.jsr77
at org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:154)
at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_1(StandaloneXml.java:304)
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:126)
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:100)
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:117)
... 4 more
Caused by: java.util.concurrent.ExecutionException: java.lang.IllegalStateException: JBAS014744: No META-INF/services/org.jboss.as.controller.Extension found for org.jboss.as.jsr77:main
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
at java.util.concurrent.FutureTask.get(FutureTask.java:83)
at org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:146)
... 10 more
Caused by: java.lang.IllegalStateException: JBAS014744: No META-INF/services/org.jboss.as.controller.Extension found for org.jboss.as.jsr77:main
at org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:191)
at org.jboss.as.controller.parsing.ExtensionXml.access$000(ExtensionXml.java:68)
at org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:126)
at org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:123)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
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)
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
I managed by commenting out certain extensions to narrow the issue down to just 3 extensions (stated above).
Later I installed another instance of JBoss AS 7.1.0.Final and the domain.bat started fine.
I did a directory comparison between the two installs and noticed that the only difference was the index
files within the module directory structure: all were zero bytes.
When I compare the 7.1.0.Final release archive with that of 7.1.0.CR1b, I notice that the Final is now shipping with
some, but not all, module index files.
I lost the original exceptions through correcting the files. The above exception was created simply by zeroing an index file.
If a zero byte index file is present for an extension, it would help if a warning could be raised, or perhaps even the index file was rebuilt.
--
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, 8 months
[JBoss JIRA] (JBAS-9483) Excepetion occuring while start up and instantiating thread
by Nag Naga (JIRA)
Nag Naga created JBAS-9483:
------------------------------
Summary: Excepetion occuring while start up and instantiating thread
Key: JBAS-9483
URL: https://issues.jboss.org/browse/JBAS-9483
Project: Application Server 3 4 5 and 6
Issue Type: Support Patch
Security Level: Public (Everyone can see)
Components: EJB
Affects Versions: JBossAS-4.2.3.GA
Reporter: Nag Naga
Assignee: Carlo de Wolf
M: 2012-04-12 23:04:58,281 [Thread-10] INFO org.apache.catalina.loader.WebappClassLoader - Illegal access: this web application instance has been stopped already. Could not load ear.properties. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
M: 2012-04-12 23:04:58,281 [Thread-10] WARN za.co.vine.provisioningcentral.util.Locator - ear.properties not found!
M: 2012-04-12 23:04:58,285 [Thread-10] INFO org.apache.catalina.loader.WebappClassLoader - Illegal access: this web application instance has been stopped already. Could not load javax.naming.NameNotFoundException. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
java.lang.IllegalStateException
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1244)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1204)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:316)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:154)
at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620)
at org.jboss.system.JBossRMIClassLoader.loadClass(JBossRMIClassLoader.java:91)
at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:247)
at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:197)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:225)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142)
at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:667)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at za.co.vine.provisioningcentral.util.Locator.getProvisioningCentralManager(Locator.java:121)
at za.co.vine.robocall.util.CampaignListener$CampaignThread.run(CampaignListener.java:41)
M: 2012-04-12 23:04:58,287 [Thread-10] INFO org.apache.catalina.loader.WebappClassLoader - Illegal access: this web application instance has been stopped already. Could not load javax.naming.NamingException. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
java.lang.IllegalStateException
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1244)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1204)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:316)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:154)
at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620)
at org.jboss.system.JBossRMIClassLoader.loadClass(JBossRMIClassLoader.java:91)
at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:247)
at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:197)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1583)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:225)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142)
at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:667)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at za.co.vine.provisioningcentral.util.Locator.getProvisioningCentralManager(Locator.java:121)
at za.co.vine.robocall.util.CampaignListener$CampaignThread.run(CampaignListener.java:41)
M: 2012-04-12 23:04:58,287 [Thread-10] INFO org.apache.catalina.loader.WebappClassLoader - Illegal access: this web application instance has been stopped already. Could not load java.lang.StackTraceElement. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
java.lang.IllegalStateException
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1244)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1204)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:316)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:154)
at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620)
at org.jboss.system.JBossRMIClassLoader.loadClass(JBossRMIClassLoader.java:91)
at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:247)
at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:197)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1624)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:225)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142)
at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:667)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at za.co.vine.provisioningcentral.util.Locator.getProvisioningCentralManager(Locator.java:121)
at za.co.vine.robocall.util.CampaignListener$CampaignThread.run(CampaignListener.java:41)
M: 2012-04-12 23:04:58,288 [Thread-10] WARN za.co.vine.robocall.util.CampaignListener - Terminating... javax.naming.NameNotFoundException: ProvisioningCentralManager not bound
--
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, 8 months
[JBoss JIRA] (AS7-4695) Server does not start with sun jmx enabled
by Michael Voegele (JIRA)
Michael Voegele created AS7-4695:
------------------------------------
Summary: Server does not start with sun jmx enabled
Key: AS7-4695
URL: https://issues.jboss.org/browse/AS7-4695
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Affects Versions: 7.1.1.Final
Reporter: Michael Voegele
Assignee: Brian Stansberry
Starting a server in domain mode configured as
{code:xml}
<servers>
<server name="server-1" group="server-group-1" auto-start="true">
<system-properties>
<property name="com.sun.management.jmxremote.port" value="13013"/>
<property name="com.sun.management.jmxremote.authenticate" value="false"/>
<property name="com.sun.management.jmxremote.ssl" value="false"/>
...
{code}
does not work.
{code:java}
[Server:server-1] WARNING: Failed to load the specified log manager class org.jboss.logmanager.LogManager
[Server:server-1] Exception in thread "main" java.lang.ExceptionInInitializerError
[Server:server-1] at org.jboss.as.server.DomainServerMain.main(DomainServerMain.java:86)
[Server:server-1] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[Server:server-1] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[Server:server-1] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[Server:server-1] at java.lang.reflect.Method.invoke(Method.java:597)
[Server:server-1] at org.jboss.modules.Module.run(Module.java:260)
[Server:server-1] at org.jboss.modules.Main.main(Main.java:291)
[Server:server-1] Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
[Server:server-1] at org.jboss.logmanager.Logger.getLogger(Logger.java:60)
[Server:server-1] at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRepositorySelector.java:42)
[Server:server-1] ... 7 more
{code}
I've seen in https://issues.jboss.org/browse/AS7-1859 that this won't be supported. May I ask why? I think that this is standard java and it should work.
--
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, 8 months
[JBoss JIRA] (AS7-4694) JBAS014478: Could not find timeout method
by Franck Garcia (JIRA)
Franck Garcia created AS7-4694:
----------------------------------
Summary: JBAS014478: Could not find timeout method
Key: AS7-4694
URL: https://issues.jboss.org/browse/AS7-4694
Project: Application Server 7
Issue Type: Bug
Components: EJB
Affects Versions: 7.1.1.Final
Environment: ubuntu 11.04, x32, oracle jdk_1.6.0_27, AS 7.1.1.Final
Reporter: Franck Garcia
Assignee: jaikiran pai
I've added a timer service in one of my ejb of a specific module inside my ear application through the @Schedule annotation.
I then removed the method annotated with the Schedule annotation and redeploy.
The AS refuses to deploy my module (and my entire ear as a consequence) ended up with the following exception:
Caused by: java.lang.IllegalStateException: JBAS014478: Could not find timeout method: com.acme.AppLogger.processSend(javax.ejb.Timer)
at org.jboss.as.ejb3.timerservice.CalendarTimer.<init>(CalendarTimer.java:138)
at org.jboss.as.ejb3.timerservice.TimerServiceImpl.getActivePersistentTimers(TimerServiceImpl.java:906)
at org.jboss.as.ejb3.timerservice.TimerServiceImpl.restoreTimers(TimerServiceImpl.java:633)
at org.jboss.as.ejb3.timerservice.TimerServiceImpl.start(TimerServiceImpl.java:190)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
I add to get rid of the $JBOSS_DIR$standalone/data/timer-service-data folder to be able to properly redeploy.
--
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, 8 months
[JBoss JIRA] (JBRULES-3487) NullPointerException in org.jbpm.ruleflow.core.validation.RuleFlowProcessValidator
by James Nord (JIRA)
James Nord created JBRULES-3487:
-----------------------------------
Summary: NullPointerException in org.jbpm.ruleflow.core.validation.RuleFlowProcessValidator
Key: JBRULES-3487
URL: https://issues.jboss.org/browse/JBRULES-3487
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core (flow)
Affects Versions: 5.4.0.CR1
Reporter: James Nord
Assignee: Mark Proctor
There is a coding issue in that leads to a NullPOinterException.
The Exception has been shown presumable due to an invalid rf file - but the code gives an unhelpful exception.
Insepction of the code reveals that if the first condition is true on line 193 then the code will blow up - which is presumable not what the coder has intended
{code:title=RuleFlowProcessValidator.java Line 190 onwars|borderStyle=solid}
if (split.getType() == Split.TYPE_XOR || split.getType() == Split.TYPE_OR ) {
for ( final Iterator<Connection> it = split.getDefaultOutgoingConnections().iterator(); it.hasNext(); ) {
final Connection connection = it.next();
if (split.getConstraint(connection) == null && !split.getConstraint(connection).isDefault() && (split.getConstraint(connection).getConstraint() == null || split.getConstraint(connection).getConstraint().trim().length() == 0)) {
errors.add(new ProcessValidationErrorImpl(process,
"Split node '" + node.getName() + "' [" + node.getId() + "] does not have a constraint for " + connection.toString() + "."));
}
}
}
{code}
"if (split.getConstraint(connection) == null && !split.getConstraint(connection).isDefault()"
if "split.gerConstraint(connection)" is null then "split.getConstraint(connection).isDefault()" will dereference null.
--
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, 8 months