[Design of Messaging on JBoss (Messaging/JBoss)] - Broken build
by timfox
I've had a deeper look into way the build started failing recently/
Whilst it is true it was actually the randomfailovertest failing (Jeff was right), the reason for this seems to be the following in the logs:
| (group:JBM-InVM-Transport-Threads-31601333):) Failed to delete consumer
| javax.management.InstanceNotFoundException: org.jboss.messaging:module=Core,type=Queue,address="FailoverTestAddress",name="FailoverTestAddress"
| at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(DefaultMBeanServerInterceptor.java:374)
| at com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanServer.java:527)
| at org.jboss.messaging.core.management.impl.ManagementServiceImpl.unregisterFromJMX(ManagementServiceImpl.java:360)
| at org.jboss.messaging.core.management.impl.ManagementServiceImpl.unregisterResource(ManagementServiceImpl.java:298)
| at org.jboss.messaging.core.management.impl.ManagementServiceImpl.unregisterQueue(ManagementServiceImpl.java:228)
| at org.jboss.messaging.core.postoffice.impl.PostOfficeImpl.removeBinding(PostOfficeImpl.java:239)
| at org.jboss.messaging.core.server.impl.ServerSessionImpl.doHandleDeleteQueue(ServerSessionImpl.java:580)
| at org.jboss.messaging.core.server.impl.ServerSessionImpl.handleDeleteQueue(ServerSessionImpl.java:555)
| at org.jboss.messaging.core.server.impl.ServerSessionPacketHandler.handlePacket(ServerSessionPacketHandler.java:127)
| at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.handlePacket(RemotingConnectionImpl.java:1306)
| at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.access$1(RemotingConnectionImpl.java:1242)
| at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:438)
| at org.jboss.messaging.core.remoting.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:322)
| at org.jboss.messaging.core.remoting.impl.invm.InVMConnection$1.run(InVMConnection.java:118)
| at org.jboss.messaging.util.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105)
| at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
| at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
| at java.lang.Thread.run(Thread.java:595)
|
This only started to occur (failing most test runs) after svn revision 5361, which contains the following change:
| - ManagementService managementService = new ManagementServiceImpl(ManagementFactory.getPlatformMBeanServer(), false);
| + ManagementService managementService = new ManagementServiceImpl(ManagementFactory.getPlatformMBeanServer(), config.isJMXManagementEnabled());
|
So basically now jmx server is enabled by default, previously it wasn't. This would explain why we only see the error after the commit.
I have put a temporary hack in postoffficeImpl:removeBinding to get the suite to run ok, but this needs to be solved properly.
I suspect it's being called after the managementservice has shutdown.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189480#4189480
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189480
17 years, 4 months
[Design of POJO Server] - Re: VFS Permissions - JBMICROCONT-149
by anil.saldhana@jboss.com
"alesj" wrote : "anil.saldhana(a)jboss.com" wrote : Issues:
| | a) AOP uses vfsmemory:// pattern. Not sure about assigning perms to a codesource URL in memory. Maybe vfs real url may help.
| And there are others - assembled stuff --> vfs://.
| Plus users can add their own protocols. ;-)
|
| Dunno what to do about those,
| as they don't have logical 'real' representation.
We can deal with custom protocols. But we would need some static content in the URL that goes into the codesource url.
Something like:
<protocol>://<static>/<dynamic>
|
| vfsmemory://jboss/microcontainer/uuid-string
|
Then the onus is on the system administrator to adequately assign permissions. I still see issues with rogue applications trying to mess in memory.
Maybe Scott/Adrian can think of something....
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189474#4189474
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189474
17 years, 4 months