[JBoss JIRA] (AS7-6184) ConcurrentModificationException in org.jboss.as.cmp.TransactionEntityMap$GlobalTxSynchronization instances
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/AS7-6184?page=com.atlassian.jira.plugin.s... ]
Brad Maxwell updated AS7-6184:
------------------------------
Affects: Release Notes
> ConcurrentModificationException in org.jboss.as.cmp.TransactionEntityMap$GlobalTxSynchronization instances
> ----------------------------------------------------------------------------------------------------------
>
> Key: AS7-6184
> URL: https://issues.jboss.org/browse/AS7-6184
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
> Fix For: 7.1.4.Final (EAP)
>
>
> ConcurrentModificationException
> Caused by: javax.ejb.EJBException: JBAS018688: Exception in store of entity: 710304
> at org.jboss.as.cmp.TransactionEntityMap$GlobalTxSynchronization.synchronize(TransactionEntityMap.java:317) [jboss-as-cmp-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.cmp.TransactionEntityMap.synchronizeEntities(TransactionEntityMap.java:214) [jboss-as-cmp-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.cmp.component.CmpEntityBeanComponent.synchronizeEntitiesWithinTransaction(CmpEntityBeanComponent.java:104) [jboss-as-cmp-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.cmp.component.interceptors.CmpEntityBeanHomeFinderInterceptorFactory.invokeFind(CmpEntityBeanHomeFinderInterceptorFactory.java:69) [jboss-as-cmp-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanHomeFinderInterceptorFactory$1.processInvocation(EntityBeanHomeFinderInterceptorFactory.java:92) [jboss-as-ejb3-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:201) [jboss-as-ejb3-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> ... 90 more
> Caused by: java.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:819) [rt.jar:1.7.0_09]
> at java.util.ArrayList$Itr.next(ArrayList.java:791) [rt.jar:1.7.0_09]
> at org.jboss.as.cmp.TransactionEntityMap$GlobalTxSynchronization.synchronize(TransactionEntityMap.java:278) [jboss-as-cmp-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> ... 96 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6079) EJB 2.1 CMP configuration options missing (sync-on-commit-only, insert-after-ejb-post-create, call-ejb-store-on-clean)
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/AS7-6079?page=com.atlassian.jira.plugin.s... ]
Brad Maxwell updated AS7-6079:
------------------------------
Affects: Release Notes
> EJB 2.1 CMP configuration options missing (sync-on-commit-only, insert-after-ejb-post-create, call-ejb-store-on-clean)
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6079
> URL: https://issues.jboss.org/browse/AS7-6079
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.1.0.Alpha1, 7.1.3.Final (EAP)
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
> Fix For: 7.2.0.CR1, 7.1.4.Final (EAP)
>
>
> In JBoss AS 7, EJB 2.1 CMP beans cannot configure some options such as sync-on-commit-only and insert-after-ejb-post which were configurable in previous versions of JBoss.
> Should also confirm how to configure the rest of the options that were available previously.
> <container-configuration>
> <container-name>Clustered CMP 2.x EntityBean</container-name>
> <call-logging>false</call-logging>
> <invoker-proxy-binding-name>clustered-entity-rmi-invoker</invoker-proxy-binding-name>
> <sync-on-commit-only>false</sync-on-commit-only>
> <insert-after-ejb-post-create>false</insert-after-ejb-post-create>
> <container-interceptors>
> ...
> </container-interceptors>
> <instance-pool>org.jboss.ejb.plugins.EntityInstancePool</instance-pool>
> <instance-cache>org.jboss.ejb.plugins.EntityInstanceCache</instance-cache>
> <persistence-manager>org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager</persistence-manager>
> <locking-policy>org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock</locking-policy>
> <container-cache-conf>
> <cache-policy>org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy</cache-policy>
> <cache-policy-conf>
> <min-capacity>50</min-capacity>
> <max-capacity>1000000</max-capacity>
> <overager-period>300</overager-period>
> <max-bean-age>600</max-bean-age>
> <resizer-period>400</resizer-period>
> <max-cache-miss-period>60</max-cache-miss-period>
> <min-cache-miss-period>1</min-cache-miss-period>
> <cache-load-factor>0.75</cache-load-factor>
> </cache-policy-conf>
> </container-cache-conf>
> <container-pool-conf>
> <MaximumSize>100</MaximumSize>
> </container-pool-conf>
> <commit-option>B</commit-option>
> </container-configuration>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6079) EJB 2.1 CMP configuration options missing (sync-on-commit-only, insert-after-ejb-post-create, call-ejb-store-on-clean)
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/AS7-6079?page=com.atlassian.jira.plugin.s... ]
Brad Maxwell resolved AS7-6079.
-------------------------------
Fix Version/s: 7.2.0.CR1
7.1.4.Final (EAP)
(was: Open To Community)
Resolution: Done
> EJB 2.1 CMP configuration options missing (sync-on-commit-only, insert-after-ejb-post-create, call-ejb-store-on-clean)
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6079
> URL: https://issues.jboss.org/browse/AS7-6079
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.1.0.Alpha1, 7.1.3.Final (EAP)
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
> Fix For: 7.2.0.CR1, 7.1.4.Final (EAP)
>
>
> In JBoss AS 7, EJB 2.1 CMP beans cannot configure some options such as sync-on-commit-only and insert-after-ejb-post which were configurable in previous versions of JBoss.
> Should also confirm how to configure the rest of the options that were available previously.
> <container-configuration>
> <container-name>Clustered CMP 2.x EntityBean</container-name>
> <call-logging>false</call-logging>
> <invoker-proxy-binding-name>clustered-entity-rmi-invoker</invoker-proxy-binding-name>
> <sync-on-commit-only>false</sync-on-commit-only>
> <insert-after-ejb-post-create>false</insert-after-ejb-post-create>
> <container-interceptors>
> ...
> </container-interceptors>
> <instance-pool>org.jboss.ejb.plugins.EntityInstancePool</instance-pool>
> <instance-cache>org.jboss.ejb.plugins.EntityInstanceCache</instance-cache>
> <persistence-manager>org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager</persistence-manager>
> <locking-policy>org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock</locking-policy>
> <container-cache-conf>
> <cache-policy>org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy</cache-policy>
> <cache-policy-conf>
> <min-capacity>50</min-capacity>
> <max-capacity>1000000</max-capacity>
> <overager-period>300</overager-period>
> <max-bean-age>600</max-bean-age>
> <resizer-period>400</resizer-period>
> <max-cache-miss-period>60</max-cache-miss-period>
> <min-cache-miss-period>1</min-cache-miss-period>
> <cache-load-factor>0.75</cache-load-factor>
> </cache-policy-conf>
> </container-cache-conf>
> <container-pool-conf>
> <MaximumSize>100</MaximumSize>
> </container-pool-conf>
> <commit-option>B</commit-option>
> </container-configuration>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6327) Create JPA service callback for invoking database migration
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/AS7-6327?page=com.atlassian.jira.plugin.s... ]
jaikiran pai commented on AS7-6327:
-----------------------------------
I thought there was already a (Hibernate specific?) way of doing this. Some property which points to a "DDL file". It might have meant to create a DB schema, but perhaps you can just use it to do whatever migration activity that you are looking for?
> Create JPA service callback for invoking database migration
> -----------------------------------------------------------
>
> Key: AS7-6327
> URL: https://issues.jboss.org/browse/AS7-6327
> Project: Application Server 7
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Anil Arora
> Assignee: Scott Marlow
>
> Looking for a simple callback/listener mechanism so that we can invoke a database migration script before JPA persistent unit starts up and runs the Hibernate schema validation mechanism.
> Ideally, there would be a property within the persistence.xml that indicates which class to call. It would also pass in/inject the datasource that is being used for the persistence unit.
> Essentially, this would solve the lack of migration support in Hibernate itself.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6121) Naming subsystem <lookup> could use LinkRef/Reference
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/AS7-6121?page=com.atlassian.jira.plugin.s... ]
Eduardo Martins commented on AS7-6121:
--------------------------------------
This feature was designed to bind a msc service that provides "jndi lookup of X" as a managed value. When changed the managed value to a linkref, which is only dereferenced when doing a JNDI lookup, injection of the msc bind service, for instance as a dependency, injects the linkref itself, since it does not uses JNDI at all.
Now its a fact that the lookup subsystem op also creates a link, since it binds this "lookup of x" into JNDI, and this is possibly where we could do a change, by instead having a separated subsystem op (for instance "link") to bind link refs.
I need to look carefully to all the usages of the current feature before proposing anything at all.
> Naming subsystem <lookup> could use LinkRef/Reference
> -----------------------------------------------------
>
> Key: AS7-6121
> URL: https://issues.jboss.org/browse/AS7-6121
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Naming
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: James Livingston
> Assignee: Eduardo Martins
> Fix For: 7.2.0.Alpha1
>
>
> NameBindingAdd.installLookup() sets up the machinery so that when Context.lookup() is done it looks up the redirected name and returns it.
> It should be possible to do that by binding a LinkRef, Reference or similar object into JNDI instead.
> Where this could make a difference is when Context.lookupLink() is called instead.
> Currently if you have
> <simple name="java:/v" value="hello"/>
> <lookup name="java:/a" lookup="java:/b"/>
> lookupLink("java:/a") will return "hello" rather a LinkRef/Reference/whatever pointing to java:/b.
> We need to decide whether a <lookup> should be considered a "link" for the purposes of lookup() or not. If it should be considered one, then we should change NameBindingAdd.installLookup() to make lookupLink() return the other value.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6327) Create JPA service callback for invoking database migration
by Anil Arora (JIRA)
Anil Arora created AS7-6327:
-------------------------------
Summary: Create JPA service callback for invoking database migration
Key: AS7-6327
URL: https://issues.jboss.org/browse/AS7-6327
Project: Application Server 7
Issue Type: Feature Request
Components: JPA / Hibernate
Affects Versions: 7.1.3.Final (EAP)
Reporter: Anil Arora
Assignee: Scott Marlow
Looking for a simple callback/listener mechanism so that we can invoke a database migration script before JPA persistent unit starts up and runs the Hibernate schema validation mechanism.
Ideally, there would be a property within the persistence.xml that indicates which class to call. It would also pass in/inject the datasource that is being used for the persistence unit.
Essentially, this would solve the lack of migration support in Hibernate itself.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-4942) modcluster configuration does not respect SSL configuration
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/AS7-4942?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar resolved AS7-4942.
------------------------------
Fix Version/s: 7.2.0.Alpha1
(was: 7.2.0.CR1)
Resolution: Done
> modcluster configuration does not respect SSL configuration
> -----------------------------------------------------------
>
> Key: AS7-4942
> URL: https://issues.jboss.org/browse/AS7-4942
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering, Domain Management, Web
> Affects Versions: 7.1.1.Final
> Environment: jboss AS 7.1.1.Final. HA-Standalone configuration (clustered) with HTTPD modcluster advertise is on
> Reporter: yuval konrad
> Assignee: Tomaz Cerar
> Labels: mod_cluster
> Fix For: 7.2.0.Alpha1
>
>
> jboss AS 7.1.1.Final. HA-Standalone configuration (clustered) with HTTPD modcluster advertise is on; SSL configuration inside standalone xml are ignored (server is using default values).
> Setting the following inside httpd.conf file:
> <IfModule manager_module>
> Listen *:6666
> # ManagerBalancerName myCluster
> <VirtualHost *:6666>
> <Location />
> Order deny,allow
> Deny from all
> Allow from all
> </Location>
>
> SSLEngine ON
> SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
> SSLCertificateKeyFile conf/cert.key
> SSLCertificateFile conf/cert.cert
> SSLProtocol all -SSLv2
> ..
> Setting the following in jboss AS:
> <subsystem xmlns="urn:jboss:domain:modcluster:1.0">
> <mod-cluster-config balancer="pnw-cluster" advertise-socket="modcluster" advertise-security-key="blabla">
> <dynamic-load-provider history="10" decay="50">
> <load-metric type="cpu" weight="2" capacity="2"/>
> <load-metric type="sessions" weight="1" capacity="1000"/>
> <load-metric type="heap" weight="3" capacity="1"/>
> </dynamic-load-provider>
> <ssl password="17227491" certificate-key-file="configuration/.keystore" ca-certificate-file="configuration/.keystore"/>
> </mod-cluster-config>
> </subsystem>
> Keep getting the following ERRORS on jboss output:
> 17:51:44,291 ERROR [stderr] (pool-27-thread-1) at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.<init>(JSSESocketFactory.java:113)
> 17:51:44,291 ERROR [stderr] (pool-27-thread-1) at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.<init>(DefaultMCMPHandler.java:747)
> 17:51:44,292 ERROR [stderr] (pool-27-thread-1) at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.add(DefaultMCMPHandler.java:183)
> 17:51:44,293 ERROR [stderr] (pool-27-thread-1) at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.addProxy(DefaultMCMPHandler.java:179)
> 17:51:44,293 ERROR [stderr] (pool-27-thread-1) at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl$AdvertiseListenerWorker.run(AdvertiseListenerImpl.java:443)
> 17:51:44,294 ERROR [stderr] (pool-27-thread-1) at java.lang.Thread.run(Thread.java:662)
> 17:51:44,294 ERROR [stderr] (pool-27-thread-1) Caused by: java.io.FileNotFoundException: /export/home/ana50/.keystore (No such file or directory)
> 17:51:44,295 ERROR [stderr] (pool-27-thread-1) at java.io.FileInputStream.open(Native Method)
> 17:51:44,295 ERROR [stderr] (pool-27-thread-1) at java.io.FileInputStream.<init>(FileInputStream.java:120)
> 17:51:44,295 ERROR [stderr] (pool-27-thread-1) at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.getStore(JSSESocketFactory.java:253)
> 17:51:44,296 ERROR [stderr] (pool-27-thread-1) at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.getKeystore(JSSESocketFactory.java:208)
> 17:51:44,296 ERROR [stderr] (pool-27-thread-1) at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:280)
> 17:51:44,297 ERROR [stderr] (pool-27-thread-1) at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.<init>(JSSESocketFactory.java:98)
> 17:51:44,297 ERROR [stderr] (pool-27-thread-1) ... 5 more
> I went over all modcluster open and closed bugs without finding any relevant solution. I'm getting these error when using absolute paths as well.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6326) EJB2 CMP all entities are synchronized with the database if <EntityHome>.findByPrimaryKey(...) is called
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/AS7-6326?page=com.atlassian.jira.plugin.s... ]
Brad Maxwell updated AS7-6326:
------------------------------
Summary: EJB2 CMP all entities are synchronized with the database if <EntityHome>.findByPrimaryKey(...) is called (was: CLONE - EJB2 CMP all entities are synchronized with the database if <EntityHome>.findByPrimaryKey(...) is called)
> EJB2 CMP all entities are synchronized with the database if <EntityHome>.findByPrimaryKey(...) is called
> --------------------------------------------------------------------------------------------------------
>
> Key: AS7-6326
> URL: https://issues.jboss.org/browse/AS7-6326
> Project: Application Server 7
> Issue Type: Bug
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Wolf-Dieter Fink
> Assignee: Wolf-Dieter Fink
>
> This is a different behavior to former AS versions and a huge performance issue.
> From the EJB spec the entities must be flushed due to have the correct result of the invoked finder.
> ejbFindByPrimaryKey() is special as there is no need to flush other instances.
> It is ensured that the entity is found nevertheless whether it is changed or not as the 'cache' is evaluated first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months