[JBoss Messaging Development] - unique constraint
by tomeicher
Hello folks,
we've been using ESB 4.5 in production for a while, and now and then
(mostly when under heavy load) I find the following message with
a JBM stack trace in the
server.log:
2009-10-22 03:19:17,479 WARN [WorkerThread#0[172.17.129.178:34800]] : [] / [org.jboss.messaging.core.impl.JDBCSupport] SQLException caught, SQLState 23505 code:0- assuming deadlock detected, try:1
org.postgresql.util.PSQLException: ERROR: duplicate key value violates unique constraint "jbm_msg_ref_pkey"
Obviously, we're using Postgres persistence.
ESB 4.5 (and the new 4.6) comes with JBM 1.4.0sp3, but we've
had to patche ESB to use 1.4.4ga
(see: https://jira.jboss.org/jira/browse/JBESB-2902 )
This happens mostly daily, mostly with "try:1" and no followup errors,
but sometimes I also see a "try:2" and even less often bigger tries.
-> Do you think this is (could be) causing data loss ?
-> Does "try:1" with no followup errors mean that a retry worked ?
-> Any idea how to further debug or get logging for that issue ?
-> I do not see how I could be causing anything like this from our
code, so this is most probably a bug in the ESB ?
Should I file a bug ?
Thanks and Cheers,
Tom.
2009-10-21 18:25:09,152 WARN [WorkerThread#1[172.17.129.178:56983]] : [] / [org.jboss.messaging.core.impl.JDBCSupport] SQLException caught, SQLState 23505 code:0- assuming deadlock detected, try:1
org.postgresql.util.PSQLException: ERROR: duplicate key value violates unique constraint "jbm_msg_ref_pkey"
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1608)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1343)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:194)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:451)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:350)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:304)
at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:365)
at org.jboss.messaging.core.impl.JDBCPersistenceManager$1AddReferenceRunner.doTransaction(JDBCPersistenceManager.java:1304)
at org.jboss.messaging.core.impl.JDBCSupport$JDBCTxRunner2.execute(JDBCSupport.java:465)
at org.jboss.messaging.core.impl.JDBCSupport$JDBCTxRunner2.executeWithRetry(JDBCSupport.java:503)
at org.jboss.messaging.core.impl.JDBCPersistenceManager.addReference(JDBCPersistenceManager.java:1353)
at org.jboss.messaging.core.impl.ChannelSupport.handle(ChannelSupport.java:226)
at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.routeInternal(MessagingPostOffice.java:2203)
at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.route(MessagingPostOffice.java:489)
at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendMessage(ServerConnectionEndpoint.java:741)
at org.jboss.jms.server.endpoint.ServerSessionEndpoint.send(ServerSessionEndpoint.java:383)
at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$send$aop(SessionAdvised.java:87)
at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_7280680627620114891.invokeNext(SessionAdvised$send_7280680627620114891.java)
at org.jboss.jms.server.container.SecurityAspect.handleSend(SecurityAspect.java:157)
at sun.reflect.GeneratedMethodAccessor189.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:121)
at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_7280680627620114891.invokeNext(SessionAdvised$send_7280680627620114891.java)
at org.jboss.jms.server.endpoint.advised.SessionAdvised.send(SessionAdvised.java)
at org.jboss.jms.wireformat.SessionSendRequest.serverInvoke(SessionSendRequest.java:95)
at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:143)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:809)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:608)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:420)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:173)
2009-10-21 18:25:09,153 WARN [WorkerThread#1[172.17.129.178:56983]] : [] / [org.jboss.messaging.core.impl.JDBCSupport] Trying again after a pause
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261831#4261831
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261831
16 years, 5 months
[JBoss ESB Development] - Re: SAML Token Support
by beve
Hi Anil,
anonymous wrote : Currently the STS Action is creating a token (via the STS) but updates the current security context with the new SC. The SC that the action was invoked is lost. Kevin asserts and I agree that the new SAML token should just augment the security context that currently exists rather than switching. If you want to switch the SC, then that should be a configurable option.
Good point and actually this was configurable at one stage during development but this was a bad call on my part to remove it.
anonymous wrote : The STS action should be replaced by a pluggable SAMLTokenIssuingLoginModule such that you can just either push it in a new SecurityAction that does JAAS internally or you need to plugin the LM in the current JAAS framework wherever it is in the ESB infrastructure. Kevin mentioned that the JAAS layer already exists.
Sounds good. Can you point me to an example of using new SecurityAction as I'm not sure what you mean here.
anonymous wrote : So the STS action is not a replacement here.
Do you mean that we should remove the STS action or that it could still be there as an alternative option, but be updated to use the SAMLTokenIssuingLoginModule. I think you mean the later but I just want to make sure I understand:)
Kev, what is you view on this?
anonymous wrote : On the SAML token validation end, the current LM is fine.
The JBossSTSLoginModule that we have currently has some code specific to the ESB but this could be refactored out. Kev asked me if this could not be donated to the security project if you want it.
anonymous wrote :
| Now the SAMLTokenIssuingLM will contact the STS for a new token. Then update the JAAS subject with this new token. You can choose either to make it a principal or a credential.
We currently have the token stored as a credential (SamlCredential). This was a principal to begin with but later changed as I though it would be more appropriate as a credential but I was not really 100% sure which it should really be. So I'm glad to hear either would be OK.
I appreciate the time you've both spent discussing this as I know you both are very busy at the moment.
Thanks,
/Daniel
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261814#4261814
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261814
16 years, 5 months