[JCA/JBoss] - Datasource connection timeout
by ben_ben
Hi,
We're using pooled database connections through JBoss 4 connecting to an Ingres database. Everything works fine when the system first starts up, connections successfully contact the database and get reused via the connection pool. However...
...when the system is left alone for a reasonable length of time (e.g. 4-5 hours) the next use of a database connection times out, leaving a broken connection which is then returned to the pool. We've changed the datasource configuration to validate connections it gets out of the pool so that the system can continue to run, but we can't work out why the time-outs occur. We've also connected from a stand alone application using the same jdbc driver class to our database (i.e. bypassing JBoss) and the connections can be used and left alone with no problems at all, which leads us to think it's a datasource configuration problem.
Has anyone got any ideas?
Thanks
Ben
Datasource configuration:
| <?xml version="1.0" encoding="UTF-8"?>
|
| <datasources>
|
| <local-tx-datasource>
| <jndi-name>ingresDS</jndi-name>
| <!-- connection url -->
| <connection-url>jdbc:edbc://server:DV7/database</connection-url>
| <!-- auto commit -->
| <connection-property name="autocommit_mode">single</connection-property>
| <!-- only lock on non-read -->
| <transaction-isolation>TRANSACTION_READ_UNCOMMITTED</transaction-isolation>
| <!-- sql to run when new connections are created, doubly make sure locking isn't on -->
| <new-connection-sql>set lockmode session where readlock = nolock</new-connection-sql>
| <!-- jdbc driver class -->
| <driver-class>ca.edbc.jdbc.EdbcDriver</driver-class>
| <!-- minimum connection pool size -->
| <min-pool-size>5</min-pool-size>
| <!-- maximum connection pool size -->
| <max-pool-size>30</max-pool-size>
| <!-- timeout for idle connections -->
| <idle-timeout-minutes>0</idle-timeout-minutes>
| <!-- security domain name -->
| <security-domain>ingres</security-domain>
| <!-- test for stale connections -->
| <check-valid-connection-sql>select count(*) from table</check-valid-connection-sql>
| </local-tx-datasource>
|
| </datasources>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965215#3965215
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965215
19 years, 10 months
[JBossCache] - IllegalStateException on commit
by cw_krebs
Hi,
I played little bit around with the tree cache using the optimistic locking scheme. I wrote a small unit tests (s.b.), which tries to modify the same node at the same time by different threads in different transactions. At the first view, it looks like, that everything works fine. But running the test multiple times showed, that sometimes an IllegalStateException instead of CacheException on commiting the transaction will be thrown:
| java.lang.RuntimeException:
| at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1091)
| at org.jboss.cache.interceptors.OrderedSynchronizationHandler.beforeCompletion(OrderedSynchronizationHandler.java:75)
| at org.objectweb.jotm.SubCoordinator.doBeforeCompletion(SubCoordinator.java:1487)
| at org.objectweb.jotm.SubCoordinator.commit_one_phase(SubCoordinator.java:416)
| at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:239)
| at de.gameduell.server.cache.PureOptimisticLockingTest$Worker.run(PureOptimisticLockingTest.java:137)
| Caused by: java.lang.IllegalStateException: there is already a writer holding the lock: GlobalTransaction:<null>:41
| at org.jboss.cache.lock.LockMap.setWriterIfNotNull(LockMap.java:96)
| at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:204)
| at org.jboss.cache.Node.acquireWriteLock(Node.java:431)
| at org.jboss.cache.Node.acquire(Node.java:386)
| at org.jboss.cache.interceptors.OptimisticLockingInterceptor.lockNodes(OptimisticLockingInterceptor.java:149)
| at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:76)
| at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
| at org.jboss.cache.interceptors.TxInterceptor.runPreparePhase(TxInterceptor.java:804)
| at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1069)
| ... 5 more
Running the TreeCache I used JBossCache 1.4.0.GA and JOTM 2.0.10 with the following cache-config:
<?xml version="1.0" encoding="UTF-8"?>
| <server>
| <mbean code="org.jboss.cache.TreeCache" name="jboss.cache:service=TreeCache">
| <attribute name="NodeLockingScheme">OPTIMISTIC</attribute>
| <attribute name="CacheMode">LOCAL</attribute>
| </mbean>
| </server>
|
|
That's my JUnit-Test:
| import javax.transaction.Transaction;
| import javax.transaction.TransactionManager;
|
| import junit.framework.TestCase;
|
| import org.jboss.cache.CacheException;
| import org.jboss.cache.PropertyConfigurator;
| import org.jboss.cache.TransactionManagerLookup;
| import org.jboss.cache.TreeCache;
| import org.objectweb.jotm.Current;
|
| import EDU.oswego.cs.dl.util.concurrent.CyclicBarrier;
|
|
| /**
| * OptimisticLockingTest
| */
| public class OptimisticLockingTest extends TestCase {
|
| private static final String NODE_PATH = "/path/node";
| private static final String KEY = "key";
|
| private static final Current jotm = new Current();
|
| private TreeCache cache;
|
| protected void setUp() throws Exception {
| super.setUp();
|
| cache = new TreeCache();
| final PropertyConfigurator config = new PropertyConfigurator();
| cache.setTransactionManagerLookup(new TransactionManagerLookup() {
| public TransactionManager getTransactionManager() throws Exception {
| return Current.getTransactionManager();
| }
| });
| config.configure(cache, this.getClass().getResourceAsStream(
| "/cache-config.xml"));
| cache.startService();
| }
|
| public void testSimultanWrite() throws Exception {
| for (int i = 2; i < 20; i++) {
| System.out.println(">> testing simultaneous writes with " + i
| + " threads...");
| testSimultanWrite(i);
| }
| }
|
| public void testSimultanWrite(final int _numThreads)
| throws Exception {
| final CyclicBarrier barrier = new CyclicBarrier(_numThreads);
|
| Worker[] workers = new Worker[_numThreads];
| for (int i = 0; i < workers.length; i++) {
| workers = new Worker();
| workers.barrier = barrier;
| workers.value = "worker" + i;
| if (i == 0) {
| workers.isMaster = true;
| }
| workers.start();
| }
|
| for (int i = 0; i < workers.length; i++) {
| workers.join();
| }
|
| assertNull(workers[0].exception);
|
| for (int i = 0; i < workers.length; i++) {
| assertNull("rollback failed", workers.rollbackException);
| }
|
| for (int i = 1; i < workers.length; i++) {
| assertNotNull("missing exception", workers.exception);
| assertTrue("exception is not of type CacheException",
| workers.exception.getCause() instanceof CacheException);
| }
| assertEquals("worker0", cache.get(NODE_PATH, KEY));
|
| cache.getTransactionManager().begin();
| cache.remove(NODE_PATH);
| cache.getTransactionManager().commit();
| }
|
| private class Worker extends Thread {
|
| private CyclicBarrier barrier;
| private Exception exception;
| private Exception rollbackException;
| private String value;
| private boolean isMaster;
|
| /**
| * @see java.lang.Thread#run()
| */
| public void run() {
|
| final TransactionManager txManager = cache.getTransactionManager();
|
| Transaction tx = null;
| try {
| // wait for all threads started
| barrier.barrier();
|
| if (isMaster) {
| txManager.begin();
| cache.put(NODE_PATH, KEY, value);
|
| // lets the other threads start writing
| barrier.barrier();
|
| // wait for other threads to their modification
| barrier.barrier();
|
| // commit first
| tx = txManager.getTransaction();
| tx.commit();
|
| // lets the other threads commit
| barrier.barrier();
| } else {
| // wait for master to start transaction
| barrier.barrier();
|
| txManager.begin();
| cache.put(NODE_PATH, KEY, value);
|
| // signal modification
| barrier.barrier();
|
| // wait for master to commit transaction
| barrier.barrier();
| tx = txManager.getTransaction();
| tx.commit();
| }
| } catch (Exception e) {
| exception = e;
| try {
| tx.rollback();
| } catch (Exception e1) {
| rollbackException = e1;
| }
| }
| }
| }
| }
|
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965212#3965212
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965212
19 years, 10 months
[JBoss Seam] - servlet in seam application
by jason_rency
All,
my question may looks strange,
I tried to get a common java servlet work within a seam application by adding the following line in web.xml: (calculator is the servlet name)
<servlet>
| <servlet-name>Calculator</servlet-name>
| <servlet-class>server.Calculator</servlet-class>
| </servlet>
|
| <servlet-mapping>
| <servlet-name>Calculator</servlet-name>
| <url-pattern>/Calculator</url-pattern>
| </servlet-mapping>
the servlet worked fine (I called it from a mobile phone, that's why I need a servlet) after I deployed the seam app with this servlet. but when I tried to use the seam app itself by browser (the hotel booking example), it just didn't work. seems there are conflicts between the new lines I added and the old lines in web.xml .
then I changed the servlet by adding ejb3 annotation (it's strange, huh? a ejb3 staless session bean servlet) and re-deploy the app again (with the new lines in the web.xml). then the servlet (also a session bean) worked well and the hotel booking example worked fine as normal.
then added persistency statement to this servlet (the session bean) but I got a NPE, which seems the Entity manager is null and I can't get the entity manager properly in a servlet which is also a ejb3 session bean?
the code is like this:
package server;
|
| import javax.ejb.Stateless;
| import javax.servlet.*;
| import javax.servlet.http.*;
| import java.io.*;
| import java.text.*;
| import javax.persistence.EntityManager;
| import javax.persistence.PersistenceContext;
|
|
| @Stateless
| public class Calculator extends HttpServlet implements cacu
| {
| @PersistenceContext
| private EntityManager em;
| private Reguser user;
|
| public void doPost(HttpServletRequest request,HttpServletResponse response)
| throws IOException, ServletException
| {
| response.setContentType("text/plain");
| PrintWriter out = response.getWriter();
| String uid = request.getParameter("uid");
| String passwd =request.getParameter("passwd");
| user = em.find(Reguser.class, "rency"); (exception here, em is null)
| String email = user.getEmail();
| System.out.print(email);
| out.println("just a test: "+ uid);
| }
|
| }
exception was:
10:16:49,501 ERROR [[Calculator]] Servlet.service() for servlet Calculator threw exception
| java.lang.NullPointerException
| at server.Calculator.doPost(Calculator.java:26) (the entity manager) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
| at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
| at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
| at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
| at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
| at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
| at java.lang.Thread.run(Thread.java:595)
also I added a ejb3 web service in the app, the web service work well: code like this:
interface:
package server;
|
| import javax.jws.WebService;
| import javax.jws.WebMethod;
|
|
| @WebService
| public interface findEmail {
|
| @WebMethod public String findemail(String username);
|
| }
the implementation:
package server;
|
| import javax.ejb.Stateless;
| import javax.jws.WebService;
| import javax.persistence.EntityManager;
| import javax.persistence.PersistenceContext;
|
|
| @Stateless
| @WebService(endpointInterface="server.findEmail")
|
| public class findemailimpl implements findemail {
|
| @PersistenceContext
| private EntityManager em;
| private Reguser user;
|
| public String finduser(String username)
| {
| em.find(Reguser.class, username);
| String email = user.getEmail();
| return email;
| }
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965206#3965206
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965206
19 years, 10 months
[Installation, Configuration & Deployment] - Datasource connection timeouts
by ben_ben
Hi,
We're using pooled database connections through JBoss 4 connecting to an Ingres database. Everything works fine when the system first starts up, connections successfully contact the database and get reused via the connection pool. However...
...when the system is left alone for a reasonable length of time (e.g. 4-5 hours) the next use of a database connection times out, leaving a broken connection which is then returned to the pool. We've changed the datasource configuration to validate connections it gets out of the pool so that the system can continue to run, but we can't work out why the time-outs occur. We've also connected from a stand alone application using the same jdbc driver class to our database (i.e. bypassing JBoss) and the connections can be used and left alone with no problems at all, which leads us to think it's a datasource configuration problem.
Has anyone got any ideas?
Thanks
Ben
Datasource configuration:
| <?xml version="1.0" encoding="UTF-8"?>
|
| <datasources>
|
| <local-tx-datasource>
| <jndi-name>ingresDS</jndi-name>
| <!-- connection url -->
| <connection-url>jdbc:edbc://server:DV7/database</connection-url>
| <!-- auto commit -->
| <connection-property name="autocommit_mode">single</connection-property>
| <!-- only lock on non-read -->
| <transaction-isolation>TRANSACTION_READ_UNCOMMITTED</transaction-isolation>
| <!-- sql to run when new connections are created, doubly make sure locking isn't on -->
| <new-connection-sql>set lockmode session where readlock = nolock</new-connection-sql>
| <!-- jdbc driver class -->
| <driver-class>ca.edbc.jdbc.EdbcDriver</driver-class>
| <!-- minimum connection pool size -->
| <min-pool-size>5</min-pool-size>
| <!-- maximum connection pool size -->
| <max-pool-size>30</max-pool-size>
| <!-- timeout for idle connections -->
| <idle-timeout-minutes>0</idle-timeout-minutes>
| <!-- security domain name -->
| <security-domain>ingres</security-domain>
| <!-- test for stale connections -->
| <check-valid-connection-sql>select count(*) from table</check-valid-connection-sql>
| </local-tx-datasource>
|
| </datasources>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965204#3965204
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965204
19 years, 10 months
[J2EE Design Patterns] - how does jBPM deal with J2EE-Patterns?
by stefkrech
Hi,
i'm relativly new to jBPM - UTFSE, forum-browsing, documentation etc did not realy help to solve my "problem":
i wonder where the instantiation of ProcessDefinitions does fit with the concept of the core J2EE-Patterns, p.e. if i have one JbpmConfiguration and need different ProcessDefinitions.
Should it be placed in the SessionFacade? So the session could hold the actual state of the process-instance.
Or would it be the job for the ServiceLocator? But the ServiceLocator seems to deal with ejb-components.
Do BPM-design-questions fit with the j2ee-pattern-scheme at all?
Maybe the instantiation should be done via a simple factory or some other GoF-Pattern. If so, sould the factory be realized within a session-bean.
appreciate or any hints, tips, comments and rants ...
regards,
Stefan
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965203#3965203
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965203
19 years, 10 months
[Tomcat, HTTPD, Servlets & JSP] - How to implement JGroups-RMI Clustering in Tomcat
by sivasharma
Hai!
I had tried to replicate my RMI Server using JGROUPS in the following manner.
RMI Server running in one node with rmireplicated code using jgroups api (downloaded from soucreforge.net) and Tomcat server running on
another node. I had copied replicated rmi class files from RMI Server and pasted it into a WEB-INF/classes directory.
First I had started the RMI Server. It displayes message as Become Group Coordinator found in Remote Home.
Then I had started the Tomcat server and call my apllication using IE. When a client contacts the RMI Server it shows error..
RMI Side
[WARN] UDP - -packet from /172.178.100.79:3747 has different version ( ??") from
ours (0227). This may cause problems
[ERROR] UDP - -exception=java.io.StreamCorruptedException: invalid stream header
at java.io.ObjectInputStream.readStreamHeader(Unknown Source)
at java.io.ObjectInputStream.(Unknown Source)
at org.jgroups.protocols.UDP.handleIncomingUdpPacket(UDP.java:670)
at org.jgroups.protocols.UDP.run(UDP.java:249)
at java.lang.Thread.run(Unknown Source)
Tomcat Side
Aug 14, 2006 1:31:18 PM org.jgroups.protocols.TP handleIncomingPacket
WARNING: packet from 172.178.100.77:2189 has different version (12338) from ours
(231). This may cause problems
Aug 15, 2006 1:31:18 PM org.jgroups.protocols.TP handleIncomingPacket
SEVERE: failed unmarshalling message
java.io.EOFException
at java.io.DataInputStream.readShort(DataInputStream.java:287)
at org.jgroups.Message.readFrom(Message.java:624)
at org.jgroups.protocols.TP.bufferToMessage(TP.java:982)
at org.jgroups.protocols.TP.handleIncomingPacket(TP.java:838)
at org.jgroups.protocols.TP.access$200(TP.java:44)
at org.jgroups.protocols.TP$IncomingPacketHandler.run(TP.java:1290)
How to solve this issue. Any help regard this highly appreciated..
Thanks and Regards
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965197#3965197
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965197
19 years, 10 months