[JBossCache] - Performing cache operations while in a catch() section
by dfraser
Hi all,
the application I have written, when handling exceptions in one part, performs a cache operation (setting a node's value) to inform the other members of the cluster as to what is happening with a resource shared amongst the cluster.
everything looks and acts fine, then a minute or two later after the dust has settled, a warning pops up in server.log
17:56:19,454 WARN [TreeCache] status is 1 (not ACTIVE or PREPARING); returning null)
java.lang.Throwable
at org.jboss.cache.TreeCache.getCurrentTransaction(TreeCache.java:5805)
at org.jboss.cache.TreeCache.getCurrentTransaction(TreeCache.java:5775)
at org.jboss.cache.TreeCache.put(TreeCache.java:3831)
at sun.reflect.GeneratedMethodAccessor116.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy56.put(Unknown Source)
at com.mec.management.mbeans.TreeCacheFacade.setValue(TreeCacheFacade.java:296)
[and so on]
there are a few of these - it seems every cache related operation done while handling an exception has problems. there is a transaction timeout message before all this
17:55:17,034 WARN [TransactionImpl] Transaction TransactionImpl:XidImpl[FormatId=257, GlobalId=xbod-app01.xb-online.com/37, BranchQual=, localId=37] timed out. status=STATUS_ACTIVE
the cache is in REPL_SYNC mode, but I don't know what else to say as I'm not sure what else is important
I am sensing that this general idea of using the cache to update information within catch() blocks is not a good idea. I am lost as how to deal with this - is there some general principles I should follow or should I move the cache operation out of the exception handling all together (and how to?)?
yeah, they're only warnings but they look important. If someone could possibly explain what is going on, I would greatly appreciate it
doug
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069830#4069830
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4069830
18Â years, 8Â months
[JBoss Seam] - Re: Seam 1.2.1, AS 4.2.1, @Restricted method gives NoClassDe
by tynor
I dont know how i missed this the first time, but in fact, there was also a Facelets exception complaining about class loading.
2007-08-01 17:24:11,602 ERROR [STDERR] java.lang.ClassNotFoundException: No ClassLoaders found for: org.jboss.seam.security.SecurityFunctions
| 2007-08-01 17:24:11,602 ERROR [STDERR] at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:212)
| 2007-08-01 17:24:11,602 ERROR [STDERR] at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:514)
| 2007-08-01 17:24:11,602 ERROR [STDERR] at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:408)
| 2007-08-01 17:24:11,602 ERROR [STDERR] at
| ...
This is in fact almost identical symptoms to those described (and as far as I can tell never solved) at: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4056730 (i.e., the security functions work some times, and fail after a submit - in my case, continue to work after some submits, but seem to fail when a Validator fails)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069823#4069823
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4069823
18Â years, 8Â months
[JBoss Portal] - Re: Calling JAAS
by gersonjohan
I treated to login using a LoginContext as the following:
|
| String username = request.getParameter("username");
| String password = request.getParameter("password");
|
| boolean loginOk = false;
|
| if (username != null && password != null){
|
| LoginContext lc = null;
|
| try {
| ClienteCallbackHandler handler = new ClienteCallbackHandler(username, password.toCharArray());
| lc = new LoginContext("portal", handler);
| lc.login();
| loginOk = true;
| } catch (LoginException e) {
| logger.error("Login incorrecto.", e);
| }
| }
|
I create my callback and everything works without errors, but the portal continues sending to the login page when it is tried to accede to a safe context.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069821#4069821
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4069821
18Â years, 8Â months
[JBoss Tools (users)] - Disable the internal browser in the nightly tools?
by andrew.rw.robinson
I keep having Eclipse continuously crash on me. There seems to be some kind of conflict between the code completion using the browser and the jboss tools using the browser.
If I open an XHTML file, I can no longer use the code completion (crashes eclipse in the XUL shared library).
If I open a Java file and use the code completion, trying to open an XHTML file causes eclipse to crash.
Trying to open the code completion inside of an XHTML file seems to crash eclipse when it closes.
All these problems seem to stem from the visual and preview support from the red hat web page editor from the jboss tools. I only edit these files in source mode, so I wouldn't mind permanently disabling these features if it stops eclipse from crashing.
Any ideas?
Environment:
eclipse 3.3 using GTK version on linux
JBossTools-200707210217-nightly-ALL-linux-gtk.zip
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069819#4069819
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4069819
18Â years, 8Â months
[Security & JAAS/JBoss] - strange behavior in getting caller principal in ejb
by jainsau
Sorry for the long post, but I have tried to explain the problem in detail.
We are facing strange issues in getting the caller principal in our EJBs. Here is the envt we have:
We are using JBoss 4.2.0 GA. We are not using JAAS for authentication. A custom service is validating the credentials and returns a custom principal. The custom principal and password are set on the initial context:
credentials.put(Context.SECURITY_PRINCIPAL, customPrincipalInstance);
credentials.put(Context.SECURITY_CREDENTIALS, "dummy");
context = new InitialContext(credentials);
along with other usual details.
This context is used to lookup the remote proxy in the client. So the invoked bean should now have the sessionContext populated with the customPrincipalInstance.
We also have an EJB interceptor that intercepts any ejb method invocation. If the principal available in the interceptor is not an instance of our CustomPrincipal it throws an exception.
We have the following invocation steps (along with interceptors) which we are testing:
client->interceptor->EJB1->interceptor->EJB2.
Now when I start JBoss app server and access the client, the above steps should be undertaken. I am able to get the correct caller principal in EJB2 (EJB2 is injected into EJB1 using @EJB annotation) only at the third attempt. Here's what happens in each attempt:
First Attempt: Client passes customPrincipalInstance. In interceptor, the callerPrincipal returned by sessionConext is customPrincipalInstance. But, in EJB1, the callerPrincipal returned by sessionContext is SimplePrincipal (unauthenticated). So, when EJB1 invokes EJB2, the second interceptor fails, as the principal now in the context is SimplePrincipal.
Second Attempt: Client passes customPrincipalInstance. In interceptor, the callerPrincipal is customPrincipalInstance. This time in EJB1 also, the callerPrincipal is customPrincipalInstance. When EJB1 invokes EJB2, the second interceptor gets customPrincipalInstance. So EJB 2 gets invoked, but when I print the caller principal here, the value is SimplePrincipal (unauthenticated).
Third Attempt: Now everything works fine. Both the EJBs and the interceptors get customPrincipalInstance. No errors anywhere.
All further attempts also work fine.
I dont know why the first two invocations give error. I certainly cannot tell the client to login 3 times to get the app to work :). What could be the issue?
I checked the JBoss code, and found that threadPrincipal.get() in SecurityAssociation.getCallerPrincipal() returns the principal. But cannot understand why it doesnt work in first two attempts but works later.
Any help/input is appreciated.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069816#4069816
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4069816
18Â years, 8Â months