[JBoss JIRA] Created: (JBAS-7582) Add dependecies on HttpRMIClassLoading
by Brian Stansberry (JIRA)
Add dependecies on HttpRMIClassLoading
--------------------------------------
Key: JBAS-7582
URL: https://jira.jboss.org/jira/browse/JBAS-7582
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: JBossAS-6.0.0.M2
The tests-jbossmessaging-cluster testsuite target doesn't stop one of the two AS instances it starts. One of the tests stops the server and the ant target assumes that will happen so it doesn't do it. This is fragile since problems with the test can prevent the server being stopped. That server remaining alive then screws up the rest of the testsuite run. This is a frequent cause of hudson testsuite failures.
Adding a call to the server:stop task doesn't seem to cause a problem even if the server isn't running, so I'm adding one.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months
[JBoss JIRA] Created: (JBAS-7811) Multithreaded access to remote JDBC datasource is broken
by Justin Bertram (JIRA)
Multithreaded access to remote JDBC datasource is broken
--------------------------------------------------------
Key: JBAS-7811
URL: https://jira.jboss.org/jira/browse/JBAS-7811
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JCA service
Affects Versions: JBossAS-6.0.0.M2
Reporter: Justin Bertram
Assignee: Justin Bertram
Fix For: JBossAS-6.0.0.M3
Heavy access to a remote JDBC datasource (i.e. one configured with <use-java-context>false</use-java-context>) with multiple threads sometimes results in errors.
The root of this problem is how the proxied datasource objects (e.g. ResultSet, Connection, Statement, etc.) are stored in the server-side HashMap for re-use by the remote client. These objects are, not surprisingly, keyed by their respective hash code (i.e. object.hashCode()). There are cases where different objects return the same hashCode which means a remote client can close someone else's ResultSets, etc. One can easily see this by turning on DEBUG logging and executing your test. For example:
DEBUG [org.jboss.resource.adapter.jdbc.remote.WrapperDataSourceService] Created ResultSet proxy for invoker=jboss:service=invoker,type=jrmp, targetName=jboss.jca:service=DataSourceBinding,name=PostgresDS, cacheID=12215563
DEBUG [org.jboss.resource.adapter.jdbc.remote.WrapperDataSourceService] Created ResultSet proxy for invoker=jboss:service=invoker,type=jrmp, targetName=jboss.jca:service=DataSourceBinding,name=PostgresDS, cacheID=12215563
...
DEBUG [org.jboss.resource.adapter.jdbc.remote.WrapperDataSourceService] Closed ResultSet=12215563
Of course, the *other* client using the ResultSet whose cacheID is "12215563" will break when it tries to access it later.
To solve this problem, something other than hashCode should be used to key the HashMap entries.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months