[Deployers on JBoss (Deployers/JBoss)] - More than two QUARTZ schedullar instances in JBoss creates i
by Hema.T
Hi,
JBoss does not run the third scheduler application (it starts the first two) in the same instance. Here is my scenario:
I have three independant applications that run jobs, based on the scheduler. Each one is using its own quartz scheduler to schedule the jobs.
Now, we have created Service archives(.sar) out of this applications and tried to deploy all the three in the same JBoss. When we run these 3 .sars in 3 different JBoss severs, it work fine.
The moment we club all the 3 Sars together, the JBoss is able to start only the first two Sars and the third one is not running.
There is no deployment errors.
Two Sar are started and working fine, but the third one is not running (though deployed without any errors).
Is there any limitation in JBoss, that JBoss can support only 2 quartz instances and not more than that?
This is a very specific scenario. Any information in this regard would be of great help.
Thanks
Hema T
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4129620#4129620
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4129620
18 years, 1 month
[Design of JBoss Transaction Services] - Re: Transaction bridging bug?
by kadlecp
And another possible bug is leaking memory bug....
org.jboss.txbridge.TxBridgeManager should contain method similar to this one
| public synchronized static void disposeInboundBridge(String externalTxId) {
|
| log.trace("disposeInboundBridge()");
|
| Xid xid = txIdMappings.remove(externalTxId);
| if (xid == null) {
| log.error("inconsistency: null jta xid");
| return;
| }
|
| InboundBridge inboundBridge = inboundBridgeMappings.remove(xid);
|
| if (inboundBridge == null) {
| log.error("inconsistency: null inbound bridge");
| return;
| }
|
| try {
|
| inboundBridge.stop();
| } catch (Exception e) {
| e.printStackTrace();
| }
| }
|
In my opinion method similar to method above should be called by BridgeParticipantAT when participant commits or rolls back. Somebody must dispose InboundBridge from maps in TxManagerBridge....
Pavel
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4129593#4129593
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4129593
18 years, 1 month
[Design of JMX on JBoss (JBoss/JMX)] - JBAS-5220 - Twiddle not displaying Platform MBean.
by vickyk
The MBeanServer which is passed to InvokerAdapterService is org.jboss.mx.server.MBeanServerImpl , this MBeanServer is created during LazyMBeanServer.resetToJBossServer(server) call in org.jboss.system.server.ServerImpl .
The twiddle gets the MBean's which are registered in org.jboss.mx.server.MBeanServerImpl , the Platform MBean's are not registered in it.
The InvokerAdapterService should have the reference of the LazyMBeanServer when this system property is set.
-Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl
This can be done by making changes in InvokerAdapterService as
Index: InvokerAdaptorService.java
| ===================================================================
| --- InvokerAdaptorService.java (revision 69558)
| +++ InvokerAdaptorService.java (working copy)
| @@ -43,6 +43,7 @@
| import org.jboss.jmx.adaptor.rmi.RMINotificationListener;
| import org.jboss.jmx.connector.invoker.client.InvokerAdaptorException;
| import org.jboss.mx.server.ServerConstants;
| +import org.jboss.system.server.jmx.LazyMBeanServer;
| import org.jboss.system.Registry;
| import org.jboss.system.ServiceMBeanSupport;
|
| @@ -263,6 +264,7 @@
| Class[] paramTypes = method.getParameterTypes();
| Method mbeanServerMethod = MBeanServer.class.getMethod(name,
| paramTypes);
| + server = LazyMBeanServer.getRegisteredMBeanServer(server);
| value = mbeanServerMethod.invoke(server, args);
| }
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4129559#4129559
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4129559
18 years, 1 month
[Design the new POJO MicroContainer] - Re: Concurrent deployments
by bstansberry@jboss.com
The ControllerMode approach sounds better. I expect starting a thread in create() won't help much in many cases, as the main thread will quickly proceed to start and then block.
Unfortunately, JBM opens 2 of the 3 underlying JChannels in AS 5, and it's deploying as an mbean.
HAPartition is opening the 3rd channel and definitely can benefit from this.
The other services (JBC) are opening MuxChannels, which really just multiplex on the underlying JChannel and thus don't block. But, we want to move to using the JGroups shared transport, in which case each service will have its own JChannel; I need to think through how to use the ControllerMode to improve the startup speed.
"adrian(a)jboss.org" wrote :
| The Deployments (which are also managed for dependency by the MC)
| also run in "manual" mode which might be a good thing
| since it would still ensure that classloaders are constructed in a predictable order
| on one thread.
Did you mean the "Deployers" here?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4129518#4129518
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4129518
18 years, 1 month