[Persistence, JBoss/CMP, Hibernate, Database] - Container Managed EntityManager returns no helpful stacktrac
by alexandre.pretyman
Hi,
I am using a Container managed EntityManager on a Stateful session bean, and after a random time
it has been processing, it throws me a JDBCException regarding a deadlock, however it gives me
no information on my code of what could have caused it....
I am new to JBoss + EJB development and frankly, don't know how to proceed debugging this.
Anyone has any clues?
Thank you
The stack trace is below. I am using JBoss 4.2.2.
| 09:52:02,431 WARN [JDBCExceptionReporter] SQL Error: 0, SQLState: null
| 09:52:02,431 ERROR [JDBCExceptionReporter] Batch entry 10 update MovingObject set lastTlmtr=<stream of 10145 bytes>, beforeLastTlmtr=<stream of 10145 bytes>, tlmtrLst=<stream of 90505 bytes>, lastPnt=SRID=4326;POINT(-43.31917190551758 -23.012861251831055), badMetricCounter=0 where movingObjectId=112 was aborted. Call getNextException to see the cause.
| 09:52:02,431 WARN [JDBCExceptionReporter] SQL Error: 0, SQLState: 40P01
| 09:52:02,431 ERROR [JDBCExceptionReporter] ERROR: deadlock detected
| Detail: Process 5360 waits for ShareLock on transaction 15510843; blocked by process 5381.
| Process 5381 waits for ShareLock on transaction 15510842; blocked by process 5360.
| 09:52:02,432 ERROR [AbstractFlushingEventListener] Could not synchronize database state with session
| org.hibernate.exception.GenericJDBCException: could not update: [frota.entities.MovingObject#101]
| at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103)
| at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
| at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
| at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2425)
| at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2307)
| at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2607)
| at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:92)
| at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:250)
| at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:234)
| at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:142)
| at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
| at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
| at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
| at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
| at org.hibernate.ejb.AbstractEntityManagerImpl$1.beforeCompletion(AbstractEntityManagerImpl.java:515)
| at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:114)
| at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:247)
| at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:86)
| at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177)
| at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1389)
| at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:135)
| at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:87)
| at org.jboss.resource.adapter.jms.inflow.JmsServerSession$XATransactionDemarcationStrategy.end(JmsServerSession.java:494)
| at org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:248)
| at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:204)
| at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:275)
| at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:761)
| at java.lang.Thread.run(Thread.java:595)
| Caused by: java.sql.BatchUpdateException: Batch entry 10 update MovingObject set lastTlmtr=<stream of 10145 bytes>, beforeLastTlmtr=<stream of 10145 bytes>, tlmtrLst=<stream of 90505 bytes>, lastPnt=SRID=4326;POINT(-43.31917190551758 -23.012861251831055), badMetricCounter=0 where movingObjectId=112 was aborted. Call getNextException to see the cause.
| at org.postgresql.jdbc2.AbstractJdbc2Statement$BatchResultHandler.handleError(AbstractJdbc2Statement.java:2537)
| at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1328)
| at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:351)
| at org.postgresql.jdbc2.AbstractJdbc2Statement.executeBatch(AbstractJdbc2Statement.java:2674)
| at org.jboss.resource.adapter.jdbc.WrappedStatement.executeBatch(WrappedStatement.java:519)
| at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:48)
| at org.hibernate.jdbc.BatchingBatcher.addToBatch(BatchingBatcher.java:34)
| at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2403)
| ... 24 more
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173074#4173074
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173074
17 years, 7 months
[JBoss Messaging] - Re: BisocketClientInvoker deadlock
by siimk123
Hi
I have stumbled onto problem as described in http://www.jboss.com/index.html?module=bb&op=viewtopic&t=135432 ( BisocketClientInvoker deadlock )
I was stress testing JBoss messaging and under heavy load it occasionally happened that server did not give out connections anymore.
Left it running overnight, but the situation did not improve. It hangs in createSocket infinitely.
Setup:
JBoss 4.2.2GA
JBoss Remoting 2.2.2.SP4-brew
JBoss Messaging 1.4.0 SP3
Then after reading instructions in https://jira.jboss.org/jira/browse/JBMESSAGING-1268, I tried following setup:
JBoss 4.2.2GA
JBoss Remoting 2.2.2.SP7
JBoss Messaging 1.4.0 SP3_CP03 (from svn Branch_JBossMessaging_1_4_0_SP3_CP)
bisocket -> timeout=0
bisocket -> callbackTimeout=10000
>From what I gather here, is that proposed workaround is basically to set connection timeout and letting the blocking connection to time out. Thus freeing up resources that would otherwise block also other threads( solution for original deadlock problem ).
Problem is that when subscriber's connection gets lost then messages are also not delivered and they will be not delivered after connection is restored.
Here I must clarify that I use non durable subscribers, but publishers send persistent messages.
Looking at JBoss Messaging source I understood that you dont wait for client side acknowledge when sending to non durable subscription.
Could it be that this is the underlying reason why persistent messages to non durable subscription are left undelivered?
If this is the case, then I believe that there is a bug in JBoss Messaging, because by JMS 1.1 specification you should not give up so easily.
JMS 1.1 spec page 71 paragraph 4.7 Message Delivery Mode states:
A JMS provider must deliver a PERSISTENT message once-and-only-once. This
means a JMS provider failure must not cause it to be lost, and it must not
deliver it twice.
To summarize...
I have persistent messages for non durable subscription and they are not delivered, because of the connection problem.
I believe the correct behaviour should be that those messages will be delivered after reconnect.
Here are some code snippets from Branch_JBossMessaging_1_4_0_SP3_CP to illustrate above allegations.
ServerSessionEndpoint:1873
| if (jmsDestination.isTopic())
| {
| if (subscriptionName == null)
| {
| // non-durable subscription
| if (log.isTraceEnabled()) { log.trace(this + " creating new non-durable subscription on " + jmsDestination); }
|
| // Create the non durable sub
|
| queue = new MessagingQueue(nodeId, GUIDGenerator.generateGUID(),
| idm.getID(), ms, pm, false,
| mDest.getMaxSize(), selector,
| mDest.getFullSize(),
| mDest.getPageSize(),
| mDest.getDownCacheSize(),
| mDest.isClustered(),
| sp.getRecoverDeliveriesTimeout());
|
ServerConsumerEndpoint:173
| if (dest.isTopic() && !messageQueue.isRecoverable())
| {
| // This is a consumer of a non durable topic subscription. We don't need to store
| // deliveries since if the consumer is closed or dies the refs go too.
| this.retainDeliveries = false;
| }
|
ServerSessionEndpoint:1316
| if (consumer.isRetainDeliveries())
| {
| // Add a delivery
|
| rec = new DeliveryRecord(delivery, consumer, deliveryId);
|
| deliveries.put(new Long(deliveryId), rec);
|
| if (trace) { log.trace(this + " added delivery " + deliveryId + ": " + delivery); }
| }
| else
| {
| //Acknowledge it now
| try
| {
| //This basically just releases the memory reference
|
| if (trace) { log.trace("Acknowledging delivery now"); }
|
| delivery.acknowledge(null);
| }
| catch (Throwable t)
| {
| log.error("Failed to acknowledge delivery", t);
| }
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173063#4173063
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173063
17 years, 7 months
[JBoss jBPM] - Re: Are ProcessDefinitions singletons or prototypes?
by joe_jboss＠freemansoft.com
Yes, our research made us think that also. The current serialization serializes the process definition with the process instance so you end up with multiple copies when you deserialize it. We'd really like to change the serialization so that it writes out the process definition name and version when serializing and then restores the process definition by looking up the name and version using the ProcessState default subprocess resolver.
We had thought of subclassing process definition so that it would do this as part of a readReplace() method but the use of ProcessDefinition class is hard coded into the jpdl xml reader so there is no way to replace it with a different class. Process Definition should be an interface or the definition instantiation code should get the process definition class from a factory or from the configuration files.
Instead, when we write out process instances, we remove the process definitions from the process instances and put the name of the definitions on the transients map on the process instance. (Note that it's called transients but its still serialized) After we read the process instances back in, we walk the process instance tree attaching the process definitions based on the name previously in the transients map.
We probably serialize BPM instances 1.5 million times per day so the savings can add up.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173056#4173056
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173056
17 years, 7 months
[JBoss Portal] - Creating portal users programmatically
by psevestre
Hi,
I'd like to create a set of portal users based on information that I'll receive in a simple CSV-format file, containing some data.
I've read the docs and source-code and, in a first incarnation of this batch import, I'm using the IdentityUserManagementService (which in not documented, btw) together with User an Profile modules.
This will probably do for now but, from what I could see in code, by using the exposed APIs, the configured registration mode seems to be bypassed. In my case, this would mean that I'll have to mimic the registration process, ie, send an email and handling the validation url.
Is there a way to programmatically create users in a way that the configured registration mode is honored, whichever it is ? Also, I think that it would be nice if the API could expose this in a way that allows the programmer to bypass or not the default registration flow.
Regards,
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173042#4173042
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173042
17 years, 7 months