[JBoss JIRA] Created: (JBAS-4218) Incorrect description in connector_1_0.dtd
by Jesper Pedersen (JIRA)
Incorrect description in connector_1_0.dtd
------------------------------------------
Key: JBAS-4218
URL: http://jira.jboss.com/jira/browse/JBAS-4218
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JCA service
Affects Versions: JBossAS-4.2.0.CR1
Environment: Branch_4_2
Reporter: Jesper Pedersen
Assigned To: Weston Price
Priority: Trivial
Attachments: connector_1_0.dtd.patch, ResourceAdapterObjectModelFactory.patch
The values specified for the 'transaction-support' are currently the ones from the pre JCA-1.0 final spec. Attached patch fixes it.
If you want to include support for the pre JCA-1.0 final spec values the ResourceAdapterObjectModelFactory.patch does that.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 3 months
[JBoss JIRA] Created: (EJBTHREE-937) Cannot have more than 64K instances of a clustered SFSB passivated
by Brian Stansberry (JIRA)
Cannot have more than 64K instances of a clustered SFSB passivated
------------------------------------------------------------------
Key: EJBTHREE-937
URL: http://jira.jboss.com/jira/browse/EJBTHREE-937
Project: EJB 3.0
Issue Type: Bug
Components: Clustering
Affects Versions: AS 4.2.0 CR1
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
The cache used for clustered SFSBs uses FileCacheLoader, which creates one directory per passivated bean instance. This means the max number of passivated beans is affected by the filesystem's max number of child directories. One of the causes of the issues reported in JBPAPP-90 is a load test is hitting a limit of ~ 64K nodes on a 64 bit ext3 filesystem. Some google hits related to this make me think in some cases the limit might be 32K.
The default removal timeout for ejb3 SFSBs is 0 (i.e. no removal), so hitting this limit is not far-fetched.
Some possible solutions:
1) Add another layer to the Fqn, hash the bean id, and spread the beans among buckets.
2) Use another CacheLoader.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 3 months
[JBoss JIRA] Created: (JBAS-4295) throw a 'no transaction' exception instead of NPE
by Alexey Loubyansky (JIRA)
throw a 'no transaction' exception instead of NPE
-------------------------------------------------
Key: JBAS-4295
URL: http://jira.jboss.com/jira/browse/JBAS-4295
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: CMP service
Affects Versions: JBossAS-4.2.0.CR1, JBossAS-5.0.0.Beta1, JBossAS-4.0.5.GA
Reporter: Alexey Loubyansky
Assigned To: Alexey Loubyansky
Fix For: JBossAS-5.0.0.Beta2, JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta3
java.lang.NullPointerException
at org.jboss.ejb.plugins.cmp.jdbc2.bridge.JDBCCMRFieldBridge2$CollectionValuedFieldState.loadOnlyFromCache(JDBCCMRFieldBridge2.java:1085)
was caused by calling size() on a CMR collection w/o a transaction. It would be better to throw an exception with a message explaining the problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 3 months