Page fragment cache with JBoss Treecache, ehcache and a FileSystemCache
by Sebastian Hennebrueder
Hello,
I was working on the http://jira.jboss.com/jira/browse/JBSEAM-1891
and created three caching alternatives which can now be plugged in.
As this is the first thing I write, I would appreciate a feedback, if
the provided solution is what Christian was actually looking for and if
I should continue this or made something completely useless.
I attached the files and testng tests. If this is considered useful, I
can provide a SVN patch as well. All files are new anyway.
Cache Provider:
JBoss TreeCache 1.4
API changes a lot from 1.4 to 2, so we must be careful once the
I did not use the PojoCache as we have only simple Strings and no
complex beans. In that case PojoCache provides only overhead. (info
taken from pojocache wiki).
Eh-Cache
I did not enforce any Transaction guaranties (like READ_COMMITED) as we
have in Hibernate for example.
FileSystemCache
Manually written, idea: a large site cannot be hold in a cache being
present in memory. This cache has a small in memory area holding very
frequent files (size can be configured) and fetches files from disk.
Though the operation system caches access to disk, this is still a lot
slower than memory access but probably faster than having complex
queries to the database (see Seam Wiki queries)
The Cache can already be used in a web application using a custom
renderer kit.
example for components.xml
<component class="org.jboss.seam.cache.PageFragmentCache">
<property name="provider">#{filecache}</property>
</component>
<component class="org.jboss.seam.cache.FileSystemCacheProvider"
name="filecache">
<property name="boostBufferSize">50</property>
<property name="enableStatistics">true</property>
</component>
<component class="org.jboss.seam.statistics.StatisticsManager" />
Another idea:
I introduces a StatisticsManger component which might be used by any
components providing statistic information. This would provide one place
to access statistics of the application or to print a report. If you
like the idea, I would add a MBean wrapping this StatisticsManager else
I'll just remove it from the cache providers.
Some questions:
I did not find a way to access the name of the application (web context)
to use it as prefix for the JBoss TreeCache in case we use multiple
applications on the same system.
Is there a common way to load resources like configuration files? I saw
different approaches in the core code.
Best Regards
Sebastian Hennebrueder
laliluna.de
12 years, 7 months
Seam Guice integration
by Dan Allen
Given that we have Spring integration in the IoC module, it makes
sense that we would have Guice in there as well. Paul, would you be
interested in seeing the Guice module become part of the Seam project?
Seam devs, would this be something we want to see in Seam? I think it
should.
Granted, I know that there is the whole Web Beans coming down the
pike, but given that this integration is already implemented, why not
make it available in Seam 2.1?
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://www.mojavelinux.com
http://manning.com/dallen
NOTE: While I make a strong effort to keep up with my email on a daily
basis, life and work come first and, at times, keep me away from my mail
for a while. If you contact me, then don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
12 years, 8 months
EAR with multiple WAR example
by Dan Allen
Guys,
I have seen several postings on the forums lately about problems with
setting up two Seam-enabled WARs in one EAR. It's clear that
developers lack guidance with this task and I think it would be worth
making this one of the examples (even if just to prove it can be done
and that we can validate it works with each release). Jay, guru of
interoperability, would you be able to make this work? I'm thinking we
just mash together two of the existing examples.
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, life and work come first and, at times, keep me away from my mail
for a while. If you contact me, then don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
12 years, 8 months
ManagedEntityIdentityInterceptor again: Apply per _request_?
by Stephen Friedrich
The performance of this interceptor makes using a seam managed persistence context almost impossible for
many applications (those that need to support more than very few concurrent users).
(In my application it adds overhead of about two seconds per request on some pages.)
I am probably being naive, and miss something of importance, but:
I wonder why it is necessary to apply the interceptor on each method call.
During rendering of my pages there are often a dozen or more calls to the same backing bean.
Surely passivation or replication won't happen in between, right?
So why can't the interceptor be applied (and "de-appplied") just once for every object that is used during the request?
Otherwise: Can't Seam intercept passivation and replication somehow and apply the service only on demand?
12 years, 8 months
What's the purpose of the method context?
by Norman Richards
I'm looking at a support issue, and I've found a problem with
MethodContextInterceptor. The interceptor puts the calling component,
by name, in the method context so that future calls to getInstance()
will find that version of the component. However, it sets the raw,
unproxied object so that calls to that object will not go through the
interceptor chain. (so, an annotation like @CreateProcess won't be
triggered). This seems wrong to me, but since I don't understand the
purpose of MethodContextInterceptor, I can't say for sure.
In case the description above isn't clear, consider a simple component
like this:
...
@Name("foo")
public class Foo {
@RaiseEvent("myEvent")
public void actionOne() { }
@CreateProcess(...)
@Observe("myEvent")
public void actionTwo() { }
}
When #{foo.one} is invoked, the unproxied Foo instance is put in the
method context under "foo". When the event is raised, Events tries to
lookup "foo" but instead of finding the correct instance in it's
normal context, it finds the raw instance in the method context.
actionTwo() is called, but there are no proxies involved and thus
@CreateProcess isn't triggered.
So, what in the world is the MethodContextInterceptor doing there?
Should it really be storing the unproxied instance there?
12 years, 8 months
Starting release of 2.0.3.CR1
by Jay Balunas
People,
All the issues scheduled for Seam 2.0.3.CR1 are now closed, so we shall
start the tagging, testing, and release process.
Please consider the *Seam_2_0* branch frozen until myself or the
development team announces that the release is complete. You need to
pre-clear any commits with me.
Thanks,
Jay
12 years, 9 months
deprecations on Identity
by Dan Allen
Is it really necessary to deprecate get/setUsername() and
get/setPassword() on Identity? I understand the benefits of having a
Credentials component to hold this information, and that it can be
swapped out, but I don't see why the pass through methods on Identity
cannot be treated as convenience methods. I feel like we are going to
cause a lot of people to go and change their applications for no
reason if they are fine with their current authentication setup.
Again, I am thrilled about the new security stuff. I'm just want to
make sure we don't step on the toes of current rollouts.
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, life and work come first and, at times, keep me away from my mail
for a while. If you contact me, then don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
12 years, 9 months
Blocked threads
by Christian Bauer
During load spikes in production I find plenty of BLOCKED threads with
this stack:
java.util.Hashtable.get(Hashtable.java:335)
org.jnp.server.NamingServer.getBinding(NamingServer.java:506)
org.jnp.server.NamingServer.getBinding(NamingServer.java:537)
org.jnp.server.NamingServer.getObject(NamingServer.java:543)
org.jnp.server.NamingServer.lookup(NamingServer.java:267)
org.jnp.interfaces.NamingContext.lookup(NamingContext.java:667)
org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
javax.naming.InitialContext.lookup(InitialContext.java:351)
org
.jboss
.seam.transaction.Transaction.getUserTransaction(Transaction.java:79)
org
.jboss
.seam.transaction.Transaction.createUTTransaction(Transaction.java:71)
org.jboss.seam.transaction.Transaction.getTransaction(Transaction.java:
44)
sun.reflect.GeneratedMethodAccessor5830.invoke(Unknown Source)
sun
.reflect
.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
java.lang.reflect.Method.invoke(Method.java:585)
org.jboss.seam.util.Reflections.invoke(Reflections.java:21)
org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:125)
org.jboss.seam.Component.callComponentMethod(Component.java:2195)
org.jboss.seam.Component.unwrap(Component.java:2221)
org.jboss.seam.Component.getInstance(Component.java:1988)
org.jboss.seam.Component.getInstance(Component.java:1951)
org.jboss.seam.Component.getInstance(Component.java:1928)
org.jboss.seam.Component.getInstance(Component.java:1923)
org.jboss.seam.transaction.Transaction.instance(Transaction.java:36)
org.jboss.seam.util.Work.workInTransaction(Work.java:28)
org
.jboss
.seam
.transaction
.TransactionInterceptor.aroundInvoke(TransactionInterceptor.java:32)
org
.jboss
.seam
.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
org
.jboss
.seam
.core
.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:42)
org
.jboss
.seam
.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
org
.jboss
.seam
.security.SecurityInterceptor.aroundInvoke(SecurityInterceptor.java:118)
org
.jboss
.seam
.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:
107)
org
.jboss
.seam
.intercept
.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
org
.jboss
.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
org.jboss.seam.wiki.core.action.DocumentHome_$
$_javassist_18.getInstance(DocumentHome_$$_javassist_18.java)
Also problematic seems to be the ManagedEntityIdentityInterceptor (I
think we really could use a "no JavaBean clustering" switch that
disables it - need some input from Gavin who initially wrote it if
that is feasible):
java.util.Hashtable.get(Hashtable.java:335)
org.jnp.server.NamingServer.getBinding(NamingServer.java:506)
org.jnp.server.NamingServer.getBinding(NamingServer.java:537)
org.jnp.server.NamingServer.getObject(NamingServer.java:543)
org.jnp.server.NamingServer.lookup(NamingServer.java:296)
org.jnp.interfaces.NamingContext.lookup(NamingContext.java:667)
org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
org
.jboss
.ejb3
.naming.SimpleMultiplexer.createMultiplexer(SimpleMultiplexer.java:53)
org
.jboss
.ejb3
.naming.SimpleMultiplexer.getObjectInstance(SimpleMultiplexer.java:88)
javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
javax.naming.spi.NamingManager.getContext(NamingManager.java:422)
javax
.naming
.spi.ContinuationContext.getTargetContext(ContinuationContext.java:38)
javax
.naming.spi.NamingManager.getContinuationContext(NamingManager.java:770)
org.jnp.interfaces.NamingContext.lookup(NamingContext.java:773)
org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
javax.naming.InitialContext.lookup(InitialContext.java:351)
org
.jboss
.seam.transaction.Transaction.getUserTransaction(Transaction.java:79)
org
.jboss
.seam.transaction.Transaction.createUTTransaction(Transaction.java:71)
org.jboss.seam.transaction.Transaction.getTransaction(Transaction.java:
44)
sun.reflect.GeneratedMethodAccessor6220.invoke(Unknown Source)
sun
.reflect
.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
java.lang.reflect.Method.invoke(Method.java:585)
org.jboss.seam.util.Reflections.invoke(Reflections.java:21)
org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:125)
org.jboss.seam.Component.callComponentMethod(Component.java:2195)
org.jboss.seam.Component.unwrap(Component.java:2221)
org.jboss.seam.Component.getInstance(Component.java:1988)
org.jboss.seam.Component.getInstance(Component.java:1951)
org.jboss.seam.Component.getInstance(Component.java:1928)
org.jboss.seam.Component.getInstance(Component.java:1923)
org.jboss.seam.transaction.Transaction.instance(Transaction.java:36)
org
.jboss
.seam
.persistence
.ManagedEntityIdentityInterceptor
.isTransactionRolledBackOrMarkedRolback
(ManagedEntityIdentityInterceptor.java:62)
org
.jboss
.seam
.persistence
.ManagedEntityIdentityInterceptor
.aroundInvoke(ManagedEntityIdentityInterceptor.java:50)
org
.jboss
.seam
.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
org
.jboss
.seam
.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:
31)
org
.jboss
.seam
.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
org
.jboss
.seam
.core
.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:42)
org
.jboss
.seam
.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:
107)
org
.jboss
.seam
.intercept
.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
org
.jboss
.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
org.jboss.seam.wiki.preferences.Preferences_$
$_javassist_21.get(Preferences_$$_javassist_21.java)
Right now our websites are basically not accessible, system load is >
20.00 with more than 30 blocked threads.
12 years, 9 months
