[JBoss JIRA] Created: (JBAS-8261) Finalizer and Timer-Log4jService threads deadlock
by Bart Berger (JIRA)
Finalizer and Timer-Log4jService threads deadlock
-------------------------------------------------
Key: JBAS-8261
URL: https://jira.jboss.org/browse/JBAS-8261
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Logging
Affects Versions: JBossAS-5.1.0.GA
Environment: OS: Linux (2.6.16.46-0.12-bigsmp)
JVM: Java HotSpot(TM) Server VM (16.3-b01, mixed mode) (JRE 1.6.0_20)
Reporter: Bart Berger
Assignee: David Lloyd
Encountered the following deadlock:
"Finalizer" daemon prio=8 tid=3 BLOCKED
at org.jboss.logmanager.LoggerNode.getParentLogger(LoggerNode.java:142)
Local Variable: org.jboss.logmanager.LoggerNode#362
at org.jboss.logmanager.LoggerInstance.getParent(LoggerInstance.java:167)
at org.jboss.logmanager.LoggerInstance.setLevel(LoggerInstance.java:96)
Local Variable: java.util.logging.Level#2
Local Variable: org.jboss.logmanager.LogContext#1
at org.jboss.logmanager.LoggerInstance.finalize(LoggerInstance.java:204)
at java.lang.ref.Finalizer.$$YJP$$invokeFinalizeMethod(Native Method)
at java.lang.ref.Finalizer.invokeFinalizeMethod(Finalizer.java)
at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)
Local Variable: org.jboss.logmanager.LoggerInstance#161
at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)
Local Variable: java.lang.ref.Finalizer#65597
"Timer-Log4jService" daemon prio=5 tid=25 WAITING
at sun.misc.Unsafe.$$YJP$$park(Native Method)
at sun.misc.Unsafe.park(Unsafe.java)
Local Variable: sun.misc.Unsafe#1
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)
Local Variable: java.util.concurrent.locks.AbstractQueuedSynchronizer$Node#629
Local Variable: java.util.concurrent.locks.AbstractQueuedSynchronizer$Node#630
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)
at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)
Local Variable: java.util.concurrent.locks.ReentrantLock$NonfairSync#89
at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
Local Variable: java.util.concurrent.locks.ReentrantLock#42
at org.jboss.logmanager.LoggerInstance.setLevel(LoggerInstance.java:89)
at org.jboss.logmanager.LoggerInstance.<init>(LoggerInstance.java:53)
Local Variable: org.jboss.logmanager.LoggerInstance#1049
Local Variable: java.lang.String#936666
at org.jboss.logmanager.LoggerNode.getOrCreateLogger(LoggerNode.java:127)
at org.jboss.logmanager.LogContext.getLogger(LogContext.java:71)
at org.jboss.logmanager.LogManager.getLogger(LogManager.java:273)
at java.util.logging.LogManager.demandLogger(LogManager.java:390)
at java.util.logging.Logger.getLogger(Logger.java:274)
Local Variable: org.jboss.logmanager.LogManager#1
at org.jboss.logbridge.LogBridgeHandler.updateLoggers(LogBridgeHandler.java:123)
Local Variable: java.util.Collections$SynchronizedMap#43
Local Variable: java.util.Vector$1#3
Local Variable: org.apache.log4j.spi.RootLogger#1
Local Variable: org.apache.log4j.Hierarchy#1
Local Variable: org.apache.log4j.Logger#375
Local Variable: java.lang.String#582052
Local Variable: org.jboss.logbridge.LevelMapper#1
Local Variable: org.jboss.logbridge.LogBridgeHandler#1
at org.jboss.logbridge.LogNotificationListener.handleNotification(LogNotificationListener.java:67)
at sun.reflect.GeneratedMethodAccessor203.invoke(<unknown string>)
Local Variable: sun.reflect.GeneratedMethodAccessor203#1
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
Local Variable: sun.reflect.DelegatingMethodAccessorImpl#458
at java.lang.reflect.Method.invoke(Method.java:597)
Local Variable: org.jboss.logbridge.LogNotificationListener#1
at org.jboss.mx.notification.NotificationListenerProxy.invoke(NotificationListenerProxy.java:153)
Local Variable: java.lang.String#2851584
Local Variable: java.lang.Object[]#760535
Local Variable: org.jboss.mx.notification.NotificationListenerProxy#2
Local Variable: java.lang.reflect.Method#16042
at $Proxy73.handleNotification(<unknown string>)
at org.jboss.mx.util.JBossNotificationBroadcasterSupport.handleNotification(JBossNotificationBroadcasterSupport.java:127)
Local Variable: $Proxy73#1
at org.jboss.mx.util.JBossNotificationBroadcasterSupport.sendNotification(JBossNotificationBroadcasterSupport.java:108)
Local Variable: org.jboss.mx.notification.DefaultListenerRegistration#3
Local Variable: org.jboss.mx.notification.ListenerRegistry$ListenerRegistrationIterator#1
at org.jboss.logging.Log4jService.emitReconfigureNotification(Log4jService.java:560)
Local Variable: org.jboss.logging.Log4jService#1
Local Variable: javax.management.Notification#1
at org.jboss.logging.Log4jService$URLWatchTimerTask.reconfigure(Log4jService.java:716)
at org.jboss.logging.Log4jService$URLWatchTimerTask.run(Log4jService.java:636)
Local Variable: org.jboss.net.protocol.resource.ResourceURLConnection#1
at java.util.TimerThread.mainLoop(Timer.java:512)
Local Variable: java.lang.Object#18446
Local Variable: org.jboss.logging.Log4jService$URLWatchTimerTask#1
Local Variable: java.util.TaskQueue#5
at java.util.TimerThread.run(Timer.java:462)
The timer thread ran logging configuration while the finalizer was processing LoggerInstance objects.
The Finalizer thread calls context.levelTreeLock.lock() in LoggerInstance.setLevel(), then enters a synchronized code block in LoggerNode.getParentLogger(). The configuration thread enters a synchronized code block in LoggerNode.getOrCreateLogger(), then creates a new LoggerInstance which calls context.levelTreeLock.lock() in LoggerInstance.setLevel().
--
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
13 years, 6 months
[JBoss JIRA] Created: (JBAS-8267) MDB(Connection Consumer Thread) stop on rare occasions by JMSSecurityException
by Hiroyuki Wada (JIRA)
MDB(Connection Consumer Thread) stop on rare occasions by JMSSecurityException
------------------------------------------------------------------------------
Key: JBAS-8267
URL: https://jira.jboss.org/browse/JBAS-8267
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JMS (JBossMQ)
Affects Versions: JBossAS-4.2.2.GA, JBossAS-4.0.5.GA, JBossAS-4.0.2 Final
Environment: Java VM: Java HotSpot(TM) Client VM 1.4.2_19-b04,Sun Microsystems Inc.
OS-System: Windows XP SP3
Reporter: Hiroyuki Wada
Assignee: Adrian Brock
When MDB's connection thread (Connection Consumer Thread) receive a message, JMSSecurityException is throwed on rare occasions. And the thread go down, so MDB don't be executed if a message be sent.
Following stacktrace is visible in server.log.
10:39:15,796 WARN [SpyConnectionConsumer] Connection consumer closing due to error in listening thread SpyConnectionConsumer[sub=Subscription[subId=-2147483648connection=ConnectionToken:ID:1/a347321b2793ca494842452c5278a657 destination=TOPIC.testTopic messageSelector=null Local Create] messages=0 waitingForMessage=false internalThread=Thread[Connection Consumer for dest Subscription[subId=-2147483648connection=ConnectionToken:ID:1/a347321b2793ca494842452c5278a657 destination=TOPIC.testTopic messageSelector=null Local Create] id=1,5,jboss] sessionPool=org.jboss.jms.asf.StdServerSessionPool@1ce9085 connection=Connection@13008985[token=ConnectionToken:ID:1/a347321b2793ca494842452c5278a657 rcvstate=STARTED]]
javax.jms.JMSSecurityException: User session is not valid
at org.jboss.mq.security.SecurityManager.authorize(SecurityManager.java:230)
at org.jboss.mq.security.ServerSecurityInterceptor.authorizeRead(ServerSecurityInterceptor.java:233)
at org.jboss.mq.security.ServerSecurityInterceptor.receive(ServerSecurityInterceptor.java:98)
at org.jboss.mq.server.TracingInterceptor.receive(TracingInterceptor.java:570)
at org.jboss.mq.server.JMSServerInvoker.receive(JMSServerInvoker.java:226)
at org.jboss.mq.il.jvm.JVMServerIL.receive(JVMServerIL.java:244)
at org.jboss.mq.Connection.receive(Connection.java:909)
at org.jboss.mq.SpyConnectionConsumer.run(SpyConnectionConsumer.java:238)
at java.lang.Thread.run(Thread.java:534)
It looks like a synchronization problem.
In 'org.jboss.mq.security.SecurityManager#authorize' method, 'authCache' variable is accessed by HashMap#get method but it's not synchronized.
When other thread put object to the 'authCache' variable, the HashMap#get methos will return null on rare occasions even though the key is contained.
so when the return value is null, JMSSecurityException is throwed.
SubjectInfo info = (SubjectInfo) authCache.get(token.getSessionId());
if (info == null)
throw new JMSSecurityException("User session is not valid");
I wrote a patch for JBossAS Branch_4_0 and Branch_4_2.
It is very simple patch that add synchorized block.
--
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
13 years, 6 months
[JBoss JIRA] Created: (JBAS-7926) Quartz RA: Endpoint deactivation immediately stops classloader of (long running) quartz job
by Marcus Linke (JIRA)
Quartz RA: Endpoint deactivation immediately stops classloader of (long running) quartz job
-------------------------------------------------------------------------------------------
Key: JBAS-7926
URL: https://jira.jboss.org/jira/browse/JBAS-7926
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-6.0.0.M2
Reporter: Marcus Linke
While undeploying/stopping the MDB the QuartzResourceAdapter's 'endpointDeactivation' hook calls the quartz scheduler method 'deleteJob(..)'. This method call is nonblocking and therefore the process of stopping the MDB is continued. As part of this the classloader of the quartz job is also stopped which may prevent a long running job to successfully complete.
One possible workaround may be to use a quartz job listener here to emulate the blocking behavior and wait until a running job completes. Eventually there is a need for a timeout value then, but this could be configured by the MDB itself via ActivationConfigProperties.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] Created: (JBAS-8369) JBoss AS CPU loop - incorrect synchronization on HashMap?
by Stephen Potter (JIRA)
JBoss AS CPU loop - incorrect synchronization on HashMap?
---------------------------------------------------------
Key: JBAS-8369
URL: https://jira.jboss.org/browse/JBAS-8369
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Tomcat) service
Affects Versions: JBossAS-5.1.0.GA
Environment: SUSE Linux 2.6.27.19-5-default #1 SMP 2009-02-28 04:40:21 +0100 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Stephen Potter
Assignee: Remy Maucherat
Web application becomes unresponsive. JBoss java CPU at 340%. jstack shows 3 JBoss web threads in HashMap.get suggesting that the cause is incorrectly synchronized use of a HashMap. Extract of stack dump:
"ajp-127.0.0.1-50113-55" daemon prio=10 tid=0x000000004c364800 nid=0x4f1 runnable [0x00007f6f09cd7000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.get(HashMap.java:303)
at org.jboss.injection.InjectionUtil.collapseXmlMethodInjectors(InjectionUtil.java:71)
at org.jboss.injection.InjectionUtil.collapseXmlMethodInjectors(InjectionUtil.java:92)
at org.jboss.injection.InjectionUtil.collapseXmlMethodInjectors(InjectionUtil.java:92)
at org.jboss.web.tomcat.service.injection.TomcatInjectionUtils.processDynamicBeanAnnotations(TomcatInjectionUtils.java:59)
at org.jboss.web.tomcat.service.TomcatInjectionContainer.processAnnotations(TomcatInjectionContainer.java:407)
at org.jboss.web.tomcat.service.TomcatInjectionContainer.processDynamicBeanAnnotations(TomcatInjectionContainer.java:382)
at org.jboss.web.tomcat.service.TomcatInjectionContainer.newInstance(TomcatInjectionContainer.java:274)
at org.jboss.web.tomcat.service.TomcatInjectionContainer.newInstance(TomcatInjectionContainer.java:265)
at org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:145)
- locked <0x00007f6f8d353200> (a org.apache.jasper.servlet.JspServletWrapper)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:322)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:249)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
. . . . . . . . . . . . .
"ajp-127.0.0.1-50113-15" daemon prio=10 tid=0x000000005caa6800 nid=0x15f2 runnable [0x00007f6f4073d000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.get(HashMap.java:303)
at org.jboss.injection.InjectionUtil.collapseXmlMethodInjectors(InjectionUtil.java:71)
at org.jboss.injection.InjectionUtil.collapseXmlMethodInjectors(InjectionUtil.java:92)
at org.jboss.injection.InjectionUtil.collapseXmlMethodInjectors(InjectionUtil.java:92)
at org.jboss.web.tomcat.service.injection.TomcatInjectionUtils.processDynamicBeanAnnotations(TomcatInjectionUtils.java:59)
at org.jboss.web.tomcat.service.TomcatInjectionContainer.processAnnotations(TomcatInjectionContainer.java:407)
at org.jboss.web.tomcat.service.TomcatInjectionContainer.processDynamicBeanAnnotations(TomcatInjectionContainer.java:382)
at org.jboss.web.tomcat.service.TomcatInjectionContainer.newInstance(TomcatInjectionContainer.java:274)
at org.jboss.web.tomcat.service.TomcatInjectionContainer.newInstance(TomcatInjectionContainer.java:265)
at org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:145)
- locked <0x00007f6fd8a886b0> (a org.apache.jasper.servlet.JspServletWrapper)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:322)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:249)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
. . . . . . . . . . . . .
"ajp-127.0.0.1-50113-6" daemon prio=10 tid=0x00000000418f0000 nid=0x25d7 runnable [0x00007f6f41045000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.get(HashMap.java:303)
at org.jboss.injection.InjectionUtil.collapseXmlMethodInjectors(InjectionUtil.java:71)
at org.jboss.injection.InjectionUtil.collapseXmlMethodInjectors(InjectionUtil.java:92)
at org.jboss.injection.InjectionUtil.collapseXmlMethodInjectors(InjectionUtil.java:92)
at org.jboss.web.tomcat.service.injection.TomcatInjectionUtils.processDynamicBeanAnnotations(TomcatInjectionUtils.java:59)
at org.jboss.web.tomcat.service.TomcatInjectionContainer.processAnnotations(TomcatInjectionContainer.java:407)
at org.jboss.web.tomcat.service.TomcatInjectionContainer.processDynamicBeanAnnotations(TomcatInjectionContainer.java:382)
at org.jboss.web.tomcat.service.TomcatInjectionContainer.newInstance(TomcatInjectionContainer.java:274)
at org.jboss.web.tomcat.service.TomcatInjectionContainer.newInstance(TomcatInjectionContainer.java:265)
at org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:145)
- locked <0x00007f6fd40a01b8> (a org.apache.jasper.servlet.JspServletWrapper)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:322)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:249)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
. . . . . . . . . . . . .
--
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
13 years, 6 months
[JBoss JIRA] Created: (JBAS-8741) Linux multicast issue using IPv4 addresses and IPv6 stack
by Richard Achmatowicz (JIRA)
Linux multicast issue using IPv4 addresses and IPv6 stack
----------------------------------------------------------
Key: JBAS-8741
URL: https://issues.jboss.org/browse/JBAS-8741
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Integration
Affects Versions: 6.0.0.M4
Reporter: Richard Achmatowicz
Assignee: Shelly McGowan
Fix For: TBD-6.x
The test cases org.jboss.test.util.test.TwiddleUnitTestCase.{testGet, testInvoke} are failing.
One problem is that the twiddle option -o is not correctly handling IPv6 addresses; for example:
[rachmatowicz@soa3 bin]$ ./twiddle.sh -o fec0:0:a16:ffff::13 get "jboss.system:type=Server" Started
15:17:53,066 ERROR [Twiddle] Exec failed
org.jboss.util.NestedRuntimeException: For input string: "0:a16:ffff::13:1090"; - nested throwable: (java.lang.NumberFormatException: For input string: "0:a16:ffff::13:1090")
at org.jboss.console.twiddle.Twiddle$1.getServer(Twiddle.java:208)
at org.jboss.console.twiddle.command.MBeanServerCommand.getMBeanServer(MBeanServerCommand.java:64)
at org.jboss.console.twiddle.command.GetCommand.execute(GetCommand.java:149)
at org.jboss.console.twiddle.Twiddle.main(Twiddle.java:357)
Caused by: java.lang.NumberFormatException: For input string: "0:a16:ffff::13:1090"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Integer.parseInt(Integer.java:458)
at java.lang.Integer.parseInt(Integer.java:499)
at com.sun.jndi.url.rmi.rmiURLContext.getRootURLContext(rmiURLContext.java:86)
at com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.java:182)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1886)
at javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1856)
at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:257)
at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248)
at org.jboss.console.twiddle.Twiddle.createMBeanServerConnection(Twiddle.java:309)
at org.jboss.console.twiddle.Twiddle.connect(Twiddle.java:318)
at org.jboss.console.twiddle.Twiddle.access$400(Twiddle.java:60)
at org.jboss.console.twiddle.Twiddle$1.getServer(Twiddle.java:204)
... 3 more
This is a typical IPv6 URL creation issue, as the issue can be fixed by surrouning the IPv6 address literal in square brackets:
[rachmatowicz@soa3 bin]$ ./twiddle.sh -o [fec0:0:a16:ffff::13] get "jboss.system:type=Server" Started
Started=true
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] Created: (JBAS-8353) PATCH: Support obfuscated System Properties
by Andrew Oliver (JIRA)
PATCH: Support obfuscated System Properties
-------------------------------------------
Key: JBAS-8353
URL: https://jira.jboss.org/browse/JBAS-8353
Project: JBoss Application Server
Issue Type: Patch
Security Level: Public (Everyone can see)
Environment: ALL
Reporter: Andrew Oliver
Assignee: Andrew Oliver
when you put -Djboss.sysprop.obfuscation in your run.conf JBOSS_OPTS, the SecurityIdentityLoginModule decode function is used to decode properties ending in _OBFUSCATED
i.e.
server/default/conf/test.properties
mypassword_OBFUSCATED=5dfc52b51bd35553df8592078de921bc
server/default/deploy/properties-service.xml
<mbean code="org.jboss.varia.property.SystemPropertiesService"
name="jboss:type=Service,name=SystemProperties">
<attribute name="URLList">
./conf/test.properties
</attribute>
</mbean>
then in your System.getProperties you have:
mypassword password
mypassword_OBFUSCATED 5dfc52b51bd35553df8592078de921bc
So you can then use those properties in your config files with ${mypassword}
you can use the same tool in: http://community.jboss.org/wiki/EncryptingDataSourcePasswords to obfuscate passwords in the property file...
This helps you pass dumb security audits that require you to do dumb things that have nothing to do with security but fake security through needless labor is an industry standard that we have to live with.
--
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
13 years, 6 months
[JBoss JIRA] Created: (JBAS-8624) JBoss 5.1.0 sometimes can't undeploy war application
by Dmitry Geurkov (JIRA)
JBoss 5.1.0 sometimes can't undeploy war application
----------------------------------------------------
Key: JBAS-8624
URL: https://jira.jboss.org/browse/JBAS-8624
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-5.1.0.GA
Environment: Windows 7 Operating System, Oracle Java 1.6.0_21
Reporter: Dmitry Geurkov
Priority: Minor
Sometimes during development web applications stuck and can't be undeployed. manually removing war archive is not possible because system says that file is used by another program.
But no other programs use archive except jboss process. Trying to remove stucked web application from Admin Console only stops the application but not removes it completely. The following exception is thrown in during the click on remove button in Admin Console
14:55:51,376 INFO [DeployHandler] Stop, [vfszip:/D:/jboss-5.1.0.GA/server/default/deploy/docflowweb.war/]
14:55:51,376 INFO [DeployHandler] End stop, [vfszip:/D:/jboss-5.1.0.GA/server/default/deploy/docflowweb.war/]
14:55:51,381 INFO [DeployHandler] Remove, [vfszip:/D:/jboss-5.1.0.GA/server/default/deploy/docflowweb.war/]
14:55:53,385 INFO [DeployHandler] Failed to complete command: [remove] for deployment: names=[vfszip:/D:/jboss-5.1.0.GA/server/default/deploy/docflowweb.war/], copyContent=true
java.io.IOException: Failed to delete: DelegatingHandler(a)15550946[path=docflowweb.war context=file:/D:/jboss-5.1.0.GA/server/default/deploy/ real=file:/D:/jboss-5.1.0.GA/server/default/deploy/docflowweb.war]
at org.jboss.system.server.profileservice.repository.BasicDeploymentRepository.removeDeployment(BasicDeploymentRepository.java:268)
at org.jboss.system.server.profileservice.repository.BasicDeploymentRepository.removeDeployment(BasicDeploymentRepository.java:229)
at org.jboss.profileservice.management.upload.remoting.DeployHandler.removeDeployment(DeployHandler.java:176)
at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.remove(AbstractDeployHandler.java:333)
at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:185)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
at org.jboss.remoting.Client.invoke(Client.java:1724)
at org.jboss.remoting.Client.invoke(Client.java:629)
at org.jboss.profileservice.management.upload.remoting.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:305)
at org.jboss.profileservice.management.upload.remoting.StreamingDeploymentTarget.remove(StreamingDeploymentTarget.java:229)
at org.jboss.profileservice.management.upload.DeploymentProgressImpl.remove(DeploymentProgressImpl.java:321)
at org.jboss.profileservice.management.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:94)
at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:120)
at org.rhq.plugins.jbossas5.StandaloneManagedDeploymentComponent.deleteResource(StandaloneManagedDeploymentComponent.java:326)
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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:482)
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:619)
14:55:53,843 ERROR [StandaloneManagedDeploymentComponent] Failed to remove deployment 'vfszip:/D:/jboss-5.1.0.GA/server/default/deploy/docflowweb.war/'.
java.lang.RuntimeException: java.io.IOException: Failed to delete: DelegatingHandler(a)15550946[path=docflowweb.war context=file:/D:/jboss-5.1.0.GA/server/default/deploy/ real=file:/D:/jboss-5.1.0.GA/server/default/deploy/docflowweb.war]
at org.jboss.profileservice.management.upload.remoting.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:313)
at org.jboss.profileservice.management.upload.remoting.StreamingDeploymentTarget.remove(StreamingDeploymentTarget.java:229)
at org.jboss.profileservice.management.upload.DeploymentProgressImpl.remove(DeploymentProgressImpl.java:321)
at org.jboss.profileservice.management.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:94)
at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:120)
at org.rhq.plugins.jbossas5.StandaloneManagedDeploymentComponent.deleteResource(StandaloneManagedDeploymentComponent.java:326)
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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:482)
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:619)
Caused by: java.io.IOException: Failed to delete: DelegatingHandler(a)15550946[path=docflowweb.war context=file:/D:/jboss-5.1.0.GA/server/default/deploy/ real=file:/D:/jboss-5.1.0.GA/server/default/deploy/docflowweb.war]
at org.jboss.system.server.profileservice.repository.BasicDeploymentRepository.removeDeployment(BasicDeploymentRepository.java:268)
at org.jboss.system.server.profileservice.repository.BasicDeploymentRepository.removeDeployment(BasicDeploymentRepository.java:229)
at org.jboss.profileservice.management.upload.remoting.DeployHandler.removeDeployment(DeployHandler.java:176)
at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.remove(AbstractDeployHandler.java:333)
at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:185)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
at org.jboss.remoting.Client.invoke(Client.java:1724)
at org.jboss.remoting.Client.invoke(Client.java:629)
at org.jboss.profileservice.management.upload.remoting.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:305)
... 15 more
14:55:54,153 WARN [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
14:55:54,159 WARN [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
I think some thread in JBoss locks the war archive. something related to new vfs system that was introduced in JBoss 5.
No such problems occurred in JBoss 4.2.3 or early versions.
--
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
13 years, 6 months