[JBoss JIRA] Created: (JBAS-9339) Provide jta-data-source if not specified
by Shelly McGowan (JIRA)
Provide jta-data-source if not specified
----------------------------------------
Key: JBAS-9339
URL: https://issues.jboss.org/browse/JBAS-9339
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JPA / Hibernate
Reporter: Shelly McGowan
Assignee: Scott Marlow
Fix For: 7.0.0.CR1
Persistence 2.0 Spec, Chapter 8.2.1.5
In Java EE environments, the jta-data-source and non-jta-data-source elements are used to specify the global JNDI name of the JTA and/or non-JTA data source to be used by the persistence provider.
and need to provide one if it is not specified:
If neither is specified, the deployer must specify a JTA data source at deployment or a JTA data source must be provided by the container, and a JTA EntityManagerFactory will be created to correspond to it.
Without the jta-data-source element in the persistence.xml, the deployment fails to start:
08:53:57,004 WARN [org.hibernate.connection.UserSuppliedConnectionProvider] (MSC service thread 1-6) No connection properties specified - the user must supply JDBC connections
08:53:57,011 INFO [org.hibernate.ejb.connection.InjectedDataSourceConnectionProvider] (MSC service thread 1-5) Using provided datasource
08:53:57,017 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC00001: Failed to start service jboss.persistenceunit."my_web.war#MY-EM": org.jboss.msc.service.StartException in service jboss.persistenceunit."my_web.war#MY-EM": Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1363)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_21]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_21]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]
Caused by: javax.persistence.PersistenceException: [PersistenceUnit: MY-EM] Unable to build EntityManagerFactory
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:911)
at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:74)
at org.jboss.as.jpa.service.PersistenceUnitService.createContainerEntityManagerFactory(PersistenceUnitService.java:169)
at org.jboss.as.jpa.service.PersistenceUnitService.start(PersistenceUnitService.java:78)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[JBoss JIRA] Created: (JBMESSAGING-1842) Live node dropping out of cluster can cause duplicate message delivery
by Justin Bertram (JIRA)
Live node dropping out of cluster can cause duplicate message delivery
----------------------------------------------------------------------
Key: JBMESSAGING-1842
URL: https://issues.jboss.org/browse/JBMESSAGING-1842
Project: JBoss Messaging
Issue Type: Bug
Components: JMS Clustering
Affects Versions: 1.4.0.SP3.CP10
Reporter: Justin Bertram
Assignee: Yong Hao Gao
When a live node is kicked out of the cluster (for whatever reason) its JBoss Messaging ServerPeer remains active which means the node is still available to receive messages and, if necessary, persist them to the database. However, the CHANNEL_ID values used for the persisted messages will be invalid since the fail-over procedure would have removed the "dead" node's channels from the JBM_POSTOFFICE and new CHANNEL_ID values will be used when the "dead" node is finally restarted. This essentially orphans any persistent messages sent to the "dead" node after it has been kicked out of the cluster. Recovering the orphaned messages would require manual intervention with the database, but even then it might not be possible to match the old CHANNEL_ID values with the new ones.
The simplest way to solve this problem is to add a constraint to the database that forces the inserted message's CHANNEL_ID to correspond to a CHANNEL_ID from JBM_POSTOFFICE. Of course, such a constraint will hurt performance a bit, but it could be optional - customers could trade robustness for speed.
The node would still need to be restarted in order to rejoin the cluster appropriately, but the constraint would avoid orphaned messages.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[JBoss JIRA] Created: (AS7-675) /server-group=<group>/jvm=<jvm>:add() ignores properties
by Heiko Braun (JIRA)
/server-group=<group>/jvm=<jvm>:add() ignores properties
--------------------------------------------------------
Key: AS7-675
URL: https://issues.jboss.org/browse/AS7-675
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Reporter: Heiko Braun
Assignee: Jason Greene
Fix For: 7.0.0.Beta4
[INFO] {
[INFO] "operation" => "add",
[INFO] "address" => [
[INFO] ("server-group" => "my-group"),
[INFO] ("jvm" => "default")
[INFO] ],
[INFO] "jvm" => ("default" => {
[INFO] "heap-size" => "64m",
[INFO] "max-heap-size" => "128m"
[INFO] })
[INFO] }
leads to
[localhost:9999 /] /server-group=my-group:read-resource(recursive=true)
{
"outcome" => "success",
"result" => {
"profile" => "default",
"jvm" => {"default" => {
"type" => undefined,
"agent-lib" => undefined,
"agent-path" => undefined,
"debug-enabled" => undefined,
"debug-options" => undefined,
"env-classpath-ignored" => undefined,
"environment-variables" => undefined,
"heap-size" => undefined,
"max-heap-size" => undefined,
"java-agent" => undefined,
"java-home" => undefined,
"jvm-options" => undefined,
"permgen-size" => undefined,
"max-permgen-size" => undefined,
"stack-size" => undefined
}},
"deployment" => undefined,
"socket-binding-group" => "standard-sockets"
},
"compensating-operation" => undefined
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months