[JCA/JBoss] - inactive connections are not closed in oracle even i mentine
by ps.ganesh
I am using a pooled connection in my web application using jboss specific configuration file oracle-ds.xml the entries of the file is :
<local-tx-datasource>
<jndi-name>OracleDS-QA</jndi-name>
<connection-url>jdbc:oracle:thin:@opi049.nod.comp.com:1551:prodqa</connection-url>
<driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
<user-name>xxx</user-name>
123
<exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
<valid-connection-checker-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker</valid-connection-checker-class-name>
<new-connection-sql>select 1 from dual</new-connection-sql>
<check-valid-connection-sql>select 1 from dual</check-valid-connection-sql>
<min-pool-size>10</min-pool-size>
<max-pool-size>100</max-pool-size>
<idle-timeout-minutes>1</idle-timeout-minutes>
<type-mapping>Oracle8i</type-mapping>
</local-tx-datasource>
In my application I am getting the connection by datasource as :
Context ctx=new InitialContext();
ds = (DataSource) ctx.lookup(jndiName);
..
ds.getConnection();
When I complete load testing with 50 users I found 50 inactive connections at oracle side
[ SELECT COUNT(*) FROM v$session WHERE osuser='tsering' AND status='INACTIVE' ]
and when i complete single transation after that my inactive conn incremented by 1.
I am not aware why the inactive connections are there at oracle side. Is there any mechanism to remove these inactive connections from oracle side.
I know that when we call con.close() method in a pooled connection the connection is returned back to pool but I didn't know why it is not using the inactive connection for a new connection request it is creating a new one.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160724#4160724
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160724
17 years, 9 months
[JBoss Cache: Core Edition] - Passivation false problem
by rachna_agg
Hi,
We are using JBoss Cache in a stand alone web application with tomcat 5.5.23 as our Web Server. We are using JDBC Cache Loader and passivation is taken as false.
We are facing an issue that we are not able to find the Cache Interceptor "ActivationInterceptor" MBean as registered although we have called the setRegisterInterceptors() API in CacheJmxWrapperMBean as true. As a result, we are not able to see the attributes "Activations", "CacheLoaderLoads" and "CacheLoaderMisses".
Can anyone please let us know is this Activation Interceptor linked with passivation property being true? I think they should not be linked as nodes are activated from the database when they are not found in the memory so we should get the attributes for Cache Loader Loads/Misses.
Also, when passivation is false, the attribute "Hits" is always zero and never increases and "Misses" attribute always increases whenever we call a retrieve API.
Regards,
Rachna
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160723#4160723
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160723
17 years, 9 months
[JBoss AOP] - Re: Multiple ClassLoaders problem?
by fr0w
Ok, Flavia, I tried what you suggested and it seemed to work, but turns out that developing with eclipse (and using it's compiler) together with AopC isn't a good idea, because everytime I change a single char using eclipse it recompiles the class so it will loose all code that was once inserted by AopC. But that wasn't the only problem, I also had some other problems that I can't recall now. So I visited the official site and saw that there was an upgrade available (I was using CR8) so I grabbed it and replaced the JARs.
After upgrading I decided to give load-time weaving a second chance and it also worked! But in order to make it work I had to do some Thread.currentThread().setContextClassLoader() in some places... But that wasn't enough to make errors happen.
First of all, let me try to explain the "boot" procedure of a JPF application.
- The main class of the application is called org.java.plugin.boot.Boot
- This Boot class check the system properties looking for a property called 'org.java.plugin.boot.applicationPlugin'. This property has a classname which is later resolved to a Class and the have a method boot() called (so this boot() method works like our old main())
Introducing a Java Agent causes this process to get a little more complex.
- premain() -> Boot.main() -> MyClass.boot()
premain() and Boot.main() uses the default ClassLoader to load the necessary class in order to be able to call MyClass.boot() that includes JbossAOP libraries (since the AspectManager is loaded by in the premain() method).
After premain() and Boot.main(), JPF creates its own ClassLoading architecture based on some XML files and its configuration (plugin dependency, for example). A simple example of how the ClassLoading works in JPF can be the following:
- 'pluginB' depends on 'pluginA' so the ClassLoader used to load 'pluginB' classes' is also able to "see" 'pluginA' classes.
But now let's say I added a interceptor to a method in 'pluginB', but due to JPF way of handling things, the premain() / Boot.main() class loader is not able to "see" 'pluginB' classes', causing the exception bellow:
| Exception generating org.drftpd.vfs.JoinPoint_toString6853976482757027775_8: org.drftpd.vfs.index.lucene.SimpleInterceptor
| java.lang.ClassNotFoundException: org.drftpd.vfs.index.lucene.SimpleInterceptor
| at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
| at java.security.AccessController.doPrivileged(Native Method)
| at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
| at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
| at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
| at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
| at org.jboss.aop.instrument.JoinPointGenerator$AdviceSetup.<init>(JoinPointGenerator.java:1405)
| at org.jboss.aop.instrument.JoinPointGenerator.initialiseAdviceInfosAndAddFields(JoinPointGenerator.java:526)
| at org.jboss.aop.instrument.JoinPointGenerator.generateJoinpointClass(JoinPointGenerator.java:367)
| at org.jboss.aop.instrument.JoinPointGenerator.doGenerateJoinPointClass(JoinPointGenerator.java:285)
| at org.jboss.aop.instrument.JoinPointGenerator.access$300(JoinPointGenerator.java:77)
| at org.jboss.aop.instrument.JoinPointGenerator$GenerateJoinPointClassAction$2.generateJoinPointClass(JoinPointGenerator.java:1729)
| at org.jboss.aop.instrument.JoinPointGenerator.generateJoinPointClass(JoinPointGenerator.java:250)
| at org.jboss.aop.GeneratedClassAdvisor.generateJoinPointClass(GeneratedClassAdvisor.java:1042)
| at org.drftpd.vfs.InodeHandle$InodeHandleAdvisor.toString6853976482757027775(InodeHandle$InodeHandleAdvisor.java)
| at org.drftpd.vfs.InodeHandle.toString(InodeHandle.java)
| at java.lang.String.valueOf(String.java:2827)
| at java.lang.StringBuilder.append(StringBuilder.java:115)
| at org.drftpd.commands.list.LIST.list(LIST.java:364)
| at org.drftpd.commands.list.LIST.doLIST(LIST.java:406)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
|
| at java.lang.reflect.Method.invoke(Method.java:597)
| at org.drftpd.commandmanager.StandardCommandManager.execute(StandardCommandManager.java:238)
| at org.drftpd.master.BaseFtpConnection$CommandThread.run(BaseFtpConnection.java:634)
| at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
| at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
| at java.lang.Thread.run(Thread.java:619)
|
org.jboss.aop.GeneratedClassAdvisor.generateJoinPointClass(GeneratedClassAdvisor.java:1042)
generator.generateJoinPointClass(this.getClass().getClassLoader(), info);
The above piece of code is, at least for me, the cause of my problems. since the ClassLoader that loaded JointPointGenerator cannot "see" JPF's ClassLoader.
Dunno if that's a limitation or a not handled case or a bug.
Thanks in advance for you help.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160721#4160721
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160721
17 years, 9 months