[JBoss Messaging] - Re: strange failover behaviour in clustered config
by timfox
Well, we could add such a switch, but it doesn't tackle the problem of all messages going to one node every time you do a normal startup.
Also, going ahead, most people want to move away from the old style "JBoss MQ" model where you have a single shared database which all nodes use - since this turns into a performance bottleneck.
For better scalability, we're going to support each node having its own file based persistent storage, or it's own database. (Of course we'll support the old model too)
Typically all the file based stores would be persisted on some kind of SAN or shared file system with redundancy built in.
If a node fails, another one takes over.
When starting up from complete power failure, if a particular node doesn't start - e.g. the box is dead, then you could just start it on another node with the same server id, this could be done with a simple script.
You could probably do something similar then you wouldn't have to worry about starting the node from the same crashed box.
But having all messages on one node is not really a scalable solution.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063479#4063479
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063479
19Â years
[Persistence, JBoss/CMP, Hibernate, Database] - Transactions timing out?
by greigm
Can anyone help me figure out my problem, I basically have a simple jsp deployed in a web-app (war) which uses JNDI to lookup an EJB3 stateless Bean and execute a single method. The method loads a large amount of data from a table into memory then loops through this data, performing a select to find a related record and updating/inserting any changes.
All done through a single xa Datasource (MSSQL2000 using jtds). I'm finding that the process can perform thousands of SQL statements then suddenly I receive:
2007-07-12 14:06:35,841 WARN [com.arjuna.ats.arjuna.logging.arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.BasicAction_58] - Abort of action id -3f57feef:6e1:469615dd:e0 invoked while multiple threads active within it.
| 2007-07-12 14:06:35,841 WARN [com.arjuna.ats.arjuna.logging.arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.CheckedAction_2] - CheckedAction::check - atomic action -3f57feef:6e1:469615dd:e0 aborting with 1 threads active!
| 2007-07-12 14:06:35,857 FATAL [com.myco.dao.workauth.WorkAuthorisationSQLSDAO] SQLException caught in findByMasterReference
| org.jboss.util.NestedSQLException: Transaction is not active: tx=TransactionImple < ac, BasicAction: -3f57feef:6e1:469615dd:e0 status: ActionStatus.ABORTING >; - nested throwable: (javax.resource.ResourceException: Transaction is not active: tx=TransactionImple < ac, BasicAction: -3f57feef:6e1:469615dd:e0 status: ActionStatus.ABORTING >)
| at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:94)
All SQL is performed in the old fashioned getDatasource->getConnection->getStatement old-school JDBC commands and not via Entity or other persistence tools.
The error seems to happen after a large number of selects with no inserts/updates - my question, is there an implied transaction which times out because there have been no inserts/updates for a long time (even though there have been selects)? If so is there any way to prevent this timeout?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063474#4063474
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063474
19Â years
[JBossWS] - Latency problem due to small TCP/IP packetsize
by mhohmann
Hello,
we run a couple of webservices as interfaces to some datawarehouse reports. The webservices take some parameters in the soap-request to run the sql-querys against the DB. The result-data is returned as an XML-element in the body of the soap-reponse.
An average reponse is about 130KB. With an MTU around 1500Byte the response should fit in <100 packets, but a network sniff showed that the server generates >10,000 packets for one response. The push-option in the IP-header is also set which instructs the IP-stack to send the paket immediatly before its payload-capacity is filled.
This leads to latency problems because the firewall between the server and the client-applications takes more time to examine the packets. In case of a 130KB response a webservice-request through the firewall takes 10 seconds compare to <2 seconds without the firewall between client and server.
Are there any options to configure the packetsize or some buffer parameters to change the behavior of packet generation (or Sockets) in JBoss, JBossWS or JVM? I really don´t know where to search for a Solution.
I hope someone can help me.
I'm looking foreward for your replies. Thanks in advance.
Michael Hohmann
PS: Sorry for my bad english
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063470#4063470
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063470
19Â years
[JBossCache] - very slow bdbje loader implementation (CR3)
by srnm
I have a simple test case that puts 1000 objects into a node.
Using the bdbje loader the test runs in >100s
Using the jdbm loader the test runs in <10s
I looked at the loader implementations and I see that bdbje loader is storing each node as a HashMap, and that each put reads the hashmap from disk, modifies it and then writes it. Put another way, the entire node is being read, and written as it grows.
In contrast, the jdbm implementation uses a "flat" key space and therefore can take advantage of the b-tree structure to find and modify individual items.
I'd go so far as to say that the bdbje loader is currently unusable.
Are there any plans to fix this?
My apologies, I can't volunteer to fix this right now.
I'm new here, so please forgive if I have missed something...
thanks in advance,
Steven Marcus
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063468#4063468
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063468
19Â years