[JBoss Cache] - SuspectException seen by one node when the other node in the cluster goes down
by Aditi Andhare
Aditi Andhare [http://community.jboss.org/people/aditi.andhare] created the discussion
"SuspectException seen by one node when the other node in the cluster goes down"
To view the discussion, visit: http://community.jboss.org/message/570224#570224
--------------------------------------------------------------
Hi all,
We are using the following configuration:
jGroups 3.2.0GA
jboss cache 3.2.0 GA
jboss AS 5.1.0 GA
I have two nodes in my clustered setup. Consider the case when there is continous load on both of these nodes. Now I stop one of the nodes in the cluster. The other node which is still active sees the SuspectException for a very few transactions hence affecting transactions performed by the active node. Here is the stack trace:
org.jboss.cache.SuspectException: Suspected member: 10.17.221.19:59378
at org.jboss.cache.RPCManagerImpl.callRemoteMethods(RPCManagerImpl.java:764)
at org.jboss.cache.RPCManagerImpl.callRemoteMethods(RPCManagerImpl.java:716)
at org.jboss.cache.RPCManagerImpl.callRemoteMethods(RPCManagerImpl.java:721)
at org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:161)
at org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:135)
at org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:107)
at org.jboss.cache.interceptors.ReplicationInterceptor.handleCrudMethod(ReplicationInterceptor.java:160)
at org.jboss.cache.interceptors.ReplicationInterceptor.visitPutDataMapCommand(ReplicationInterceptor.java:113)
at org.jboss.cache.commands.write.PutDataMapCommand.acceptVisitor(PutDataMapCommand.java:104)
at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131)
at org.jboss.cache.commands.AbstractVisitor.visitPutDataMapCommand(AbstractVisitor.java:60)
at org.jboss.cache.commands.write.PutDataMapCommand.acceptVisitor(PutDataMapCommand.java:104)
at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.jboss.cache.interceptors.TxInterceptor.attachGtxAndPassUpChain(TxInterceptor.java:301)
at org.jboss.cache.interceptors.TxInterceptor.handleDefault(TxInterceptor.java:283)
at org.jboss.cache.commands.AbstractVisitor.visitPutDataMapCommand(AbstractVisitor.java:60)
at org.jboss.cache.commands.write.PutDataMapCommand.acceptVisitor(PutDataMapCommand.java:104)
at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.jboss.cache.interceptors.CacheMgmtInterceptor.visitPutDataMapCommand(CacheMgmtInterceptor.java:97)
at org.jboss.cache.commands.write.PutDataMapCommand.acceptVisitor(PutDataMapCommand.java:104)
at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.jboss.cache.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:178)
at org.jboss.cache.interceptors.InvocationContextInterceptor.visitPutDataMapCommand(InvocationContextInterceptor.java:64)
at org.jboss.cache.commands.write.PutDataMapCommand.acceptVisitor(PutDataMapCommand.java:104)
at org.jboss.cache.interceptors.InterceptorChain.invoke(InterceptorChain.java:287)
at org.jboss.cache.invocation.CacheInvocationDelegate.invokePut(CacheInvocationDelegate.java:705)
at org.jboss.cache.invocation.CacheInvocationDelegate.put(CacheInvocationDelegate.java:519)
at org.jboss.cache.invocation.NodeInvocationDelegate.addChild(NodeInvocationDelegate.java:337)
at com.openwave.servicebroker.util.CacheUtil.createNode(CacheUtil.java:204)
at com.openwave.servicebroker.ServiceBrokerImpl.serviceRequest(ServiceBrokerImpl.java:838)
at servicebroker.ServiceBroker$Processor$serviceRequest.process(ServiceBroker.java:809)
at servicebroker.ServiceBroker$Processor.process(ServiceBroker.java:626)
at org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:252)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
The code statement which causes the above exception is not in a transaction. Here is the FD configurations in the conf files:
<FD_SOCK/>
<FD max_tries="20" shun="false" timeout="60000"/>
<VERIFY_SUSPECT timeout="1500"/>
Upon analysis of logs I see that this exception is always caused during the short time gap when one node is suspected and when the cluster recieves a new view.
2010-10-29 *03:04:12,480* INFO [org.jboss.ha.framework.interfaces.HAPartition.lifecycle.ClusterOne] (VERIFY_SUSPECT.TimerThread,ClusterOne,10.17.221.18:48782) Suspected member: 10.17.221.19:34650
2010-10-29 *03:04:12,534* INFO [org.jboss.ha.framework.interfaces.HAPartition.lifecycle.ClusterOne] (Incoming-17,10.17.221.18:48782) New cluster view for partition ClusterOne (id: 4, delta: -1) : [10.17.221.18:1099]
So my question is:
1. Is this an expected behaviour?
2. Whenever a member in a cluster goes down, will all the active transactions seen by the other active members in the cluster fail due to the Suspect Exception?
3. Or are there any configuration settings that I am missing out here?
Thanks in advance for all your help.
Aditi
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/570224#570224]
Start a new discussion in JBoss Cache at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 5 months
[EJB3] - Re: JBoss 5 --> JBoss 6 M5 EJB3 already registered
by Federica De Martin
tecnico [http://community.jboss.org/people/tecnico] created the discussion
"Re: JBoss 5 --> JBoss 6 M5 EJB3 already registered"
To view the discussion, visit: http://community.jboss.org/message/570221#570221
--------------------------------------------------------------
Thank you for your answer.
Actually in my ear there were more then one time the same ejb:
myear.ear
mywar.war
myejb.jar
myejb.jar
and this was working in JBoss 5.
I'm packaging my application with maven so now I've changed the dependencies in the pom.xml of the "war project" updating the scope of the ejb project to provided:
>
>
> <dependencies>
> <!-- javaee per ejb -->
> <dependency>
> <groupId>javaee</groupId>
> <artifactId>javaee-api</artifactId>
> <version>5</version>
> <scope>provided</scope>
> </dependency>
> <dependency>
> <groupId>org.jboss.resteasy</groupId>
> <artifactId>resteasy-jaxrs</artifactId>
> <version>2.0.1.GA</version>
> <exclusions>
> <exclusion>
> <artifactId>slf4j-simple</artifactId>
> <groupId>org.slf4j</groupId>
> </exclusion>
> <exclusion>
> <artifactId>slf4j-api</artifactId>
> <groupId>org.slf4j</groupId>
> </exclusion>
> <exclusion>
> <artifactId>javassist</artifactId>
> <groupId>javassist</groupId>
> </exclusion>
> </exclusions>
> </dependency>
> * <dependency>
> <groupId>tpi.gimovit</groupId>
> <artifactId>gimovit-ejb</artifactId>
> <version>1.0</version>
> <scope>provided</scope>
> </dependency>*
> <!-- GWT dependencies (from central repo) -->
> <dependency>
> <groupId>com.google.gwt</groupId>
> <artifactId>gwt-servlet</artifactId>
> <version>${gwt.version}</version>
> <scope>runtime</scope>
> </dependency>
> <dependency>
> <groupId>com.google.gwt</groupId>
> <artifactId>gwt-user</artifactId>
> <version>${gwt.version}</version>
> <scope>provided</scope>
> </dependency>
> <!-- SmartGWT -->
> <dependency>
> <groupId>com.smartgwt</groupId>
> <artifactId>smartgwt</artifactId>
> <version>2.2</version>
> </dependency>
> <dependency>
> <groupId>com.smartgwt</groupId>
> <artifactId>smartgwt-skins</artifactId>
> <version>2.2</version>
> </dependency>
> <!-- test -->
> <dependency>
> <groupId>junit</groupId>
> <artifactId>junit</artifactId>
> <version>4.7</version>
> <scope>test</scope>
> </dependency>
> </dependencies>
Now the ejb isn't included in the war and I can compile, package and start the application but when in the application calls the ejb I recieve this error:
> 10:01:24,604 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/gimovit-gwt]] Exception while dispatching incoming RPC call: com.google.gwt.user.server.rpc.UnexpectedException: Service method 'public abstract java.lang.String tpi.gimovit.gwt.client.GreetingService.checkLogin(java.lang.String,java.lang.String)' threw an unexpected exception: javax.ejb.EJBException: java.lang.NullPointerException
> at com.google.gwt.user.server.rpc.RPC.encodeResponseForFailure(RPC.java:360) [:]
> at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:546) [:]
> at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:166) [:]
> at com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost(RemoteServiceServlet.java:86) [:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:754) [:1.0.0.Beta2]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [:1.0.0.Beta2]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:324) [:6.0.0.20100911-M5]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [:6.0.0.20100911-M5]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [:6.0.0.20100911-M5]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) [:6.0.0.20100911-M5]
> at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:181) [:6.0.0.20100911-M5]
> at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285) [:1.1.0.CR3]
> at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261) [:1.1.0.CR3]
> at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:88) [:6.0.0.20100911-M5]
> at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:100) [:6.0.0.20100911-M5]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) [:6.0.0.20100911-M5]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [:6.0.0.20100911-M5]
> at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) [:6.0.0.20100911-M5]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [:6.0.0.20100911-M5]
> at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53) [:6.0.0.20100911-M5]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [:6.0.0.20100911-M5]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [:6.0.0.20100911-M5]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [:6.0.0.20100911-M5]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [:6.0.0.20100911-M5]
> at java.lang.Thread.run(Thread.java:662) [:1.6.0_22]
> Caused by: javax.ejb.EJBException: java.lang.NullPointerException
> at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:183) [:0.0.1]
> at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:251) [:0.0.1]
> at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.required(CMTTxInterceptor.java:349) [:0.0.1]
> at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:209) [:0.0.1]
> at org.jboss.ejb3.tx2.aop.CMTTxInterceptorWrapper.invoke(CMTTxInterceptorWrapper.java:52) [:0.0.1]
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
> at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76) [:1.0.0.GA]
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
> at org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42) [:1.0.3]
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
> at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:182) [:1.5.1]
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
> at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41) [:1.5.1]
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
> at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67) [:1.5.1]
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
> at org.jboss.ejb3.core.context.CurrentInvocationContextInterceptor.invoke(CurrentInvocationContextInterceptor.java:47) [:1.5.1]
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
> at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67) [:1.0.1]
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
> at org.jboss.ejb3.interceptor.EJB3TCCLInterceptor.invoke(EJB3TCCLInterceptor.java:86) [:1.5.1]
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
> at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:369) [:1.5.1]
> at org.jboss.ejb3.remoting.IsLocalInterceptor.invokeLocal(IsLocalInterceptor.java:88) [:1.5.1]
> at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:75) [:1.5.1]
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
> at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62) [:1.0.1.GA]
> at $Proxy553.invoke(Unknown Source) at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:185) [:1.0.11-alpha-2]
> at $Proxy552.getSession(Unknown Source) at tpi.gimovit.gwt.server.GreetingServiceImpl.checkLogin(GreetingServiceImpl.java:65) [:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_22]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_22]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_22]
> at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_22]
> at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:527) [:]
> ... 23 more
> Caused by: java.lang.NullPointerException
> at tpi.gimovit.ejb.GimovitCoreBean.getSession(GimovitCoreBean.java:50) [:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_22]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_22]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_22]
> at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_22]
> at org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122) [jboss-aop.jar:2.2.1.Alpha3]
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111) [jboss-aop.jar:2.2.1.Alpha3]
> at org.jboss.ejb3.interceptors.container.ContainerMethodInvocationWrapper.invokeNext(ContainerMethodInvocationWrapper.java:72) [:1.0.7]
> at org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:76) [:1.0.7]
> at org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:62) [:1.0.7]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_22]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_22]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_22]
> at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_22]
> at org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174) [jboss-aop.jar:2.2.1.Alpha3]
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
> at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72) [:1.0.7]
> at org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_23069842.invoke(InvocationContextInterceptor_z_fillMethod_23069842.java)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
> at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88) [:1.0.7]
> at org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_23069842.invoke(InvocationContextInterceptor_z_setup_23069842.java)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
> at org.jboss.ejb3.async.impl.interceptor.FutureSerializingInterceptor.invoke(FutureSerializingInterceptor.java:88) [:1.0.0-alpha-5]
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
> at org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62) [:1.5.1]
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
> at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56) [:1.5.1]
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
> at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47) [:1.5.1]
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
> at org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42) [:1.0.3]
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
> at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:68) [:1.5.1]
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
> at org.jboss.ejb3.core.context.SessionInvocationContextAdapter.proceed(SessionInvocationContextAdapter.java:90) [:1.5.1]
> at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:247) [:0.0.1]
> ... 57 more
>
In the ejb GimovitCoreBean at line 50, I call an Entity Bean but I've recieved no errors with the persistence unit.
I don't understand if there is something wrong in my configuration, can you suggest me where I have to make changes?
Thank you for the help.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/570221#570221]
Start a new discussion in EJB3 at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 5 months
[Datasource Configuration] - When does JBoss reopen a dead connection?
by Glauber Ribeiro
Glauber Ribeiro [http://community.jboss.org/people/theglauber] created the discussion
"When does JBoss reopen a dead connection?"
To view the discussion, visit: http://community.jboss.org/message/569897#569897
--------------------------------------------------------------
I'm using JBoss 4.3. I have a data source defined like this:
<min-pool-size>5</min-pool-size>
<max-pool-size>25</max-pool-size>
<validate-on-match>false</validate-on-match>
<background-validation>true</background-validation>
<idle-timeout-minutes>5</idle-timeout-minutes>
<background-validation-minutes>1</background-validation-minutes>
<prefill>true</prefill>
<min-pool-size>5</min-pool-size>
<max-pool-size>25</max-pool-size>
<validate-on-match>false</validate-on-match>
<background-validation>true</background-validation>
<idle-timeout-minutes>10</idle-timeout-minutes>
<background-validation-minutes>15</background-validation-minutes>
<prefill>true</prefill>
And i have the validation SQLs defined:
<new-connection-sql>select 1</new-connection-sql>
<check-valid-connection-sql>select 1</check-valid-connection-sql>
Here's my problem: when there is a database failure (say, just for the sake of argument, i reboot the database server, to cause a failure) under load (that is, i'm constantly feeding transactions to my application, so it is trying to use the database all the time), JBoss continues to feed dead database connections to the application, until the background validation fires, at which point the connections are re-opened. So i see a bunch of errors in my application log that say things like "SQLException: invalid operation on closed connection", until the background validation fires and those connections are re-opened.
I'm surprised this is happening. I thought a SQLException on a connection would cause JBoss to drop that connection from the pool, but instead, JBoss seems to be blissfully unaware that there is anything wrong with the connections, and keeps passing them back to the application. Why doesn't it? Is JBoss relying on the application re-throwing the SQLExceptions? :-/
Thanks for any help, pointers, etc.
glauber
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/569897#569897]
Start a new discussion in Datasource Configuration at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 5 months