[JBoss Seam] - Seam complained
by tonylmai
Hello,
I have a very simple login page that uses Seam's Identity. The first time I invoke this page, I saw the following log entry:
anonymous wrote : 18:51:44,000 INFO [ServletCacheAdministrator] Created new instance of ServletCacheAdministrator
| 18:51:44,000 INFO [ServletCacheAdministrator] Created new application-scoped cache at key: __oscache_cache
| 18:51:44,078 ERROR [STDERR] May 2, 2007 6:51:44 PM com.sun.faces.lifecycle.ELResolverInitPhaseListener populateFacesELResolverForJsp
| INFO: JSF1027: [null] The ELResolvers for JSF were not registered with the JSP container.
| 18:51:44,093 INFO [Lifecycle] starting up: org.jboss.seam.security.identity
| 18:51:44,578 ERROR [SeamPhaseListener] uncaught exception
| java.lang.IllegalStateException: No active conversation context
| at org.jboss.seam.core.FacesMessages.instance(FacesMessages.java:417)
| at org.jboss.seam.jsf.AbstractSeamPhaseListener.beforeRender(AbstractSeamPhaseListener.java:226)
| at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:56)
| at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:215)
| at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:140)
| at javax.faces.webapp.FacesServlet.service(FacesServlet.java:245)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:63)
| at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:57)
| at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49)
| at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:60)
| at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49)
| at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
| at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49)
| at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:79)
| at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49)
| at org.jboss.seam.web.SeamFilter.doFilter(SeamFilter.java:84)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.ajax4jsf.framework.ajax.xmlfilter.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:96)
| at org.ajax4jsf.framework.ajax.xmlfilter.BaseFilter.doFilter(BaseFilter.java:220)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
| at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
| at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
| at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
| at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
| at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
| at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
| at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
| at java.lang.Thread.run(Unknown Source)
|
Does anyone have any idea about this error?
Thanks
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4042684#4042684
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4042684
18 years, 11 months
[JBossCache] - Re: Threading Bug in PojoCache?
by vincent.marquez
Hey Jason, thanks for taking time to respond to my earlier post. To answer your questions, I'm not using Optimistic Locking, nor transactions.
When I came back to investigating this bug, I wasn't able to replicate the exact exception, but there most definitely is a race condition and I have a test case to show it. I'm not sure why I can't get the exact same exception, but I have a feeling they are directly related. Do you have any ideas on why I'm getting in the original exception a "null pointer instance"?
To get the exception I can replicate with an easy test case, run the junit test after inserting a breakpoint in AdvisedPojoHandler at line 128.
the line should be
| util_.attachInterceptor(obj, advisor, interceptor, observer_);
|
Run the program, and at any time you wish to cause the exception, simply step over that line to the next one, and wait. This is to simulate one thread reading the data at the exact time another thread could be inserting a pojo into the cache. You shall see when the second thread attempts to access the pojo, an exception is thrown:
Exception in thread "READERTHREAD" org.jboss.cache.pojo.PojoCacheAlreadyDetachedException: pojo: class org.jboss.cache.pojo.test.Person has possibly been detached remotely. Internal id: /__JBossInternal__/personFqn/_ID_/a232u-oafb98-f18j8tg3-1-f18j8tgi-2
at org.jboss.cache.pojo.interceptors.dynamic.CacheFieldInterceptor.isPojoDetached(CacheFieldInterceptor.java:235)
at org.jboss.cache.pojo.interceptors.dynamic.CacheFieldInterceptor.invoke(CacheFieldInterceptor.java:179)
at org.jboss.cache.pojo.test.JoinPoint_r_age_7.invokeNext(JoinPoint_r_age_7.java)
at org.jboss.cache.pojo.test.JoinPoint_r_age_7.invokeJoinpoint(JoinPoint_r_age_7.java)
at org.jboss.cache.pojo.test.Person$PersonAdvisor.Person$PersonAdvisor$age_r_$aop(Person$PersonAdvisor.java)
at org.jboss.cache.pojo.test.Person$PersonInstanceAdvisor.Person$PersonAdvisor$age_r_$aop(Person$PersonInstanceAdvisor.java)
at org.jboss.cache.pojo.test.Person.age_r_$aop(Person.java)
at org.jboss.cache.pojo.test.Person.getAge(Person.java:76)
at com.deltel.cache.test.ThreadTest$Reader.run(ThreadTest.java:69)
at java.lang.Thread.run(Unknown Source)
My unit test I used to show the bug:
| package com.deltel.cache.test;
|
| import org.jboss.cache.config.Configuration;
| import org.jboss.cache.config.Configuration.CacheMode;
| import org.jboss.cache.pojo.test.Person;
| import org.jboss.cache.lock.IsolationLevel;
| import org.jboss.cache.pojo.PojoCache;
| import org.jboss.cache.pojo.PojoCacheFactory;
|
| import EDU.oswego.cs.dl.util.concurrent.Latch;
|
| import junit.framework.Test;
| import junit.framework.TestCase;
| import junit.framework.TestSuite;
|
| public class ThreadTest extends TestCase {
|
| protected PojoCache cache1;
|
| protected Person person = new Person();
|
| protected String personFqn = "personFqn";
|
| private Latch finishedRead = new Latch();
|
| private Latch finishedAdd = new Latch();
|
| public void setUp() throws Exception {
| cache1 = this.fetchCache();
| person.setAge(50);
| }
|
| public void testRun() throws Exception {
|
| Thread t1 = new Thread(new Adder());
| Thread t2 = new Thread(new Reader(),"READERTHREAD");
|
| t1.start();
| t2.start();
|
| this.finishedAdd.acquire();
| this.finishedRead.acquire();
|
| System.out.println("finished without an error");
| }
|
|
| public static Test suite() {
| return new TestSuite(ThreadTest.class);
| }
|
|
| private class Adder implements Runnable {
| public void run() {
| cache1.attach(personFqn, person);
| finishedAdd.release();
| }
| }
|
| private class Reader implements Runnable {
| public void run() {
| for ( int x=0;x<50; x++ ) {
| try {
| Thread.sleep(10000);
| } catch ( InterruptedException e ) {
|
| }
|
| System.out.println("reading the field " + person.getAge());
|
| }
| finishedRead.release();
| }
| }
|
| PojoCache fetchCache() throws Exception {
| PojoCache cache = null;
| Configuration config = new Configuration();
| config.setCacheMode(CacheMode.REPL_SYNC);
| config.setIsolationLevel(IsolationLevel.REPEATABLE_READ);
| config.setLockAcquisitionTimeout(100000);
| config.setFetchInMemoryState(true);
| config.setClusterName("test");
| cache = PojoCacheFactory.createCache(config, false);
| cache.start();
| return cache;
| }
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4042682#4042682
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4042682
18 years, 11 months
[Performance Tuning] - Re: poor use of Memory
by PeterJ
A Java application will take only as much memory as it needs for the objects it has created. Given your heap settings, the JVM will initially reserve 1024MB of memory (in Windows it shows up as "committed" memory) thought the OS is typically a little smarter and only allocates the actual amount of physical memory required by the allocated objects. For example, the app might need only 200MB, in which case that amount of physical memory is allocated while the other 824MB stays in reserve and is physically allocated only when required.
If you put a pause at the start if your memory-eating app, you will notice that it also initially only uses a very small amount of memory. If you put a pause between iterations of your loop you will see them emory gradually increase.
The app server does lazy-loading for deployed applications and services. As the app server runs and handles requests, you will see the memory usage increase. If you want to pre-allocate that memory, you could create a service that initializes various apps by doing things such as establishing database connections, allocating EJBs, etc.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4042681#4042681
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4042681
18 years, 11 months