[JBoss Cache Users] - MVCCLockManager.lockAndRecord ignores the values of Invocati
by veklov
Hi
As you can see from the below log:
* actual lock acquisition timeout in lockAndRecord is 10 seconds which equals to timeout on the cache level. (time between MVCCLockManager.lockAndRecord and MVCCLockingInterceptor.doAfterCall).
* the value of InvocationContext.getLockAcquisitionTimeout is 0. (exception message "... Unable to acquire lock on Fqn [...] after [0] milliseconds ..." produced by MVCCNodeHelper.acquireLock)
04.09.09 12:56:16.539 MSD [17] FINEST org.jboss.cache.lock.MVCCLockManager.lockAndRecord - Attempting to lock /java.lang.Integer/k
04.09.09 12:56:26.539 MSD [17] FINEST org.jboss.cache.interceptors.MVCCLockingInterceptor.doAfterCall - Nothing to do since there are no modifications in scope.
04.09.09 12:56:26.539 MSD [17] FINEST org.jboss.cache.InvocationContext.throwIfNeeded - There was a problem handling this request, but failSilently was set, so suppressing exception - org.jboss.cache.lock.TimeoutException: Unable to acquire lock on Fqn [/java.lang.Integer/k] after [0] milliseconds for requestor [Thread[Thread-1,5,main]]! Lock held by [GlobalTransaction:<10.139.132.111:2698>:0]
at org.jboss.cache.mvcc.MVCCNodeHelper.acquireLock(MVCCNodeHelper.java:159)
at org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:236)
at org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:186)
In particular this affects behaviour of Cache.putFromExternalRead
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4253535#4253535
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4253535
16 years, 7 months
[JBoss Messaging Users] - Qeustion on transactions and restarting the Server
by mclu
Hi Howard!
I have problems to explain the following problem:
(JBM1.4 build 7798 with OderingGroup enabled via CF)
(But I think OG has nothing to do with it)
I have a consumer which get one message transacted like this
| ...
| @Resource(mappedName="java:/JmsXA")
| private ConnectionFactory cf;
| ...
| Connection connection = cf.createConnection();
| connection.start();
| ...
| Session session = connection.createSession(true, Session.SESSION_TRANSACTED);
| MessageConsumer consumer = session.createConsumer(m_queue);
| Message msg = consumer.receive(20000);
|
Now I do the following:
- Message is received
- While I handle the message (in the transaction) i kill the Server (real kill)
After I restart my server my consumer will NOT get the same message again. It gets the next one.
If I look into the jbm_msg_ref I see one message
with Transaction_ID 41157221480464402 and state "-" and one entry in the tx table.
As I can see this message stays there forever.
Whats the problem or the reason here?
In my case this message must be retried again until the maxdeliverycount is reached and then the next must be delivered.
So in my case this scrambles my order.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4253527#4253527
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4253527
16 years, 7 months
[Security] - JBossNegotiation NullPointerExcpetion on EJB Call after Cach
by j_ri
Hi,
this week I gave JBossNegotiation a try. I tried it with a webapplication which calls a stateless session ejb.
In the first step authentication works well, but after the SecurityManager Cache timed out, the next call from the webapp to the EJB fails with a NullPointerExcpetion:
09:55:06,299 WARN [FWAction] de.lbank.portal.PortalException: java.lang.NullPointerException
at org.jboss.security.negotiation.spnego.SPNEGOLoginModule.login(SPNEGOLoginModule.java:106)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:579)
at org.jboss.security.plugins.JaasSecurityManager.defaultLogin(JaasSecurityManager.java:603)
at org.jboss.security.plugins.JaasSecurityManager.authenticate(JaasSecurityManager.java:537)
at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:344)
at org.jboss.ejb.plugins.SecurityInterceptor.checkSecurityAssociation(SecurityInterceptor.java:211)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:158)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
at org.jboss.ejb.plugins.CleanShutdownInterceptor.invoke(CleanShutdownInterceptor.java:278)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:648)
at org.jboss.ejb.Container.invoke(Container.java:960)
at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:430)
at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
at $Proxy266.getAlleAnwendungen(Unknown Source)
at de.lbank.portal.ejb.PortalLocalEjbBusinessDelegate.getAlleAnwendungen(PortalLocalEjbBusinessDelegate.java:75)
at de.lbank.portal.web.action.PortalHomeAnzeigeAction.doExecute(PortalHomeAnzeigeAction.java:92)
at com.cc.framework.adapter.struts.ActionUtil.execute(Unknown Source)
at com.cc.framework.adapter.struts.FWAction.execute(Unknown Source)
at com.cc.framework.adapter.struts.FWAction.execute(Unknown Source)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:421)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:226)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:397)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
at de.lbank.framework.web.struts.LActionServlet.service(LActionServlet.java:53)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at org.jboss.web.tomcat.service.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:87)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.jboss.web.tomcat.service.sso.ClusteredSingleSignOn.invoke(ClusteredSingleSignOn.java:676)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
Is there a solution for this problem, if I don't want to change the "DefaultCacheTimeout" in the "org.jboss.security.plugins.JaasSecurityManagerService" MBean to a very long time?
How does this work with failover in the cluster?
Thanks,
Jochen
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4253516#4253516
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4253516
16 years, 7 months