[Messaging, JMS & JBossMQ] - JMS provider failure detected
by erez.axis
Hi all.
I have a cluster of 4 nodes. If my master node fails, the other nodes try to reconnect, but the following error appears in my log. I would appreciate any comments any of you may have on this issue.
The log says:
2007-01-30 16:27:42,570 INFO [org.jboss.ejb.plugins.jms.JMSContainerInvoker] Trying to reconnect to JMS provider
2007-01-30 16:27:42,652 WARN [org.jboss.ejb.plugins.jms.JMSContainerInvoker] destination not found: queue/ExAccMDB reason: javax.naming.NameNotFoundException: queue not bound
2007-01-30 16:27:42,652 WARN [org.jboss.ejb.plugins.jms.JMSContainerInvoker] creating a new temporary destination: queue/ExAccMDB
2007-01-30 16:27:42,656 ERROR [org.jboss.ejb.plugins.jms.JMSContainerInvoker] Reconnect failed: JMS provider failure detected:
org.jboss.deployment.DeploymentException: Error during queue setup; - nested throwable: (javax.management.InstanceNotFoundException: jboss.mq:service=DestinationManager is not registered.)
at org.jboss.deployment.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:39)
at org.jboss.ejb.plugins.jms.JMSContainerInvoker.innerStartDelivery(JMSContainerInvoker.java:906)
at org.jboss.ejb.plugins.jms.JMSContainerInvoker$ExceptionListenerImpl.run(JMSContainerInvoker.java:1471)
at java.lang.Thread.run(Thread.java:595)
Caused by: javax.management.InstanceNotFoundException: jboss.mq:service=DestinationManager is not registered.
at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:508)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:638)
at org.jboss.ejb.plugins.jms.JMSContainerInvoker.createDestination(JMSContainerInvoker.java:1201)
at org.jboss.ejb.plugins.jms.JMSContainerInvoker.innerStartDelivery(JMSContainerInvoker.java:872)
... 2 more
2007-01-30 16:27:42,657 ERROR [org.jboss.ejb.plugins.jms.JMSContainerInvoker] Could not set ExceptionListener to null
javax.jms.IllegalStateException: The connection is closed
at org.jboss.mq.Connection.setExceptionListener(Connection.java:559)
at org.jboss.ejb.plugins.jms.JMSContainerInvoker.innerStopDelivery(JMSContainerInvoker.java:973)
at org.jboss.ejb.plugins.jms.JMSContainerInvoker$ExceptionListenerImpl.run(JMSContainerInvoker.java:1447)
at java.lang.Thread.run(Thread.java:595)
2007-01-30 16:27:42,658 ERROR [org.jboss.ejb.plugins.jms.JMSContainerInvoker] Could not stop JMS connection
javax.jms.IllegalStateException: The connection is closed
at org.jboss.mq.Connection.stop(Connection.java:694)
at org.jboss.ejb.plugins.jms.JMSContainerInvoker.innerStopDelivery(JMSContainerInvoker.java:987)
at org.jboss.ejb.plugins.jms.JMSContainerInvoker$ExceptionListenerImpl.run(JMSContainerInvoker.java:1447)
at java.lang.Thread.run(Thread.java:595)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008316#4008316
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008316
19 years, 2 months
[JBoss jBPM] - Re: jBPM and Message Driven Beans
by new4jboss
Yes ProcessInstance is being persisted, the exception only happens now and then when the MDB starts the process before the jsp commits the transaction. When the MDB processes the request after the jsp closes the jbpmContext, it works fine.
| SELECT JBPM_PROCESSINSTANCE.ID_,
| JBPM_PROCESSINSTANCE.START_,
| JBPM_PROCESSINSTANCE.END_,
| JBPM_PROCESSINSTANCE.ROOTTOKEN_,
| JBPM_NODE.NAME_
| FROM JBPM_PROCESSINSTANCE,
| JBPM_TOKEN,
| JBPM_NODE
| WHERE JBPM_PROCESSINSTANCE.ROOTTOKEN_ = JBPM_TOKEN.ID_
| AND JBPM_TOKEN.NODE_ = JBPM_NODE.ID_
| ORDER BY JBPM_PROCESSINSTANCE.START_
|
| output:
|
| ID_ START_ END_ ROOTTOKEN_ NAME_
| ------ ----------------------- ----------------------- ------------- --------
| 696 2007-01-29 20:34:51.532 2007-01-29 20:34:57.003 697 end1
| 700 2007-01-29 20:34:52.704 2007-01-29 20:34:58.772 701 end1
| 704 2007-01-29 20:34:57.976 (null) 705 state1
| 708 2007-01-29 20:34:58.551 2007-01-29 20:35:00.627 709 end1
|
|
Thanks,
Délio Guerra
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008308#4008308
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008308
19 years, 2 months
[JBossCache] - Performance expectations
by mvlior
Hi,
We have been evaluating JBC for production use in our system, and have decided to test PojoCache performance on the hardware we intend to use.
Looking for performance data, we came across this performance test:
http://wiki.jboss.org/wiki/Wiki.jsp?page=WhatShouldWeExpectOfThePojoCache...
The reason for this post is that we tried to run our own, differnt, throughput test, but the performance seemed very degraded in comparison to the expected results, implied by the above reference.
The two tests are not identical, but based on the reference we believe our test should have run significantly faster than it does.
In practice, the test runs about four time slower than it should take to attach these amount of new, very small POJOs.
Can anyone please point out what we have been doing wrong, verify our results, cite other benchmarks of JBoss-Cache etc. ?
Also, if anyone knows about comparison to other caching solutions, we would be interested.
Below are the test details, our results, the configuration file and the test code itself.
Thank you in advance,
Lior Neuman
R&D Team
MailVision LTD
Test environment:
Single node (Local cache),
HW: Dual P4 Xeon 3.0, 2Gb, 80Gb
SW: running Linux 2.6.9-22.ELsmp, JVM: 32bit 1.5.0_06
Remarks:
Our HW has 2G RAM whereas the test had 4G, but only 20% of it are being used throughout the test.
The system was dedicated for the test.
Logging level is set to INFO, sent to console only
Test Plan and Load Pattern
A Local cache, with optimistic-locking and no eviction is created and started.
A single thread, with no added delay, invokes putObject(key, value) where both key and value are new String instances, which have not been attached before.
Basically, the code that runs is the following, in an infinite loop: (full code at the end)
| String key = "/root/Key-" + counter;
| Object value = "dummy" + counter;
|
| pojoCache.putObject(key, value);
|
| if (counter % 1000 == 0) {
| // print counter and elapsed time
| }
|
Test Results
Col1 = Total Objs
Col2 = Time Delta[sec]
Col3 = Throughput [obj/sec]
Col 1 | Col 2 | Col 3
------------------------------
1000 | 4.84 | 206.75
2000 | 2.38 | 277.2
3000 | 2.02 | 324.89
4000 | 1.95 | 357.55
5000 | 2.28 | 371.25
6000 | 2.68 | 371.56
7000 | 3.14 | 363
8000 | 3.52 | 350.82
9000 | 3.95 | 336.34
10000 | 4.31 | 321.84
11000 | 4.71 | 307.41
12000 | 5.14 | 293.26
13000 | 5.70 | 278.84
14000 | 6.13 | 265.38
15000 | 6.52 | 253.05
16000 | 6.89 | 241.82
Graphically, the results show that the throughput starts at approx. 200 Objects/Sec,
climbs to 370 (for 6000 objects), and then linearily
decreases at approx. 12 Objects/Sec for every 1000 objects
added.
Cache Configuration File
<?xml version="1.0" encoding="UTF-8"?>
|
| <!-- ===================================================================== -->
| <!-- -->
| <!-- Sample PojoCache Service Configuration -->
| <!-- -->
| <!-- ===================================================================== -->
|
| <server>
|
| <!-- Used inside JBoss AS -->
| <classpath codebase="./lib" archives="jboss-cache.jar, jgroups.jar" />
|
|
| <!-- ==================================================================== -->
| <!-- Defines configuration -->
| <!-- ==================================================================== -->
|
| <mbean code="org.jboss.cache.aop.PojoCache"
| name="jboss.cache:service=testPojoCache">
|
| <!-- Used inside JBoss AS -->
| <depends>jboss:service=Naming</depends>
| <depends>jboss:service=TransactionManager</depends>
|
| <!--
| Configure the TransactionManager
| -->
| <attribute name="TransactionManagerLookupClass">org.jboss.cache.DummyTransactionManagerLookup</attribute>
|
| <!--
| Node locking scheme:
| OPTIMISTIC
| PESSIMISTIC (default)
| -->
| <attribute name="NodeLockingScheme">OPTIMISTIC</attribute>
|
| <!--
| Note that this attribute is IGNORED if your NodeLockingScheme above is OPTIMISTIC.
|
| Isolation level : SERIALIZABLE
| REPEATABLE_READ (default)
| READ_COMMITTED
| READ_UNCOMMITTED
| NONE
| -->
| <attribute name="IsolationLevel">NONE</attribute>
|
| <!--
| Valid modes are LOCAL
| REPL_ASYNC
| REPL_SYNC
| INVALIDATION_ASYNC
| INVALIDATION_SYNC
| -->
| <attribute name="CacheMode">LOCAL</attribute>
|
| <!-- Name of cluster. Needs to be the same for all clusters, in order
| to find each other
| -->
| <attribute name="ClusterName">MVCache-Cluster</attribute>
|
| <!-- JGroups protocol stack properties. Can also be a URL,
| e.g. file:/home/bela/default.xml
| <attribute name="ClusterProperties"></attribute>
| -->
|
| <attribute name="ClusterConfig">
| <config>
| <!-- UDP: if you have a multihomed machine,
| set the bind_addr attribute to the appropriate NIC IP address, e.g bind_addr="192.168.0.2"
| -->
| <!-- UDP: On Windows machines, because of the media sense feature
| being broken with multicast (even after disabling media sense)
| set the loopback attribute to true -->
| <UDP mcast_addr="228.1.2.3" mcast_port="48866" ip_ttl="64" ip_mcast="true" mcast_send_buf_size="150000"
| mcast_recv_buf_size="80000" ucast_send_buf_size="150000" ucast_recv_buf_size="80000"
| loopback="true" />
| <PING timeout="2000" num_initial_members="3" up_thread="false" down_thread="false" />
| <MERGE2 min_interval="10000" max_interval="20000" />
| <!-- <FD shun="true" up_thread="true" down_thread="true" />-->
| <FD_SOCK />
| <VERIFY_SUSPECT timeout="3000" up_thread="false" down_thread="false" />
| <pbcast.NAKACK gc_lag="50" retransmit_timeout="600,1200,2400,4800" max_xmit_size="8192"
| up_thread="false" down_thread="false" />
| <UNICAST timeout="600,1200,2400" window_size="100" min_threshold="10" down_thread="false" />
| <pbcast.STABLE desired_avg_gossip="20000" up_thread="false" down_thread="false" />
| <FRAG frag_size="8192" down_thread="false" up_thread="false" />
| <pbcast.GMS join_timeout="5000" join_retry_timeout="2000" shun="true" print_local_addr="true" />
| <pbcast.STATE_TRANSFER up_thread="true" down_thread="true" />
| </config>
| </attribute>
|
|
| <!--
| Whether or not to fetch state on joining a cluster
| NOTE this used to be called FetchStateOnStartup and has been renamed to be more descriptive.
| -->
| <attribute name="FetchInMemoryState">true</attribute>
|
| <!--
| The max amount of time (in milliseconds) we wait until the
| initial state (ie. the contents of the cache) are retrieved from
| existing members in a clustered environment
| -->
| <attribute name="InitialStateRetrievalTimeout">20000</attribute>
|
| <!--
| Number of milliseconds to wait until all responses for a
| synchronous call have been received.
| -->
| <attribute name="SyncReplTimeout">15000</attribute>
|
| <!-- Max number of milliseconds to wait for a lock acquisition -->
| <attribute name="LockAcquisitionTimeout">10000</attribute>
|
| <!-- Name of the eviction policy class. -->
| <attribute name="EvictionPolicyClass"></attribute>
|
| <!--
| Indicate whether to use region based marshalling or not. Set this to true if you are running under a scoped
| class loader, e.g., inside an application server. Default is "false".
| -->
| <attribute name="UseRegionBasedMarshalling">false</attribute>
| </mbean>
|
|
| <!-- Uncomment to get a graphical view of the TreeCache MBean above -->
| <!-- <mbean code="org.jboss.cache.TreeCacheView" name="jboss.cache:service=TreeCacheView">-->
| <!-- <depends>jboss.cache:service=TreeCache</depends>-->
| <!-- <attribute name="CacheService">jboss.cache:service=TreeCache</attribute>-->
| <!-- </mbean>-->
|
|
| </server>
Test Code
package test.stress;
|
| import java.util.Properties;
|
| import javax.naming.Context;
|
| import junit.framework.TestCase;
|
| import org.apache.log4j.Logger;
| import org.jboss.cache.PropertyConfigurator;
| import org.jboss.cache.aop.PojoCache;
|
| /**
| *
| * Tests performance with JBC 1.4.0 SP1. Adding new primitive objects only.
| *
| */
| public class StressTestAdd extends TestCase {
|
| static {
| org.apache.log4j.PropertyConfigurator.configure("resources/test.log4j");
| }
|
| private static final long TEST_TIME_SECONDS = 70;
| private static final String CONFIG_FILENAME = "resources/session-cache/local_cache.xml";
| private static final Logger log = Logger.getLogger(StressTestAdd.class);
|
| public void testOneCache() throws Exception {
|
| // configure cache, don't start it yet
| Properties prop = new Properties();
| prop.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.cache.transaction.DummyContextFactory");
| final PojoCache pojoCache = new PojoCache();
| org.jboss.cache.PropertyConfigurator config = new PropertyConfigurator();
| config.configure(pojoCache, CONFIG_FILENAME);
|
|
| // declare runner thread
| Thread runner = new Thread(new Runnable() {
|
| private int counter = 0;
| boolean running = true;
| private final long start = System.currentTimeMillis();
|
| public void run() {
| try {
| while (running) {
| counter++;
|
| // key and value for attach(key, value);
| String key = "/root/Key-" + counter;
| Object value = "dummy" + counter;
|
| // put in cache
| Object previous = pojoCache.putObject(key, value);
|
| // verify no object was already attached with that key
| if (previous != null) {
| log.error("A previous key existed");
| running = false;
| fail("Attempt to update an existing key " + key);
| }
|
| // display counter every 1000 invocations
| if (counter % 1000 == 0) {
| long elapsed = System.currentTimeMillis() - start; // approx.
| log.info("Number = " + counter + ", after approx. "
| + elapsed / 1000.0 + " seconds.");
| }
| }
| } catch (Exception e) {
| log.error("Exception caught: ", e);
| fail(e.toString());
| }
| }
| });
|
|
| // start stress
| log.info("Stress test about to begin...");
|
| pojoCache.start();
| runner.start();
| Thread.sleep(TEST_TIME_SECONDS * 1000);
|
| log.info("...Stress test ended");
|
| }
|
| }
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008305#4008305
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008305
19 years, 2 months