[Resin-interest] changes page broker
http://caucho.com/resin-4.0/changes/changes.xtp 500 Servlet Exception /var/www/hosts/www.caucho.com/webapps/resin-4.0/changes/changes.xtp:48: `/li.' expected `' at `'. Closing tags must close immediately after the tag name. 46: liconfig: app-oinf in cluster wasn't picked up properly (#5004)/li 47: licloud: EC2elastic server with ext: address and missing cluster-system-key (#5015)/li. 48: liservlet: add header-size-max and header-count-max (#4986, rep by Deepak Ramaprasad)/li 49: lideploy: web-socket issue causing large deployment problems (#5113, rep by Alexey Abashev)/li 50: liservlet: multipart-mime with forward parameters was double-parsing (#4896)/li -- Resin/4.0.27 Server: 'app-0' regards -Wesley ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4 stable for production ?
since 4.0.7 we use it in production site.
now we use 4.0.18.
our site suffered no less than 30M hits per day.
http://www.yinyuetai.com
2011/12/5 Jonathan Melly jonathan.me...@swissquote.ch
Hello.
We are still using some resin 3.0.24 and plan to migrate them but from
the caucho website, it's not clear if we should go for 3.1 or 4.0 or
even 3.2 (by the what is this 3.2 that I saw only on the source repo ?)
Thanks in advance for your help.
Jonathan Melly
Swissquote
Switzerland
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
--
*Wesley Wu 吴萌野*
QQ:18990702
Mobile: 18601033886
Email: wesley...@yinyuetai.com wesley...@yinyuetai.com
工体北路8号三里屯SOHO办公D座1103 邮编100027
[image: U3%8Y%PN7N{6ZGQY1F)PI_P]
www.yinyuetai.com
* *
image001.jpg___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] It seems resin 4.0.x does not implement Unified EL 2.2 properly
Hi Scott,
I used to bundle JUEL 2.1.x in my webapp and it run fine with resin 4.0.x.
After I upgrade to JUEL 2.2.3, some of the el expressions in jsp file
threw exceptions.
The error method invocation expressions is like:
${myBean.myMethod()}
it will produce
javax.el.MethodNotFoundException: Cannot find method 'myMethod' in
'class mypackage.MyBean'
I replaced java.el package in RESIN_HOME/lib/javaee16.jar with the
same package content in juel-2.2.3.jar
then everything went fine.
So I guess the implementation of java.el in resin maybe is conformed
to the EL 2.1 spec but not the EL 2.2 one.
I looked at the source of resin el implementation and found
java.el.CompositeELResolver did not implemented the
public Object invoke(ELContext context, Object base, Object method,
Class?[] paramTypes, Object[] params);
method which was added since EL 2.2.
any thoughts?
--
Wesley Wu
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] It seems resin 4.0.x does not implement Unified EL 2.2 properly
Hi Scott,
I used to bundle JUEL 2.1.x in my webapp and it run fine with resin 4.0.x.
After I upgrade to JUEL 2.2.3, some of the el expressions in jsp file
threw exceptions.
The error method invocation expressions is like:
${myBean.myMethod()}
it will produce
javax.el.MethodNotFoundException: Cannot find method 'myMethod' in
'class mypackage.MyBean'
I replaced java.el package in RESIN_HOME/lib/javaee16.jar with the
same package content in juel-2.2.3.jar
then everything went fine.
So I guess the implementation of java.el in resin maybe is conformed
to the EL 2.1 spec but not the EL 2.2 one.
I looked at the source of resin el implementation and found
java.el.CompositeELResolver did not implemented the
public Object invoke(ELContext context, Object base, Object method,
Class?[] paramTypes, Object[] params);
method which was added since EL 2.2.
any thoughts?
--
Wesley Wu
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] ScheduledThreadPool randomly failed to start throwing NullPointerException
Hi Scott,
I found resin sometimes can't start ScheduledThreadPool, resulting in
@Inject
ExecutorService executorService
not work (executorService is null).
can't precisely reproduce it coz it happened randomly when server restarts.
affected resin version:
Resin 4.0.s100809
Resin 4.0.18
[11-07-07 15:02:07.675] {resin-9} java.lang.NullPointerException
at
com.caucho.server.util.ScheduledThreadPool$TaskFuture.run(ScheduledThreadPool.java:591)
at
com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:164)
at
com.caucho.env.thread.ResinThread.run(ResinThread.java:130)
[11-07-07 15:02:07.675] {resin-9} java.lang.NullPointerException
at
com.caucho.server.util.ScheduledThreadPool$TaskFuture.run(ScheduledThreadPool.java:591)
at
com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:164)
at
com.caucho.env.thread.ResinThread.run(ResinThread.java:130)
[11-07-07 15:02:07.676] {resin-9} java.lang.NullPointerException
at
com.caucho.server.util.ScheduledThreadPool$TaskFuture.run(ScheduledThreadPool.java:591)
at
com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:164)
at
com.caucho.env.thread.ResinThread.run(ResinThread.java:130)
[11-07-07 15:02:07.676] {resin-9} java.lang.NullPointerException
at
com.caucho.server.util.ScheduledThreadPool$TaskFuture.run(ScheduledThreadPool.java:591)
at
com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:164)
at
com.caucho.env.thread.ResinThread.run(ResinThread.java:130)
-Wesley
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] no JMX ObjectName detected with jrockit vm
Hi Scott,
Resin 4.0.14 log many warnings about no JMX ObjectName detected
[11-02-11 00:19:23.324] {resin-34} MemoryTenuredHealthCheck: WARNING:
MemoryTenuredHealthCheck[] has no JMX ObjectName detected
[11-02-11 00:19:23.324] {resin-34} MemoryPermGenHealthCheck: WARNING:
MemoryPermGenHealthCheck[] has no JMX ObjectName detected
[11-02-11 00:24:23.327] {resin-360} MemoryTenuredHealthCheck: WARNING:
MemoryTenuredHealthCheck[] has no JMX ObjectName detected
[11-02-11 00:24:23.327] {resin-360} MemoryPermGenHealthCheck: WARNING:
MemoryPermGenHealthCheck[] has no JMX ObjectName detected
[11-02-11 00:29:23.330] {resin-309} MemoryTenuredHealthCheck: WARNING:
MemoryTenuredHealthCheck[] has no JMX ObjectName detected
[11-02-11 00:29:23.330] {resin-309} MemoryPermGenHealthCheck: WARNING:
MemoryPermGenHealthCheck[] has no JMX ObjectName detected
I'm using jrockit vm R28.1 64bit edition in CentOS 5.5.
-Wesley
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] InjectManager._selfBeanMap should be ConcurrentHashMap?
Thanks, Scott. Would you give out a snapshot and I will do some stress
test on it.
-Wesley
2010/11/30 Scott Ferguson f...@caucho.com:
Thanks. I've fixed it for the next release (changing to ConcurrentHashMap)
- Scott
Wesley Wu wrote:
Or this method sync the wrong map?
private SetBean? resolveAllBeans()
{
synchronized (_beanMap) {
LinkedHashSetBean? beans = new LinkedHashSetBean?();
for (ArrayListTypedBean comp : _selfBeanMap.values()) {
for (TypedBean typedBean : comp) {
beans.add(typedBean.getBean());
}
}
return beans;
}
}
maybe should synchronized (_selfBeanMap) instead.
-Wesley
2010/11/30 Wesley Wu wumen...@gmail.com:
2010-11-30 02:35:13.697 ERROR [Thread-48]
c.b.c.j.MessageReceiverDaemon -
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:977)
at java.util.HashMap$KeyIterator.next(HashMap.java:1012)
at java.util.HashMap.buildCache(HashMap.java:590)
at java.util.HashMap.resize(HashMap.java:576)
at java.util.HashMap.addEntry(HashMap.java:939)
at java.util.HashMap.put(HashMap.java:477)
at
com.caucho.config.inject.InjectManager.addBeanByType(InjectManager.java:720)
at
com.caucho.config.inject.InjectManager.addBeanByType(InjectManager.java:697)
at
com.caucho.config.inject.InjectManager.addBeanImpl(InjectManager.java:1205)
at
com.caucho.config.inject.InjectManager.addBean(InjectManager.java:1163)
at
com.caucho.config.inject.InjectManager.addBean(InjectManager.java:1133)
at
com.caucho.config.inject.InjectManager.addDiscoveredBean(InjectManager.java:3156)
at
com.caucho.config.inject.InjectManager.discoverBeanImpl(InjectManager.java:3128)
at
com.caucho.config.inject.InjectManager.processPendingAnnotatedTypes(InjectManager.java:2868)
at
com.caucho.config.inject.InjectManager.fillByType(InjectManager.java:1540)
at
com.caucho.config.inject.InjectManager.access$200(InjectManager.java:158)
at
com.caucho.config.inject.InjectManager$FillByType.apply(InjectManager.java:3929)
at
com.caucho.loader.EnvironmentClassLoader.applyVisibleModules(EnvironmentClassLoader.java:703)
at
com.caucho.config.inject.InjectManager.getWebComponent(InjectManager.java:1505)
at
com.caucho.config.inject.InjectManager.resolveRec(InjectManager.java:1369)
at
com.caucho.config.inject.InjectManager.resolve(InjectManager.java:1360)
at
com.caucho.config.inject.InjectManager.getBeans(InjectManager.java:1308)
at
mdi.java.factory.MDIObjectFactory.buildBean(MDIObjectFactory.java:121)
at
com.buysou.cms.jms.MessageDestinationStore$DefaultMessageReceivedCallback.onReceive(MessageDestinationStore.java:168)
at
com.buysou.cms.jms.MessageReceiverDaemon.start(MessageReceiverDaemon.java:61)
at
com.buysou.cms.jms.MessageReceiverDaemon.run(MessageReceiverDaemon.java:42)
at java.lang.Thread.run(Thread.java:619)
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin CanDI not support @Alternative ?
Hi Scott,
Thanks for the checking.
My deployment causing the problem:
XaPooledConnectionFactory was in a jar called buysou-jms.jar which
contains a beans.xml.
buysou_cms.jar was deployed in WEB-INF/lib.
===the beans.xml in buysou_cms.jar==
beans xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/beans_1_0.xsd;
xmlns:config=urn:java:com.buysou.cms.config
config:BeanRewriteConfig/
/beans
Note: The purpose of config:BeanRewriteConfig/ line is to load
com.buysou.cms.config.BeanRewriteConfig at startup.
After I removed the line config:BeanRewriteConfig/ the @Alternative
worked as a charm.
The problem was solved by annotate a @Startup on BeanRewriteConfig
instead of put it in the beans.xml.
Thanks.
-Wesley
2010/11/2 Scott Ferguson f...@caucho.com:
I just checked with that example and it's working fine. Where are the
files/classes located, and how is JmsTemplate instantiated?
-- Scott
Wesley Wu wrote:
==beans.xml===
?xml version=1.0 encoding=UTF-8?
beans xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/beans_1_0.xsd;
alternatives
classcom.buysou.cms.jms.qpid.pool.XaPooledConnectionFactory/class
/alternatives
/beans
the alternative implementation==
@Alternative
@ApplicationScoped
public class XaPooledConnectionFactory implements
javax.jms.ConnectionFactory {
...
}
usage==
public class JmsTemplate {
@Inject
ConnectionFactory factory;
...
}
- Wesley
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Resin CanDI not support @Alternative ?
==beans.xml===
?xml version=1.0 encoding=UTF-8?
beans xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/beans_1_0.xsd;
alternatives
classcom.buysou.cms.jms.qpid.pool.XaPooledConnectionFactory/class
/alternatives
/beans
the alternative implementation==
@Alternative
@ApplicationScoped
public class XaPooledConnectionFactory implements javax.jms.ConnectionFactory {
...
}
usage==
public class JmsTemplate {
@Inject
ConnectionFactory factory;
...
}
- Wesley
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] ConnectionPool pool overflow issue again in resin 4.0.10
Hi Scott,
I experienced ConnectionPool pool overflow issue again in resin 4.0.10.
Some time (probably 20 minutes) after resin started, resin reported:
[10-10-08 01:07:28.555] {server://*:6801-5523}
ConnectionPool[jdbc/mypool] pool overflow
[10-10-08 01:07:28.555] {server://*:6801-5109}
ConnectionPool[jdbc/mypool] pool overflow
[10-10-08 01:07:28.557] {server://*:6801-5435}
ConnectionPool[jdbc/mypool] pool overflow
[10-10-08 01:07:28.557] {server://*:6801-5494}
ConnectionPool[jdbc/mypool] pool overflow
[10-10-08 01:07:28.568] {server://*:6801-5520}
ConnectionPool[jdbc/mypool] pool overflow
[10-10-08 01:07:28.568] {server://*:6801-5542}
ConnectionPool[jdbc/mypool] pool overflow
[10-10-08 01:07:28.576] {server://*:6801-5633}
ConnectionPool[jdbc/mypool] pool overflow
but my pool was not full at all which size was 2000.
I met this before in resin 4.0.9 which caused by the alarm issue.
Then I switched back to Resin 4.0.9.s100809 and everything went fine.
I'll do a fine log if required.
Thanks.
-Wesley
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] ConcurrentModificationException when InjectManager.findByName
Thanks Scott. Is my code causing this error as Aaron said?
-Wesley
2010/8/20 Scott Ferguson f...@caucho.com:
Aaron Freeman wrote:
This is an error in your JSP/JSTL, not with Resin -- you are trying to
modify (add to) a HashMap that you are iterating over.
Except it's the Resin code that's modifying the HashMap. It's an easy fix.
-- Scott
Here is a more detailed explanation:
http://forums.sun.com/thread.jspa?threadID=5335803
Aaron
On 8/19/2010 4:20 AM, Wesley Wu wrote:
Often happened at 30 seconds after appserver start.
[10-08-19 17:11:44.378] {server://*:6801-487}
java.util.ConcurrentModificationException
at
java.util.HashMap$HashIterator.nextEntry(HashMap.java:977)
at
java.util.HashMap$KeyIterator.next(HashMap.java:1012)
at
java.util.HashMap.buildCache(HashMap.java:590)
at
java.util.HashMap.resize(HashMap.java:576)
at
java.util.HashMap.addEntry(HashMap.java:939)
at
java.util.HashMap.put(HashMap.java:477)
at
com.caucho.config.inject.InjectManager.findByName(InjectManager.java:759)
at
com.caucho.config.inject.InjectManager.getBeans(InjectManager.java:1254)
at
com.caucho.config.inject.InjectManager.getReferenceFactory(InjectManager.java:1268)
at
com.caucho.config.el.CandiElResolver.getValue(CandiElResolver.java:125)
at
com.caucho.el.EnvironmentLevelELResolver.getValue(EnvironmentLevelELResolver.java:154)
at
com.caucho.el.EnvironmentELResolver.getValue(EnvironmentELResolver.java:151)
at
com.caucho.el.StackELResolver.getValue(StackELResolver.java:143)
at
com.caucho.jsp.InitPageContextImpl.resolveVariable(InitPageContextImpl.java:88)
at
com.caucho.jsp.PageContextImpl$PageVariableMapper.resolveVariable(PageContextImpl.java:2183)
at
com.caucho.el.ELParser.parseSimpleTerm(ELParser.java:702)
at
com.caucho.el.ELParser.parseTerm(ELParser.java:460)
at
com.caucho.el.ELParser.parseExpr(ELParser.java:231)
at
com.caucho.el.ELParser.parseInterpolate(ELParser.java:194)
at
com.caucho.el.ELParser.parse(ELParser.java:113)
at
com.caucho.jsp.JspUtil.createExpr(JspUtil.java:69)
at
_jsp._WEB_22dINF._templates._default._home._album._view__jsp.caucho_init(_view__jsp.java:752)
at
com.caucho.jsp.JspManager.loadPage(JspManager.java:422)
at
com.caucho.jsp.JspManager.preload(JspManager.java:357)
at
com.caucho.jsp.JspManager.compile(JspManager.java:236)
at
com.caucho.jsp.JspManager.createPage(JspManager.java:191)
at
com.caucho.jsp.JspManager.createPage(JspManager.java:170)
at
com.caucho.jsp.PageManager.getPage(PageManager.java:339)
at
com.caucho.jsp.PageManager.getPage(PageManager.java:269)
at
com.caucho.jsp.PageManager.getPage(PageManager.java:252)
at
com.caucho.jsp.QServlet.getSubPage(QServlet.java:295)
at
com.caucho.jsp.QServlet.getPage(QServlet.java:210)
at
com.caucho.server.dispatch.PageFilterChain.compilePage(PageFilterChain.java:237)
at
com.caucho.server.dispatch.PageFilterChain.doFilter(PageFilterChain.java:144)
at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:287)
at
com.caucho.server.webapp.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:289)
-Wesley
___
resin-interest mailing list
resin-interest@caucho.com
http
Re: [Resin-interest] Possible memory leak in Resin 4.0.9
Hi Scott, I believe I've fixed this issue by adding @ApplicationScoped and @RequestedScoped annotation to my beans. :) Thanks for your efforts. -Wesley 2010/8/18 Wesley Wu wumen...@gmail.com: Hi Scott, Thanks for the checking. Today I double checked the CDI spec and got some new knowledge. Nearly all my beans were not annotated with any scope, so that they should be @Dependent. Some of the beans were created (not injected) in a servlet filter via a static ObjectFactory. I think the beans should be transient but they are NOT. They actually were probably immortal because they were created in a servlet filter (singleton in webapp). And also my ObjectFactory was annotated with @Singleton too, too bad. As a workaround, I may annotated most my beans as @ApplicationScoped or @SessionScoped, because they're all stateless. At least after a bean was annotated as @SessionScoped, the @PreDestroy method was correctly fired when the request ended. This workaround SHOULD address the memory leak problem of my site, though not thoroughly tested. It's my initial thought. Hope you have a full story to tell me, if u've got some time. :) Thanks again. -Wesley ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Possible memory leak in Resin 4.0.9
2010/8/20 Scott Ferguson f...@caucho.com: I still think there's a chance for a Resin leak; I just don't understand where it's coming from. I think so. The same code worked fine (no leak) in Resin 4.0.5. It shouldn't matter what context you're injecting from, as long as you're creating a new top-level CreationalContext. The getReference for a dependent bean shouldn't have any references to it. -- Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Possible memory leak in Resin 4.0.9
I'll tried to do so. 2010/8/20 Scott Ferguson f...@caucho.com: Wesley Wu wrote: 2010/8/20 Scott Ferguson f...@caucho.com: I still think there's a chance for a Resin leak; I just don't understand where it's coming from. I think so. The same code worked fine (no leak) in Resin 4.0.5. Do you have access to the eclipse mat program or some other heap analyzer? If you can reproduce the issue, ask Resin to dump the heap (it's in /resin-admin/memory with the jvm heap dump button), and then ask the heap analyzer to trace the leaking memory to root, it would help track down this issue greatly. -- Scott It shouldn't matter what context you're injecting from, as long as you're creating a new top-level CreationalContext. The getReference for a dependent bean shouldn't have any references to it. -- Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Possible memory leak in Resin 4.0.9
Hi Scott, Thanks for the checking. Today I double checked the CDI spec and got some new knowledge. Nearly all my beans were not annotated with any scope, so that they should be @Dependent. Some of the beans were created (not injected) in a servlet filter via a static ObjectFactory. I think the beans should be transient but they are NOT. They actually were probably immortal because they were created in a servlet filter (singleton in webapp). And also my ObjectFactory was annotated with @Singleton too, too bad. As a workaround, I may annotated most my beans as @ApplicationScoped or @SessionScoped, because they're all stateless. At least after a bean was annotated as @SessionScoped, the @PreDestroy method was correctly fired when the request ended. This workaround SHOULD address the memory leak problem of my site, though not thoroughly tested. It's my initial thought. Hope you have a full story to tell me, if u've got some time. :) Thanks again. -Wesley ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4.0.9 release
Hi Jan, Did your resin server have a busy traffic? Did u observed any memory leak or heap overflow? -Wesley ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Possible memory leak in Resin 4.0.9
Hi Scott, The memory leak circumstance was not spotted in Resin 4.0.5 and early 4.0.x versions. One of the inject path is: * A filter CmsPageFilter dispatch a request to a Jsp page through javax.servlet.RequestDispatcher.forward(request, response) * Jsp page called a BeanMethod custom jsp tag * The jsp tag create a VideoManager through my BeanManager wrapper (MDIObjectFactory) * VideoManager injects a PersonManager * PersonManager injects a PersonController * PersonController injects a DefaultBeanManager and a DefaultBeanReader * DefaultBeanManager and DefaultBeanReader inject a CmsPersistentUnit(@Singleton) * CmsPersistentUnit injects a javax.persistence.EntityManagerFactory (@PersistenceUnit) All those beans except CmsPersistentUnit were dependent scoped (not explicitly annotated) and should be created at its inject point and freed when the parent bean (the jsp page) was destroyed. I list three most frequently bean creation process here. #handle jsp tag which requires bean creation=== # this call should be the creation of an @Dependent (thought not explicitly annotated) beans # like com.buysou.cms.managers.DefaultBeanManager or com.buysou.cms.managers.DefaultBeanReader # (for writing/reading database through a @RequestScoped @PersistentContext) com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, CreationalContextImpl, InjectionPoint) 118 com.caucho.config.inject.InjectionTargetBuilder$FieldInjectProgram.inject(Object, CreationalContext) 117 com.caucho.config.inject.CandiProducer.inject(Object, CreationalContext) 117 com.caucho.config.inject.InjectionTargetBuilder.inject(Object, CreationalContext) 117 com.caucho.config.inject.ManagedBeanImpl.createDependent(CreationalContext) 117 com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, CreationalContextImpl, InjectionPoint) 117 com.caucho.config.inject.InjectionTargetBuilder$FieldInjectProgram.inject(Object, CreationalContext) 114 com.caucho.config.inject.CandiProducer.inject(Object, CreationalContext) 114 com.caucho.config.inject.InjectionTargetBuilder.inject(Object, CreationalContext) 114 com.caucho.config.inject.ManagedBeanImpl.createDependent(CreationalContext) 114 com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, CreationalContextImpl, InjectionPoint) 114 com.caucho.config.inject.InjectionTargetBuilder$FieldInjectProgram.inject(Object, CreationalContext) 112 com.caucho.config.inject.CandiProducer.inject(Object, CreationalContext) 112 com.caucho.config.inject.InjectionTargetBuilder.inject(Object, CreationalContext) 112 com.caucho.config.inject.ManagedBeanImpl.createDependent(CreationalContext) 111 com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, CreationalContextImpl, InjectionPoint) 111 com.caucho.config.inject.InjectionTargetBuilder$FieldInjectProgram.inject(Object, CreationalContext) 103 com.caucho.config.inject.CandiProducer.inject(Object, CreationalContext) 103 com.caucho.config.inject.InjectionTargetBuilder.inject(Object, CreationalContext) 103 com.caucho.config.inject.ManagedBeanImpl.createDependent(CreationalContext) 103 com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, CreationalContextImpl, InjectionPoint) 103 com.caucho.config.inject.InjectionTargetBuilder$FieldInjectProgram.inject(Object, CreationalContext) 89 com.caucho.config.inject.CandiProducer.inject(Object, CreationalContext) 89 com.caucho.config.inject.InjectionTargetBuilder.inject(Object, CreationalContext) 89 com.caucho.config.inject.ManagedBeanImpl.createDependent(CreationalContext) 88 com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, CreationalContextImpl, InjectionPoint) 88 com.caucho.config.inject.InjectionTargetBuilder$FieldInjectProgram.inject(Object, CreationalContext) 60 com.caucho.config.inject.CandiProducer.inject(Object, CreationalContext) 60 com.caucho.config.inject.InjectionTargetBuilder.inject(Object, CreationalContext) 60 com.caucho.config.inject.ManagedBeanImpl.createDependent(CreationalContext) 58 com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, CreationalContextImpl, InjectionPoint) 58 com.caucho.config.inject.InjectionTargetBuilder$FieldInjectProgram.inject(Object, CreationalContext) 34 com.caucho.config.inject.CandiProducer.inject(Object, CreationalContext) 34 com.caucho.config.inject.InjectionTargetBuilder.inject(Object, CreationalContext) 34 com.caucho.config.inject.ManagedBeanImpl.createDependent(CreationalContext) 33 com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl,
Re: [Resin-interest] Possible memory leak in Resin 4.0.9
My BeanManager wrapper code
@Singleton
@Startup
public class MDIObjectFactory {
private static BeanManager beanManager;
private static BeanManager getBeanManager() {
if (beanManager == null) {
try {
InitialContext ic = new InitialContext();
beanManager = (BeanManager)
ic.lookup(java:comp/BeanManager);
} catch (Exception e) {
throw new RuntimeException(e);
}
}
return beanManager;
}
...
public T T buildBean(ClassT beanClass) {
Named named = beanClass.getAnnotation(Named.class);
if (named != null) {
BeanT bean = (BeanT)
beanManager.resolve(beanManager.getBeans(named.value()));
CreationalContextT env =
beanManager.createCreationalContext(bean);
return (T) beanManager.getReference(bean,
bean.getBeanClass(), env);
}
BeanT bean = (BeanT)
beanManager.resolve(beanManager.getBeans(beanClass));
CreationalContextT env =
beanManager.createCreationalContext(bean);
return (T) beanManager.getReference(bean, beanClass, env);
}
public Object buildBean(String beanName) {
Bean bean = beanManager.resolve(beanManager.getBeans(beanName));
CreationalContext env =
beanManager.createCreationalContext(bean);
return beanManager.getReference(bean, bean.getBeanClass(), env);
}
...
}
-Wesley
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Possible memory leak in Resin 4.0.9
Hi Scott, I've applied the 4.0.10 snapshot and the Alarm issue went away. Thanks. But Resin consumed all memory after certain hours and resulted in a halt or restart. I did a jrockit flight recording and found there was a slow heap increase during various GCs. The recording file shows the objects in heap order by total size occupied descending as below: Class InstancesSize(bytes) Percentage%(%) com.caucho.config.inject.DependentCreationalContext 48,722,158 1,559,109,040 49.08 com.buysou.cms.managers.DefaultBeanManager 11,970,792 287,299,020 9.044 com.buysou.cms.managers.DefaultBeanReader 14,126,509 226,024,144 7.115 com.buysou.cms.utils.reflection.GenericReflectionProvider 11,970,802 191,532,840 6.029 char[] 1,792,936 160,800,482 5.062 (others omitted) Obviously the DependentCreationalContext eat up the heap. Note: DefaultBeanManager DefaultBeanReader GenericReflectionProvider are non singleton beans which were injected into other beans at Dependent context (should be GCed when request ends). Any ideas? -Wesley ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] ConnectionPool pool overflow issue in Resin 4.0.9
Thanks. Be sure to notify in the mailing list when the snapshot is out. :) 2010/8/7 Scott Ferguson f...@caucho.com: Wesley Wu wrote: Hi Scott, I've experienced weird connection pool issue in 4.0.9 these days. After every hour (exactly), the 4.0.9 resin refused to service any request and occasionally report ConnectionPool [...] pool overflow. This situation never occurred in prior resin releases and neither my webapp nor config was not modified at all after upgrade 4.0.5 to 4.0.9. Thanks. I think I've found it, and it should be related to the restart problem that Jan Kriesten has reported. I'll see if I can get a snapshot by Monday to verify the problem. -- Scott I've no idea what happened though I research the 4.0.9 source code. I noticed that ConnectionPool.java UserPoolItem.java were moved to another package but no major modification were made. I did a fine log, here goes the log content (partial) for download: http://gp.niugoo.com/resin.partial.zip == Resin database config: database name=jdbc/yinyuetai driver url=jdbc:mysql://192.168.1.2:3306/bbsee?useUnicode=truecharacterEncoding=utf8 class=com.mysql.jdbc.Driver /driver spyfalse/spy max-connections1500/max-connections max-idle-count1024/max-idle-count max-create-connections5/max-create-connections max-overflow-connections1024/max-overflow-connections max-idle-time30s/max-idle-time max-active-time6h/max-active-time max-pool-time1d/max-pool-time connection-wait-time30s/connection-wait-time /database -Wesley ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] ConnectionPool pool overflow issue in Resin 4.0.9
Hi Scott, I've experienced weird connection pool issue in 4.0.9 these days. After every hour (exactly), the 4.0.9 resin refused to service any request and occasionally report ConnectionPool [...] pool overflow. This situation never occurred in prior resin releases and neither my webapp nor config was not modified at all after upgrade 4.0.5 to 4.0.9. I've no idea what happened though I research the 4.0.9 source code. I noticed that ConnectionPool.java UserPoolItem.java were moved to another package but no major modification were made. I did a fine log, here goes the log content (partial) for download: http://gp.niugoo.com/resin.partial.zip == Resin database config: database name=jdbc/yinyuetai driver url=jdbc:mysql://192.168.1.2:3306/bbsee?useUnicode=truecharacterEncoding=utf8 class=com.mysql.jdbc.Driver /driver spyfalse/spy max-connections1500/max-connections max-idle-count1024/max-idle-count max-create-connections5/max-create-connections max-overflow-connections1024/max-overflow-connections max-idle-time30s/max-idle-time max-active-time6h/max-active-time max-pool-time1d/max-pool-time connection-wait-time30s/connection-wait-time /database -Wesley ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Servlet 3.0 file upload feature (javax.servlet.http.Part) improperly implemented
Hi Scott,
I found a frustrating problem when porting my framework to accommodate the
Servlet 3.0 file upload spec in Resin 4.0.8/4.0.9.
There did has a (private Object _value) in
com.caucho.server.http.HttpServletRequestImpl.PartImpl, however,
if it's not a file upload but a common text form field, I could nowhere to
retreive the text value
of the part throught current implementation.
I don't want to write the text value to a file and read it into a string.
It's just stupid.
I know it's probably a spec issue without an
Object getValue();
or
String getTextValue();
, but it does has a workaround.
I think the getInputStream() should not return null when the Part is a
normal form field.
It may return a StringReader or something to let me get the string value
throught the InputStream.
maybe like this (from
http://balusc.blogspot.com/2009/12/uploading-files-in-servlet-30.html)
/**
* Returns the text value of the given part.
*/
private String getValue(Part part) throws IOException {
String value = new
BufferedReader(newInputStreamReader(part.getInputStream(),
encoding)).readLine();
return (value != null) ? value : ; // Must be empty String according
HTTP spec.
}
Now I have to use
request.getParameterValues(part.getName());
to retrieve the text form field value. But I know it must be wrong, because
we may have multiple fields have the same name.
-Wesley
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Severe InjectManager.getCurrent synchronization problem at high load, fixed in 4.0.9?
Hi Scott,
We're running Resin 4.0.5 for a heavy traffic site (100K+ Pageviews in an
hour) for a couple of months.
In the past several days I've experienced frequent failing responding of
requests after two or three hours a Resin instance was started.
The environment:
Hardware: 16 cores with 24GB ram
OS: Centos 5.5 64bit
Java Version: Oracle JRockit(R) (build
R28.0.0-679-130297-1.6.0_17-20100312-2121-linux-x86_64, compiled mode)
Database: Mysql 5.1.47 64bit (on another Centos 5.5 box with 8 cores and
12GB ram)
The situation:
* Java process running the resin CPU utilization: raised from the
usual 60%~150% to 200%~300% (16Cores)
* Threads in resin server: raised from usual 200~800 to 1500~3000
* Resin Centos box load average: no notable change
* Database CPU utilization: dropped from the usual 50%~200% to below 10%
(8Cores)
* DB box IO utilization: drop from the usual 3%~5% to below 1%
* DB box load average: no notable change
* Most browser requests were blocked, no result, no error.
I have to restart it after it hanged.
I did jvm flight recordings of the jrockit JVM before restart for several
times.
The jfr record file show that, in most of the time, the threads were blocked
in class InjectManager
public static InjectManager getCurrent(ClassLoader loader) {
synchronized (_localContainer) {
return _localContainer.get(loader);
}
}
I noticed in the 4.0.9 source, it changed to
public static InjectManager getCurrent(ClassLoader loader)
{
return _localContainer.get(loader);
}
Probably this problem has bean resolved but I need to do more test in next
week.
Thanks for the great work.
-Wesley
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4.0.9 release
Oh my god Scott, you rule it!
/**
* Returns the current environment container.
*/
public static InjectManager getCurrent(ClassLoader loader)
{
return _localContainer.get(loader);
}
finally the synchronized (_localContainer) was gone!
You have no idea how I suffered from the locking problem of previous Resin
4.0.x.
My heavy traffic website hanged several times a day.
Thanks a lot!
I'll try 4.0.9 immediately.
-Wesley
2010/7/31 Scott Ferguson f...@caucho.com
Just an important note on Resin 4.0.9.
Most of the work for this release was related to low level improvements
and fixes to core capabilities like the locking for distributed caching,
replacing synchronization with atomic locks in the core thread
dispatching, improving the core alarm/timer functionality, fixing the
watchdog/cluster authentication, and organizing the core Resin startup
code to fix some startup timing problems.
We added extra tests for those capabilities, and added several automatic
stress tests to our nightly check.
Still, since these are core fixes to critical timing-related
capabilities that are hard to test exhaustively, you may want to take
extra care in your own testing before deploying on 4.0.9.
-- Scott
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] A request for caucho apache module - connect to an instance only after CDI deployment finished
Thanks for the Priority = normal :) -Wesley ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] A request for caucho apache module - connect to an instance only after CDI deployment finished
Hi Scott, The request: Make caucho apache module to act (maybe should be configurable) as below : When check a Resin instance whether it is ready to accept connections, make sure it's not only started normally, but also all CDI startup beans were already initialized and deployed (after @PostConstuct call finished maybe). === The problem supposed to be solved: I have some @Startup beans to load various configrations from both property files and database tables in their @PostConstuct methods. This stage usually takes 40~100 seconds to finish. Should I call this stage a deployment stage, Or they're indeed tasks which the Resin App Server deployment stage will do? Almost every my web request (filters/servlets) has dependencies to these configurations. There won't be any requests be served and they'll be all blocked by either locks I defined or something else until the deployment stage finish. So I need the caucho apache module not to redirect requests to a resin instance in deployment stage, because it's just not ready yet! I have to suffer from a 40~100 seconds request halt/blocking after bring a resin instance on in a cluster, whose forend is an apache httpd server, of course without restarting the httpd service. Hope I described the problem and the request. Or there's any way out to solve this problem currently? -Wesley ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Numerous problems moving to 4.0.8
My taglibs ?xml version=1.0 encoding=ISO-8859-1 ? taglib xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; version=2.0 xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd; tlib-version1.0/tlib-version ... /taglib has not problem in classes/META-INF 2010/7/5 Rick Mann rm...@latencyzero.com: On Jul 4, 2010, at 21:55:34, Wesley Wu wrote: Hi Rick Try to place the tld at WEB-INF/classes/META-INF/your_tld_file.tld. I don't think that should be necessary. You're supposed to be able to place a directory inside WEB-INF/tags, and then .tag files inside that, and create namespace of tags in that directory. -- Rick ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Resin 4.0.8 passed the tck?
Hi,
I noticed there is a 4.0.8 release at 6/30, and I tried it out.
Seems fine besides some minor problem described below.
***. MDBs implements MessageListener can't have an @Override on
onMessage method.
I have to remove these annos to make it run.
@Override
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
***. according to the CDI spec, @Inject on a static field is not
allowed anymore, is it right.
Congratulations to the hard work!
=
There remains a long live big problem confused me.
I quoted from CDI spec Chapter 11. Portable extensions
[quote]
11.5.3. AfterDeploymentValidation event
The container must fire a third event after it has validated that
there are no deployment problems and before creating contexts or
processing requests.
The event object must be of type
javax.enterprise.inject.spi.AfterDeploymentValidation:
public interface AfterDeploymentValidation {
public void addDeploymentProblem(Throwable t);
}
addDeploymentProblem() registers a deployment problem with the
container, causing the container to abort deployment after all
observers have been notified.
void afterDeploymentValidation(@Observes AfterDeploymentValidation
event, BeanManager manager) { ... }
If any observer method of the AfterDeploymentValidation event throws
an exception, the exception is treated as a deployment problem by the
container.
The container must not allow any request to be processed by the
deployment until all observers of this event return.
[/quote]
I never saw any version of resin 4.0.x implemented this function.
When I write a method like:
public void bootstrap(@Observes AfterDeploymentValidation event,
BeanManager manager) {
...
}
and it never got called.
-Wesley
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Numerous problems moving to 4.0.8
Hi Rick Try to place the tld at WEB-INF/classes/META-INF/your_tld_file.tld. -Wesley ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Hibernate transactions
To make set method auto translated into a UPDATE clause, the
entitymanager should be opened after a transaction begins.
@PersistenceUnit(unitName=example)
EntityManagerFactory emf;
EntityManager em;
try {
ut.begin();
EntityManager em= emf.createEntityManager();
CourseBean updateCourse = em.find(CourseBean.class, new
Integer(1));
updateCourse.setCourse(Magic);
ut.commit();
} catch (Exception e) {
e.printStackTrace();
} finally {
if (em != null em.isOpen()) {
em.close();
}
}
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Hibernate transactions
Yes. One minor problem:
@PersistentContext should be @PersistentUnit.
That's exactly what I used to do in the past three years.
I controlled the entitymanager and transaction by my own code in a JPA
wrapper class,
and gained great performance advantage over automatic transaction handling
like @TransactionAttribute.
I never inject a @PersistentContext or never use a container provided
EntityManager.
I use ThreadLocal to maintain every EntityManager instance.
-Wesley
2010/3/30 Stargazer starga...@blueyonder.co.uk
On 30-Mar-2010 09:34, Wesley Wu wrote:
To make set method auto translated into a UPDATE clause, the
entitymanager should be opened after a transaction begins.
Sincere thanks again, hopefully this will all help others coming across
it in the future.
If I understood you correctly I made those changes and now get
example.CourseServlet.emf : @PersistenceContext field must be assignable
from EntityManager.
Heres the new full servlet:
package example;
import java.io.IOException;
import java.io.PrintWriter;
import javax.inject.Inject;
import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.PersistenceContext;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.transaction.UserTransaction;
public class CourseServlet extends HttpServlet
{
// Resin IoC will inject this
@PersistenceContext(unitName=example)
EntityManagerFactory emf;
@Inject
private UserTransaction ut;
public void service(HttpServletRequest request, HttpServletResponse
response)
throws IOException, ServletException
{
PrintWriter out = response.getWriter();
response.setContentType(text/html);
EntityManager em = null;
try {
ut.begin();
em = emf.createEntityManager();
CourseBean updateCourse = em.find(CourseBean.class, new
Integer(1));
updateCourse.setCourse(Magic);
ut.commit();
} catch (Exception e) {
e.printStackTrace();
} finally {
if (em != null em.isOpen()) {
em.close();
}
}
}
}
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Hibernate transactions
I will not call UserTransaction.begin() when all db operations are SELECT. I create a EntityManager from emf to do SELECT stuff with no transaction at all. When I detected there're some update/delete operations, I'll do this: 1. close the former created EntityManager if there is one (for precedent SELECT op) 2. call UserTransaction.begin() 3. create a new EntityManager 4. do left jobs 5. commint() on success or rollback() on failure. *. finally (always) close the em (bounded to current thread) and set current ThreadLocalEntityManger to null. This worked for me in the last three years in several heavy loaded websites. -Wesley 2010/3/31 Scott Ferguson f...@caucho.com Why would calling UserTransaction in your code be faster? Essentially, all @TransactionAttribute does is call UserTransaction.begin() and commit(). (Any extra overhead should be minimal, especially compared to the actual transaction.) -- Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Hibernate transactions
More to mention about MDBs (Message Driven Beans):
1. Always use @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
on public void onMessage(Message message).
because the impl of Resin MDBs has severe reenter synchronization problem.
If I start a transaction before onMessage() being called there would be
several transactions tried to crossing commit in unexpected manner.
2. Inject a ExecutorService to do the real stuff.
public class MyMessageDrivenBean implements MessageListener {
@Inject
ExecutorService executorService;
private InjectManager _webBeans = InjectManager.create();
@Override
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
public void onMessage(Message message) {
RealStuffRunnable runnable = webBeans.getReference(RealStuffRunnable
.class);
// set some properties of runnable
...
// run it in a new thread
executorService.execute(runnable);
}
}
3. Use @TransactionAttribute on RealStuffRunnable.run()
Thus my real stuff will not suffer from the reenter and crossing commit.
Any better solutions?
-Wesley
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Hibernate transactions
Not a version issue. An entitymanager should not get transaction by itself. Transaction in a modern java appserver should be XA or JTA transaciton. An entitymanager will detect if there is a JTA transaction existing and will join it if there is an open one. You need to use an injected UserTransaction instance to do the transaction stuff and leave the entitymanager do db stuff and the entitymanager will participate in the transaction. -Wesley 2010/3/29 Stargazer starga...@blueyonder.co.uk On 27-Mar-2010 01:10, Stargazer wrote: Resin 4.0.5 - following http://wiki.caucho.com/Hibernate works fine, but I'd like to take it to the next level and persist something. Adding EntityTransaction tx = _manager.getTransaction(); tx.begin(); ... to the end of the CourseServlet.java file throws up java.lang.IllegalStateException: Container-manager @PersistenceContext may not use getTransaction. What have I missed please? ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest Could anyone tell me if this worked in an earlier vrsion of resin please? Its the first time I've tried hibernate with resin, and I can't tell if its something I'm doing (or not doing!) here or related to an issue in 4.0.5. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] CanDI java.lang.StackOverflowError
This could be a lazy init problem I think.
The scheduled tasks would be inited before some of other beans which
the tasks need.
I've met this before.
The workaround:
Inject the Injector into your task, no other webbeans.
When the task starts (run()), create webbeans instances via the injector.
-Wesley
2010/2/11 Hontvári József hontv...@flyordie.com:
I reduced the configuration to the minimum. It consists of a circular setter
dependency, and then a separate third constructor initialization which
refers to one of circular items. Both have to be present, otherwise
StackOverflow doesn't happen. I attached a configuration sample and a part
of the log file, logged on finer level.
Scott Ferguson írta:
Hontvári József wrote:
I receive java.lang.StackOverflowError when Resin tries to read the
configuration file:
[10-02-10 10:31:56.929] {resin-37}
C:/Progra~1/mireka-1.2/conf/mireka.xml:325: com.caucho.confi
g.core.ResinIf.init(): java.lang.StackOverflowError
I believe there is no circular constructor dependency in the file. To be
sure I replaced almost all constructor initialisation blocks with setter
initialization. Is there a way to debug this error? There is no stack
trace or anything else in the log.
Can you send that section of the configuration file? It looks like it's
something to do with the resin:if like the test EL expression,
although it could also be the contents of the if.
Also, it's possible that adding a logger name= level=finer/ in the
resin section will show the stack trace.
-- Scott
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
mireka:ScheduleFileDirQueue
NamedsubmittedMailQueue/Named
mireka:mailProcessorFactory
#{primaryTransmitter}
/mireka:mailProcessorFactory
/mireka:ScheduleFileDirQueue
mireka:QueuingTransmitter
NamedprimaryTransmitter/Named
mireka:queue
#{submittedMailQueue}
/mireka:queue
/mireka:QueuingTransmitter
mireka:Dummy
new
#{primaryTransmitter}
/new
/mireka:Dummy
Resin-4.0.3 (built Tue, 05 Jan 2010 09:09:02 PST)
Copyright(c) 1998-2008 Caucho Technology. All rights reserved.
Using Resin(R) Open Source under the GNU Public License (GPL).
See http://www.caucho.com for information on Resin Professional,
including caching, clustering, JNI acceleration, and OpenSSL integration.
Starting Resin on Wed, 10 Feb 2010 20:39:23 +0100 (CET)
[10-02-10 20:39:24.288] {main} resin:import 'C:\Program
Files\resin-4.0.3\conf\app-default.xml'
[10-02-10 20:39:24.429] {main} Resin[] init
[10-02-10 20:39:24.429] {main} Resin[] active
[10-02-10 20:39:24.538] {main} InjectManager[server:app-tier:main] add bean
SingletonBean[InjectManager, {...@default()}]
[10-02-10 20:39:24.601] {main} InjectManager[server:app-tier:main] add bean
XmlBean[DeployService, {...@default()}, @Singleton]
[10-02-10 20:39:24.632] {main} 'select-manager' requires Resin Professional.
See http://www.caucho.com for information and licensing.
[10-02-10 20:39:24.648] {main} Server[id=,cluster=app-tier] starting
[10-02-10 20:39:24.648] {main}
[10-02-10 20:39:24.648] {main} Windows XP 5.1 x86
[10-02-10 20:39:24.648] {main} Java(TM) SE Runtime Environment 1.6.0_18-b07,
Cp1250, hu
[10-02-10 20:39:24.648] {main} Java HotSpot(TM) Client VM 16.0-b13, 32,
mixed mode, sharing, Sun Microsystems Inc.
[10-02-10 20:39:24.648] {main}
[10-02-10 20:39:24.648] {main} resin.home = C:\Program Files\resin-4.0.3\
[10-02-10 20:39:24.648] {main} resin.root = C:\Program Files\resin-4.0.3\
[10-02-10 20:39:24.648] {main} resin.conf = /C:/Program
Files/resin-4.0.3/conf/resin.xml
[10-02-10 20:39:24.648] {main}
[10-02-10 20:39:24.648] {main} server = 127.0.0.1:6800 (app-tier:)
[10-02-10 20:39:24.648] {main} stage = default
[10-02-10 20:39:24.648] {main}
[10-02-10 20:39:24.648] {main} java.io.IOException: Socket JNI is not
available because JNI support has not been compiled.
[10-02-10 20:39:24.648] {main} On Unix, run ./configure; make; make
install. On Windows, check for resin.dll.
[10-02-10 20:39:24.648] {main} java.lang.UnsatisfiedLinkError: no resin_os
in java.library.path
[10-02-10 20:39:24.648] {main} at
com.caucho.vfs.JniServerSocketImpl.checkJni(JniServerSocketImpl.java:121)
[10-02-10 20:39:24.648] {main} at
com.caucho.vfs.JniServerSocketImpl.create(JniServerSocketImpl.java:104)
[10-02-10 20:39:24.648] {main} at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[10-02-10 20:39:24.648] {main} at
Re: [Resin-interest] Where is javax.inject.Current ?
according to the JSR299 JSR330 final spec should use javax.inject.Inject instead 2010/2/7 smallufo small...@gmail.com: I am migrating from Spring to JSR-299 , I followed this http://blog.caucho.com/?p=137 , but the first frustration is that I cannot find @Current . I extracted javaee-16.jar from resin 4.0.2 , but I cannot find that ... I grabbed glassfish v3 but sees no such annotation , Is it deprecated ? ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Where is javax.inject.Current ?
the docs should be updated I can't agree more. :) 2010/2/7 smallufo small...@gmail.com: Oops , thanks for replying so soon. BTW , the docs should be updated ... 2010/2/7 Wesley Wu wumen...@gmail.com according to the JSR299 JSR330 final spec should use javax.inject.Inject instead 2010/2/7 smallufo small...@gmail.com: I am migrating from Spring to JSR-299 , I followed this http://blog.caucho.com/?p=137 , but the first frustration is that I cannot find @Current . I extracted javaee-16.jar from resin 4.0.2 , but I cannot find that ... I grabbed glassfish v3 but sees no such annotation , Is it deprecated ? ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] @ApplicationScoped/@Singleton bean lazy init problem
Hi Scott,
When a @ApplicationScoped/@Singleton bean is designed to be initialized
after webapp starts (I.E. when first http request was fired) instead of being
initialized during startup stage, in given circumstance, it won't be
injected correctly.
This is my test case:
== StartBean ===
public class StartBean {
@Inject
FirstBean firstBean;
}
== FirstBean ===
public class FirstBean {
@Inject
SecondBean secondBean;
}
== SecondBean ===
public class SecondBean {
@Inject
ThirdBean thirdBean;
@Inject
FourthBean fourthBean;
}
== ThirdBean ===
public class ThirdBean {
@Inject
SingletonBean singletonBean;
}
== FourthBean ===
public class FourthBean {
@Inject
SingletonBean dao;
}
== SingletonBean ===
@Singleton
//@Startup
public class SingletonBean {
}
== MyServlet ===
public class MyServlet extends HttpServlet {
@Inject
StartBean startBean;
protected void doGet(HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException {
System.out.println(hello);
}
}
= web.xml ===
?xml version=1.0 encoding=UTF-8?
web-app xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
version=2.5
servlet id=MyServlet
servlet-nameMyServlet/servlet-name
servlet-classcom.mycompany.servlet.MyServlet/servlet-class
/servlet
servlet-mapping
servlet-nameMyServlet/servlet-name
url-pattern/MyServlet/url-pattern
/servlet-mapping
/web-app
=
The http://localhost:8080/MyServlet; request will produce this exception:
com.mycompany.servlet.MyServlet.startBean:
com.mycompany.beans.StartBean.firstBean:
com.mycompany.beans.FirstBean.secondBean:
com.mycompany.beans.SecondBean.fourthBean:
com.mycompany.beans.FourthBean.singletonBean:
java.lang.IllegalArgumentException:
Can not set com.mycompany.beans.SingletonBean field
com.mycompany.beans.FourthBean.singletonBean
to com.mycompany.beans.FourthBean
When I annotate the SingletonBean as @Startup, it's fine. (uncomment
the //@Startup line in SingletonBean.java)
Either @Singleton or @ApplicationScoped throws the exception.
It's a weird bug, taking me nearly two days to reproduce it in such a
simple test case.
-Wesley
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] @ApplicationScoped/@Singleton bean lazy init problem
Thanks for the quick response.
I don't expect a quick resolve of this bug, since it DOES have a workaround.
After some examination of the source code, I think the implementation around
scoped adapter may need a serious refactorying because it's something like
a HACK resolution.
-Wesley
2010/1/29 Scott Ferguson f...@caucho.com:
Wesley Wu wrote:
Hi Scott,
When a @ApplicationScoped/@Singleton bean is designed to be initialized
after webapp starts (I.E. when first http request was fired) instead of being
initialized during startup stage, in given circumstance, it won't be
injected correctly.
Thanks for tracking this down. It looks like a circularity problem,
which we should handle but our current tests don't have exactly this
configuration.
-- Scott
This is my test case:
== StartBean ===
public class StartBean {
@Inject
FirstBean firstBean;
}
== FirstBean ===
public class FirstBean {
@Inject
SecondBean secondBean;
}
== SecondBean ===
public class SecondBean {
@Inject
ThirdBean thirdBean;
@Inject
FourthBean fourthBean;
}
== ThirdBean ===
public class ThirdBean {
@Inject
SingletonBean singletonBean;
}
== FourthBean ===
public class FourthBean {
@Inject
SingletonBean dao;
}
== SingletonBean ===
@Singleton
//@Startup
public class SingletonBean {
}
== MyServlet ===
public class MyServlet extends HttpServlet {
@Inject
StartBean startBean;
protected void doGet(HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException {
System.out.println(hello);
}
}
= web.xml ===
?xml version=1.0 encoding=UTF-8?
web-app xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
version=2.5
servlet id=MyServlet
servlet-nameMyServlet/servlet-name
servlet-classcom.mycompany.servlet.MyServlet/servlet-class
/servlet
servlet-mapping
servlet-nameMyServlet/servlet-name
url-pattern/MyServlet/url-pattern
/servlet-mapping
/web-app
=
The http://localhost:8080/MyServlet; request will produce this exception:
com.mycompany.servlet.MyServlet.startBean:
com.mycompany.beans.StartBean.firstBean:
com.mycompany.beans.FirstBean.secondBean:
com.mycompany.beans.SecondBean.fourthBean:
com.mycompany.beans.FourthBean.singletonBean:
java.lang.IllegalArgumentException:
Can not set com.mycompany.beans.SingletonBean field
com.mycompany.beans.FourthBean.singletonBean
to com.mycompany.beans.FourthBean
When I annotate the SingletonBean as @Startup, it's fine. (uncomment
the //@Startup line in SingletonBean.java)
Either @Singleton or @ApplicationScoped throws the exception.
It's a weird bug, taking me nearly two days to reproduce it in such a
simple test case.
-Wesley
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] the response time
Hi Jon Scott, I don't like apache either but resin 4.0.2 cluster web-tier seems unstable for me. I've not tested the 4.0.3 cluster. My Apache config: ResinHost 192.168.1.4 6801 ResinBackup 192.168.1.5 6801 Which load balancer will be more appropriate for this usage? Thanks. -Wesley ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] HempMemoryQueue consumeQueue NullPointerException
My log output this error:
[09-12-23 04:16:12.154] {hmtp-baa-to-aaa-5}
com.caucho.hemp.broker.HempMemoryQueue consumeQueue
java.lang.NullPointerException
[09-12-23 04:16:12.154] {hmtp-baa-to-aaa-5} at
com.caucho.server.cluster.HmuxQueue.authenticate(HmuxQueue.java:263)
[09-12-23 04:16:12.154] {hmtp-baa-to-aaa-5} at
com.caucho.server.cluster.HmuxQueue.openStream(HmuxQueue.java:191)
[09-12-23 04:16:12.154] {hmtp-baa-to-aaa-5} at
com.caucho.server.cluster.HmuxQueue.dispatch(HmuxQueue.java:110)
[09-12-23 04:16:12.154] {hmtp-baa-to-aaa-5} at
com.caucho.hemp.broker.HempMemoryQueue.consumeQueue(HempMemoryQueue.java:330)
[09-12-23 04:16:12.154] {hmtp-baa-to-aaa-5} at
com.caucho.hemp.broker.HempMemoryQueue.run(HempMemoryQueue.java:388)
[09-12-23 04:16:12.154] {hmtp-baa-to-aaa-5} at
com.caucho.util.ThreadPool$PoolThread.runTasks(ThreadPool.java:901)
[09-12-23 04:16:12.154] {hmtp-baa-to-aaa-5} at
com.caucho.util.ThreadPool$PoolThread.run(ThreadPool.java:866)
[09-12-23 04:16:12.154] {hmtp-baa-to-aaa-5}
[09-12-23 04:16:12.237] {hmtp-baa-to-aaa-4}
com.caucho.hemp.broker.HempMemoryQueue consumeQueue
java.lang.NullPointerException
[09-12-23 04:16:12.237] {hmtp-baa-to-aaa-4} at
com.caucho.server.cluster.HmuxQueue.authenticate(HmuxQueue.java:263)
[09-12-23 04:16:12.237] {hmtp-baa-to-aaa-4} at
com.caucho.server.cluster.HmuxQueue.openStream(HmuxQueue.java:191)
[09-12-23 04:16:12.237] {hmtp-baa-to-aaa-4} at
com.caucho.server.cluster.HmuxQueue.dispatch(HmuxQueue.java:110)
[09-12-23 04:16:12.237] {hmtp-baa-to-aaa-4} at
com.caucho.hemp.broker.HempMemoryQueue.consumeQueue(HempMemoryQueue.java:330)
[09-12-23 04:16:12.237] {hmtp-baa-to-aaa-4} at
com.caucho.hemp.broker.HempMemoryQueue.run(HempMemoryQueue.java:388)
[09-12-23 04:16:12.237] {hmtp-baa-to-aaa-4} at
com.caucho.util.ThreadPool$PoolThread.runTasks(ThreadPool.java:901)
[09-12-23 04:16:12.237] {hmtp-baa-to-aaa-4} at
com.caucho.util.ThreadPool$PoolThread.run(ThreadPool.java:866)
[09-12-23 04:16:12.237] {hmtp-baa-to-aaa-4}
[09-12-23 04:16:12.237] {hmtp-baa-to-aaa-1}
com.caucho.hemp.broker.HempMemoryQueue consumeQueue
java.lang.NullPointerException
[09-12-23 04:16:12.237] {hmtp-baa-to-aaa-1} at
com.caucho.server.cluster.HmuxQueue.authenticate(HmuxQueue.java:263)
[09-12-23 04:16:12.237] {hmtp-baa-to-aaa-1} at
com.caucho.server.cluster.HmuxQueue.openStream(HmuxQueue.java:191)
[09-12-23 04:16:12.237] {hmtp-baa-to-aaa-1} at
com.caucho.server.cluster.HmuxQueue.dispatch(HmuxQueue.java:110)
[09-12-23 04:16:12.237] {hmtp-baa-to-aaa-1} at
com.caucho.hemp.broker.HempMemoryQueue.consumeQueue(HempMemoryQueue.java:330)
[09-12-23 04:16:12.237] {hmtp-baa-to-aaa-1} at
com.caucho.hemp.broker.HempMemoryQueue.run(HempMemoryQueue.java:388)
[09-12-23 04:16:12.237] {hmtp-baa-to-aaa-1} at
com.caucho.util.ThreadPool$PoolThread.runTasks(ThreadPool.java:901)
[09-12-23 04:16:12.237] {hmtp-baa-to-aaa-1} at
com.caucho.util.ThreadPool$PoolThread.run(ThreadPool.java:866)
Resin 4.0.s091222 snapshot
-Wesley
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] HempMemoryQueue Exception when synchronizing sessions between two nodes in a cluster
[09-12-18 01:43:05.221] {hmtp-baa-to-aaa-0}
com.caucho.hemp.broker.HempMemoryQueue consumeQueue
java.lang.IllegalStateException: WebSocket binary must begin with a
0x80 packet at 0x51 (Q)
[09-12-18 01:43:05.221] {hmtp-baa-to-aaa-0} at
com.caucho.hessian.io.Hessian2StreamingInput$StreamingInputStream.readChunkLength(Hessian2StreamingInput.java:216)
[09-12-18 01:43:05.221] {hmtp-baa-to-aaa-0} at
com.caucho.hessian.io.Hessian2StreamingInput$StreamingInputStream.startPacket(Hessian2StreamingInput.java:142)
[09-12-18 01:43:05.221] {hmtp-baa-to-aaa-0} at
com.caucho.hessian.io.Hessian2StreamingInput.startPacket(Hessian2StreamingInput.java:82)
[09-12-18 01:43:05.221] {hmtp-baa-to-aaa-0} at
com.caucho.hmtp.HmtpReader.readPacket(HmtpReader.java:86)
[09-12-18 01:43:05.221] {hmtp-baa-to-aaa-0} at
com.caucho.server.cluster.HmuxQueue.authenticate(HmuxQueue.java:258)
[09-12-18 01:43:05.221] {hmtp-baa-to-aaa-0} at
com.caucho.server.cluster.HmuxQueue.openStream(HmuxQueue.java:190)
[09-12-18 01:43:05.221] {hmtp-baa-to-aaa-0} at
com.caucho.server.cluster.HmuxQueue.dispatch(HmuxQueue.java:110)
[09-12-18 01:43:05.221] {hmtp-baa-to-aaa-0} at
com.caucho.hemp.broker.HempMemoryQueue.consumeQueue(HempMemoryQueue.java:330)
[09-12-18 01:43:05.221] {hmtp-baa-to-aaa-0} at
com.caucho.hemp.broker.HempMemoryQueue.run(HempMemoryQueue.java:388)
[09-12-18 01:43:05.221] {hmtp-baa-to-aaa-0} at
com.caucho.util.ThreadPool$PoolThread.runTasks(ThreadPool.java:901)
[09-12-18 01:43:05.221] {hmtp-baa-to-aaa-0} at
com.caucho.util.ThreadPool$PoolThread.run(ThreadPool.java:866)
[09-12-18 01:43:05.221] {hmtp-baa-to-aaa-0}
[09-12-18 01:43:05.221] {hmtp-baa-to-aaa-1}
com.caucho.hemp.broker.HempMemoryQueue consumeQueue
java.lang.IllegalStateException: WebSocket binary must begin with a
0x80 packet at 0x51 (Q)
[09-12-18 01:43:05.221] {hmtp-baa-to-aaa-1} at
com.caucho.hessian.io.Hessian2StreamingInput$StreamingInputStream.readChunkLength(Hessian2StreamingInput.java:216)
[09-12-18 01:43:05.221] {hmtp-baa-to-aaa-1} at
com.caucho.hessian.io.Hessian2StreamingInput$StreamingInputStream.startPacket(Hessian2StreamingInput.java:142)
[09-12-18 01:43:05.221] {hmtp-baa-to-aaa-1} at
com.caucho.hessian.io.Hessian2StreamingInput.startPacket(Hessian2StreamingInput.java:82)
[09-12-18 01:43:05.221] {hmtp-baa-to-aaa-1} at
com.caucho.hmtp.HmtpReader.readPacket(HmtpReader.java:86)
[09-12-18 01:43:05.221] {hmtp-baa-to-aaa-1} at
com.caucho.server.cluster.HmuxQueue.authenticate(HmuxQueue.java:258)
[09-12-18 01:43:05.221] {hmtp-baa-to-aaa-1} at
com.caucho.server.cluster.HmuxQueue.openStream(HmuxQueue.java:190)
[09-12-18 01:43:05.221] {hmtp-baa-to-aaa-1} at
com.caucho.server.cluster.HmuxQueue.dispatch(HmuxQueue.java:110)
[09-12-18 01:43:05.221] {hmtp-baa-to-aaa-1} at
com.caucho.hemp.broker.HempMemoryQueue.consumeQueue(HempMemoryQueue.java:330)
[09-12-18 01:43:05.221] {hmtp-baa-to-aaa-1} at
com.caucho.hemp.broker.HempMemoryQueue.run(HempMemoryQueue.java:388)
[09-12-18 01:43:05.221] {hmtp-baa-to-aaa-1} at
com.caucho.util.ThreadPool$PoolThread.runTasks(ThreadPool.java:901)
[09-12-18 01:43:05.221] {hmtp-baa-to-aaa-1} at
com.caucho.util.ThreadPool$PoolThread.run(ThreadPool.java:866)
[09-12-18 01:43:05.221] {hmtp-baa-to-aaa-1}
[09-12-18 01:43:35.171] {hmtp-baa-to-aaa-4}
com.caucho.hemp.broker.HempMemoryQueue consumeQueue
java.lang.IllegalStateException: WebSocket binary must begin with a
0x80 packet at 0x51 (Q)
[09-12-18 01:43:35.171] {hmtp-baa-to-aaa-4} at
com.caucho.hessian.io.Hessian2StreamingInput$StreamingInputStream.readChunkLength(Hessian2StreamingInput.java:216)
[09-12-18 01:43:35.171] {hmtp-baa-to-aaa-4} at
com.caucho.hessian.io.Hessian2StreamingInput$StreamingInputStream.startPacket(Hessian2StreamingInput.java:142)
[09-12-18 01:43:35.171] {hmtp-baa-to-aaa-4} at
com.caucho.hessian.io.Hessian2StreamingInput.startPacket(Hessian2StreamingInput.java:82)
[09-12-18 01:43:35.171] {hmtp-baa-to-aaa-4} at
com.caucho.hmtp.HmtpReader.readPacket(HmtpReader.java:86)
[09-12-18 01:43:35.171] {hmtp-baa-to-aaa-4} at
com.caucho.server.cluster.HmuxQueue.authenticate(HmuxQueue.java:258)
[09-12-18 01:43:35.171] {hmtp-baa-to-aaa-4} at
com.caucho.server.cluster.HmuxQueue.openStream(HmuxQueue.java:190)
[09-12-18 01:43:35.171] {hmtp-baa-to-aaa-4} at
com.caucho.server.cluster.HmuxQueue.dispatch(HmuxQueue.java:110)
[09-12-18 01:43:35.171] {hmtp-baa-to-aaa-4} at
com.caucho.hemp.broker.HempMemoryQueue.consumeQueue(HempMemoryQueue.java:330)
[09-12-18 01:43:35.171] {hmtp-baa-to-aaa-4} at
com.caucho.hemp.broker.HempMemoryQueue.run(HempMemoryQueue.java:388)
[09-12-18 01:43:35.171] {hmtp-baa-to-aaa-4} at
com.caucho.util.ThreadPool$PoolThread.runTasks(ThreadPool.java:901)
[09-12-18 01:43:35.171] {hmtp-baa-to-aaa-4} at
com.caucho.util.ThreadPool$PoolThread.run(ThreadPool.java:866)
[09-12-18 01:43:35.171] {hmtp-baa-to-aaa-4}
[09-12-18 01:43:35.171] {hmtp-baa-to-aaa-3}
Re: [Resin-interest] HempMemoryQueue Exception when synchronizing sessions between two nodes in a cluster
this node is using Resin-4.0.s091216 the other is using Resin-4.0.s091202 -Wesley ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] HempMemoryQueue Exception when synchronizing sessions between two nodes in a cluster
Thanks. I switched back to 091202 snapshot and this issue was resolved. Would u take some time to look at my other mail about @ApplicationScoped bean distribution? -Wesley 2009/12/18 Scott Ferguson f...@caucho.com: Wesley Wu wrote: this node is using Resin-4.0.s091216 the other is using Resin-4.0.s091202 The exception itself is a known issue that's blocking 4.0.3, but you also can't mix those two versions. We needed to change the cluster protocol to handle our upcoming EC2 support, and those two snapshots are basically a before-and-after of the change. -- Scott -Wesley ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] HempMemoryQueue Exception when synchronizing sessions between two nodes in a cluster
So if I want my beans synchronized across the cluster, I have to use either JMS or some thirdparty cluster middleware like JBossCache? -Wesley ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] HempMemoryQueue Exception when synchronizing sessions between two nodes in a cluster
thanks Jon Jeff, lol, I'll take a serious look at ehcache + terracotta. I've used JBossCache for more than 2 years, but only on single JVM (not clustered). I might think the clustered cache should be working as they advertised. -Wesley 2009/12/18 Jeff Schnitzer j...@infohazard.org: I know that Jon has spent many, many days debugging and tuning JBoss Cache on a production cluster, so I'd endorse his review, despite the brashness. Jeff On Thu, Dec 17, 2009 at 3:37 PM, Jon Stevens latch...@gmail.com wrote: DO NOT USE JBOSS CACHE. Pile of shit. ehcache + terracotta (yes, there is an oss free version) = love. I'm not super clear on what you want, but it sounds like you want the TIM-MasterWorker (ExecutorService): http://forge.terracotta.org/releases/projects/tim-messaging/docs/about.html jon On Thu, Dec 17, 2009 at 11:51 AM, Wesley Wu wumen...@gmail.com wrote: So if I want my beans synchronized across the cluster, I have to use either JMS or some thirdparty cluster middleware like JBossCache? -Wesley ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] HempMemoryQueue Exception when synchronizing sessions between two nodes in a cluster
Thanks Jon, I'll definitely give terracotta a try. As far as I know, EHCache was a opensymphony project one or two years ago. I noticed that ehcache was acquired by terracotta and became a key component of terracotta. That's great! -Wesley ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] To make @ApplicationScoped Bean distributed
Hi Scott,
I'm deploying Resin 4.0.2 snapshot to a cluster and found my
@ApplicationScoped bean not distributed across the cluster nodes.
Is there anything to config to make it possible?
I searched Gavin's blog and found some examples regarding @Observes to
resolve this situation.
If I dispatch events to my @ApplicationScoped bean, instead of call
its methods directly, could I make the data synchronized across the
cluster?
like this:
= original implementation ===
@ApplicationScoped
public class MyAppScopedBean implements Serializable {
private MapInteger, MyModel models;
public void addModel(MyModel model) {
models.put(model.getId(), model);
}
}
public class MyController {
@Inject
MyAppScopedBean appScopedBean;
public void execute() {
appScopedBean.addModel(model);
}
}
this implementation was not distributable.
= proposed implementation ===
@ApplicationScoped
public class MyAppScopedBean implements Serializable {
private MapInteger, MyModel models;
public void addModel(@Observes @MyEventAnno MyEvent event) {
MyModel model = event.getModel();
models.put(model.getId(), model);
}
}
public class MyController {
public void execute() {
beanManager.fireEvent(new MyEvent(model), ... );
}
}
should this event be distributated to all MyAppScopedBean instances in
cluster nodes?
-Wesley
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] new Resin 4.0 snapshot
-1}
com.caucho.server.http.HttpRequest parseHeaders Http[1] Content-Type:
application/x-www-form-urlencoded
[09-12-03 06:00:43.500] {http--8080-1}
com.caucho.server.http.HttpRequest parseHeaders Http[1] Accept:
application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
[09-12-03 06:00:43.500] {http--8080-1}
com.caucho.server.http.HttpRequest parseHeaders Http[1]
Accept-Encoding: gzip,deflate,sdch
[09-12-03 06:00:43.500] {http--8080-1}
com.caucho.server.http.HttpRequest parseHeaders Http[1] Cookie:
userId=bbbeaa; managedFid=a; niceName=%u536B%u65AF%u7406; rtime=3;
ltime=1259611848411; cnzz_eid=15263584-1258525777-;
JSESSIONID=aaaYdu83foOsrfeQW7qvs
[09-12-03 06:00:43.513] {http--8080-1}
com.caucho.server.http.HttpRequest parseHeaders Http[1]
Accept-Language: zh-CN,zh;q=0.8
[09-12-03 06:00:43.513] {http--8080-1}
com.caucho.server.http.HttpRequest parseHeaders Http[1]
Accept-Charset: gb18030,utf-8;q=0.7,*;q=0.3
2009/12/3 Scott Ferguson f...@caucho.com:
Wesley Wu wrote:
Another SEVERE issues with this snapshot.
All POST request was dramatically CHANGED to GET request.
I'm not seeing that behavior. Can you turn on the finer logging and see
what filters/includes/forwards are happening?
-- Scott
-Wesley
2009/12/3 Scott Ferguson f...@caucho.com:
Jamison Novak wrote:
You can ignore this. After further investigation, the developer in charge
of the app says that it's returning a similar error under Tomcat, which he
claims it was not before. There must be something else going on.
Thanks for the update. The tests I added for the most recent changes
should have covered large-file posts as well, but there's always a
chance some case was missing.
Thanks for the snapshot, though. Shiny new toys are always fun...
Yep. We did some important refactoring for 4.0.2 that had been put off
for ages, but unfortunately exposed holes in the QA tests. (Of course,
now we have the new tests, so there's a silver lining.)
-- Scott
-Original Message-
From: resin-interest-boun...@caucho.com
[mailto:resin-interest-boun...@caucho.com] On Behalf Of Jamison Novak
Sent: Wednesday, December 02, 2009 2:16 PM
To: General Discussion for the Resin application server
Subject: Re: [Resin-interest] new Resin 4.0 snapshot
Thanks, Scott. The snapshot doesn't seem to have fixed the related error
that we were seeing with one of our apps.
If we submit a form with a long list of files in a text box, we get the
same error according to Grails (I don't see anything special in Resin's
finer logging, though). If the list of files in the field is shortened,
we get no error. Could this be a related POST size error?
We're trying to troubleshoot the app itself on our end, but there's not
much in the logs to go by.
Thanks,
Jamie
-Original Message-
From: resin-interest-boun...@caucho.com
[mailto:resin-interest-boun...@caucho.com] On Behalf Of Scott Ferguson
Sent: Wednesday, December 02, 2009 1:08 PM
To: resin-interest@caucho.com
Subject: [Resin-interest] new Resin 4.0 snapshot
There's a new Resin 4.0 snapshot with additional fixes for the
hmux/forwarding issues.
-- Scott
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] new Resin 4.0 snapshot
I think the win32/win64 dlls should be recompiled against the new modification.
2009/12/3 Wesley Wu wumen...@gmail.com:
I wonder why this happened.
I encountered this in all 4.0.2 versions in my developer machine while
not occurred in production machine.
I'll do some investigation next.
Thanks Scoot.
2009/12/3 Wesley Wu wumen...@gmail.com:
I turned it on:
[09-12-03 05:59:44.722] {server--6800-4}
com.caucho.server.hmux.HmuxRequest handleRequestImpl Hmux[4] start
request
[09-12-03 05:59:44.722] {server--6800-4}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[4] r: end of file
[09-12-03 05:59:44.723] {server--6800-4}
com.caucho.server.connection.ResponseStream finish Hmux[4] close
stream
[09-12-03 05:59:44.723] {server--6800-4}
com.caucho.server.hmux.HmuxResponseStream flushNext Hmux[4] flush()
[09-12-03 05:59:44.729] {server--6800-1}
com.caucho.server.hmux.HmuxRequest handleRequestImpl Hmux[1] start
request
[09-12-03 05:59:44.729] {server--6800-1}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[1] r: end of file
[09-12-03 05:59:44.730] {server--6800-1}
com.caucho.server.connection.ResponseStream finish Hmux[1] close
stream
[09-12-03 05:59:44.730] {server--6800-1}
com.caucho.server.hmux.HmuxResponseStream flushNext Hmux[1] flush()
[09-12-03 05:59:44.738] {server--6800-3}
com.caucho.server.hmux.HmuxRequest handleRequestImpl Hmux[3] start
request
[09-12-03 05:59:44.738] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] channel-r 1
[09-12-03 05:59:44.738] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] U:uri
/register/
[09-12-03 05:59:44.738] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] m:method GET
[09-12-03 05:59:44.739] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] c protocol:
HTTP/1.1
[09-12-03 05:59:44.739] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] v server-host:
localhost
[09-12-03 05:59:44.739] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] g server-port:
889
[09-12-03 05:59:44.739] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] h 127.0.0.1
[09-12-03 05:59:44.739] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] i 127.0.0.1
[09-12-03 05:59:44.740] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] j remote-port:
40942
[09-12-03 05:59:44.740] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] H
Host=localhost:889
[09-12-03 05:59:44.740] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] H
Connection=keep-alive
[09-12-03 05:59:44.740] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] H
User-Agent=Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US)
AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.33 Safari/532.0
[09-12-03 05:59:44.741] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] H
Referer=http://localhost:889/register/
[09-12-03 05:59:44.741] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] H
Cache-Control=max-age=0
[09-12-03 05:59:44.741] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] H
Accept=application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
[09-12-03 05:59:44.741] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] H
Accept-Encoding=gzip,deflate,sdch
[09-12-03 05:59:44.742] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] H
Cookie=userId=bbbeaa; managedFid=a; niceName=%u536B%u65AF%u7406;
rtime=3; ltime=1259611848411; cnzz_eid=15263584-1258525777-;
JSESSIONID=aaaYdu83foOsrfeQW7qvs
[09-12-03 05:59:44.742] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] H
Accept-Language=zh-CN,zh;q=0.8
[09-12-03 05:59:44.742] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] H
Accept-Charset=gb18030,utf-8;q=0.7,*;q=0.3
[09-12-03 05:59:44.743] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] Q-r: end of
request
If I use 8080 port I saw:
[09-12-03 06:00:43.498] {http--8080-1}
com.caucho.server.http.HttpRequest parseRequest Http[1] POST /register
HTTP/1.1
[09-12-03 06:00:43.498] {http--8080-1}
com.caucho.server.http.HttpRequest parseRequest Http[1] Remote-IP:
127.0.0.1:61096
[09-12-03 06:00:43.498] {http--8080-1}
com.caucho.server.http.HttpRequest parseHeaders Http[1] Host:
localhost:8080
[09-12-03 06:00:43.498] {http--8080-1}
com.caucho.server.http.HttpRequest parseHeaders Http[1] Connection:
keep-alive
[09-12-03 06:00:43.499] {http--8080-1}
com.caucho.server.http.HttpRequest parseHeaders Http[1] User-Agent:
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/532.0
(KHTML, like Gecko) Chrome/3.0.195.33 Safari/532.0
[09-12-03 06:00:43.499] {http--8080-1}
com.caucho.server.http.HttpRequest
Re: [Resin-interest] new Resin 4.0 snapshot
I changed my post url to /register1 instead or /register and the
post request was handled properly.
So I think a request to the url /register will be always treated as GET?
I scanned the apache log, and the post request was logged correct:
localhost 127.0.0.1 - - [03/Dec/2009:08:18:21 +0800] POST /register
HTTP/1.1 301 346 http://localhost:889/register/; Mozilla/5.0
(Windows; U; Windows NT 6.0; zh-CN; rv:1.9.1.5) Gecko/20091102
Firefox/3.5.5 GTB6 (.NET CLR 3.5.30729) 1000
localhost 127.0.0.1 - - [03/Dec/2009:08:18:21 +0800] GET /register/
HTTP/1.1 200 9174 http://localhost:889/register/; Mozilla/5.0
(Windows; U; Windows NT 6.0; zh-CN; rv:1.9.1.5) Gecko/20091102
Firefox/3.5.5 GTB6 (.NET CLR 3.5.30729) 77000
But when I looked into resin's access log, I was shocked.
I found no access log item in it, only the subsequent redirected items:
127.0.0.1 - - [03/Dec/2009:08:18:21 +0800] GET /register/ HTTP/1.1
200 8707 http://localhost:889/register/; Mozilla/5.0 (Windows; U;
Windows NT 6.0; zh-CN; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 GTB6
(.NET CLR 3.5.30729)
127.0.0.1 - - [03/Dec/2009:08:18:21 +0800] GET /css/common.css
HTTP/1.1 304 - http://localhost:889/register/; Mozilla/5.0
(Windows; U; Windows NT 6.0; zh-CN; rv:1.9.1.5) Gecko/20091102
Firefox/3.5.5 GTB6 (.NET CLR 3.5.30729)
127.0.0.1 - - [03/Dec/2009:08:18:21 +0800] GET /js/humanmessage.js
HTTP/1.1 304 - http://localhost:889/register/; Mozilla/5.0
(Windows; U; Windows NT 6.0; zh-CN; rv:1.9.1.5) Gecko/20091102
Firefox/3.5.5 GTB6 (.NET CLR 3.5.30729)
127.0.0.1 - - [03/Dec/2009:08:18:21 +0800] GET /css/style05.css
HTTP/1.1 304 - http://localhost:889/register/; Mozilla/5.0
(Windows; U; Windows NT 6.0; zh-CN; rv:1.9.1.5) Gecko/20091102
Firefox/3.5.5 GTB6 (.NET CLR 3.5.30729)
-Wesley
2009/12/3 Wesley Wu wumen...@gmail.com:
I think the win32/win64 dlls should be recompiled against the new
modification.
2009/12/3 Wesley Wu wumen...@gmail.com:
I wonder why this happened.
I encountered this in all 4.0.2 versions in my developer machine while
not occurred in production machine.
I'll do some investigation next.
Thanks Scoot.
2009/12/3 Wesley Wu wumen...@gmail.com:
I turned it on:
[09-12-03 05:59:44.722] {server--6800-4}
com.caucho.server.hmux.HmuxRequest handleRequestImpl Hmux[4] start
request
[09-12-03 05:59:44.722] {server--6800-4}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[4] r: end of file
[09-12-03 05:59:44.723] {server--6800-4}
com.caucho.server.connection.ResponseStream finish Hmux[4] close
stream
[09-12-03 05:59:44.723] {server--6800-4}
com.caucho.server.hmux.HmuxResponseStream flushNext Hmux[4] flush()
[09-12-03 05:59:44.729] {server--6800-1}
com.caucho.server.hmux.HmuxRequest handleRequestImpl Hmux[1] start
request
[09-12-03 05:59:44.729] {server--6800-1}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[1] r: end of file
[09-12-03 05:59:44.730] {server--6800-1}
com.caucho.server.connection.ResponseStream finish Hmux[1] close
stream
[09-12-03 05:59:44.730] {server--6800-1}
com.caucho.server.hmux.HmuxResponseStream flushNext Hmux[1] flush()
[09-12-03 05:59:44.738] {server--6800-3}
com.caucho.server.hmux.HmuxRequest handleRequestImpl Hmux[3] start
request
[09-12-03 05:59:44.738] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] channel-r 1
[09-12-03 05:59:44.738] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] U:uri
/register/
[09-12-03 05:59:44.738] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] m:method GET
[09-12-03 05:59:44.739] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] c protocol:
HTTP/1.1
[09-12-03 05:59:44.739] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] v server-host:
localhost
[09-12-03 05:59:44.739] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] g server-port:
889
[09-12-03 05:59:44.739] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] h 127.0.0.1
[09-12-03 05:59:44.739] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] i 127.0.0.1
[09-12-03 05:59:44.740] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] j remote-port:
40942
[09-12-03 05:59:44.740] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] H
Host=localhost:889
[09-12-03 05:59:44.740] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] H
Connection=keep-alive
[09-12-03 05:59:44.740] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] H
User-Agent=Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US)
AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.33 Safari/532.0
[09-12-03 05:59:44.741] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] H
Referer=http://localhost:889/register/
[09-12-03 05:59:44.741] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] H
Cache-Control=max-age=0
[09
Re: [Resin-interest] new Resin 4.0 snapshot
that GET was the subsequent redirect after the POST.
I use redirect after post pattern.
A request first POST to /register and after some processing,
redirect to /register again using a GET request.
-Wesley
2009/12/3 Scott Ferguson f...@caucho.com:
Wesley Wu wrote:
I changed my post url to /register1 instead or /register and the
post request was handled properly.
So I think a request to the url /register will be always treated as GET?
Resin doesn't have any special URL like /register (except the servlet
j_*). Is there something in the Apache end which is redirecting, or
changing it, like a filter?
From the log you sent earlier, it was the front end (Apache) that's
sending the GET. (There's a log entry for the HTTP method parsing.)
-- Scott
I scanned the apache log, and the post request was logged correct:
localhost 127.0.0.1 - - [03/Dec/2009:08:18:21 +0800] POST /register
HTTP/1.1 301 346 http://localhost:889/register/; Mozilla/5.0
(Windows; U; Windows NT 6.0; zh-CN; rv:1.9.1.5) Gecko/20091102
Firefox/3.5.5 GTB6 (.NET CLR 3.5.30729) 1000
localhost 127.0.0.1 - - [03/Dec/2009:08:18:21 +0800] GET /register/
HTTP/1.1 200 9174 http://localhost:889/register/; Mozilla/5.0
(Windows; U; Windows NT 6.0; zh-CN; rv:1.9.1.5) Gecko/20091102
Firefox/3.5.5 GTB6 (.NET CLR 3.5.30729) 77000
But when I looked into resin's access log, I was shocked.
I found no access log item in it, only the subsequent redirected items:
127.0.0.1 - - [03/Dec/2009:08:18:21 +0800] GET /register/ HTTP/1.1
200 8707 http://localhost:889/register/; Mozilla/5.0 (Windows; U;
Windows NT 6.0; zh-CN; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 GTB6
(.NET CLR 3.5.30729)
127.0.0.1 - - [03/Dec/2009:08:18:21 +0800] GET /css/common.css
HTTP/1.1 304 - http://localhost:889/register/; Mozilla/5.0
(Windows; U; Windows NT 6.0; zh-CN; rv:1.9.1.5) Gecko/20091102
Firefox/3.5.5 GTB6 (.NET CLR 3.5.30729)
127.0.0.1 - - [03/Dec/2009:08:18:21 +0800] GET /js/humanmessage.js
HTTP/1.1 304 - http://localhost:889/register/; Mozilla/5.0
(Windows; U; Windows NT 6.0; zh-CN; rv:1.9.1.5) Gecko/20091102
Firefox/3.5.5 GTB6 (.NET CLR 3.5.30729)
127.0.0.1 - - [03/Dec/2009:08:18:21 +0800] GET /css/style05.css
HTTP/1.1 304 - http://localhost:889/register/; Mozilla/5.0
(Windows; U; Windows NT 6.0; zh-CN; rv:1.9.1.5) Gecko/20091102
Firefox/3.5.5 GTB6 (.NET CLR 3.5.30729)
-Wesley
2009/12/3 Wesley Wu wumen...@gmail.com:
I think the win32/win64 dlls should be recompiled against the new
modification.
2009/12/3 Wesley Wu wumen...@gmail.com:
I wonder why this happened.
I encountered this in all 4.0.2 versions in my developer machine while
not occurred in production machine.
I'll do some investigation next.
Thanks Scoot.
2009/12/3 Wesley Wu wumen...@gmail.com:
I turned it on:
[09-12-03 05:59:44.722] {server--6800-4}
com.caucho.server.hmux.HmuxRequest handleRequestImpl Hmux[4] start
request
[09-12-03 05:59:44.722] {server--6800-4}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[4] r: end of file
[09-12-03 05:59:44.723] {server--6800-4}
com.caucho.server.connection.ResponseStream finish Hmux[4] close
stream
[09-12-03 05:59:44.723] {server--6800-4}
com.caucho.server.hmux.HmuxResponseStream flushNext Hmux[4] flush()
[09-12-03 05:59:44.729] {server--6800-1}
com.caucho.server.hmux.HmuxRequest handleRequestImpl Hmux[1] start
request
[09-12-03 05:59:44.729] {server--6800-1}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[1] r: end of file
[09-12-03 05:59:44.730] {server--6800-1}
com.caucho.server.connection.ResponseStream finish Hmux[1] close
stream
[09-12-03 05:59:44.730] {server--6800-1}
com.caucho.server.hmux.HmuxResponseStream flushNext Hmux[1] flush()
[09-12-03 05:59:44.738] {server--6800-3}
com.caucho.server.hmux.HmuxRequest handleRequestImpl Hmux[3] start
request
[09-12-03 05:59:44.738] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] channel-r 1
[09-12-03 05:59:44.738] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] U:uri
/register/
[09-12-03 05:59:44.738] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] m:method GET
[09-12-03 05:59:44.739] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] c protocol:
HTTP/1.1
[09-12-03 05:59:44.739] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] v server-host:
localhost
[09-12-03 05:59:44.739] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] g server-port:
889
[09-12-03 05:59:44.739] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] h 127.0.0.1
[09-12-03 05:59:44.739] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] i 127.0.0.1
[09-12-03 05:59:44.740] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] j remote-port:
40942
[09-12-03 05:59:44.740] {server--6800-3}
com.caucho.server.hmux.HmuxRequest scanHeaders Hmux[3] H
Host=localhost
Re: [Resin-interest] Multi-Part request error when using HmuxRequest in Resin 4.0.2(GA)
Without this bug fixed, 4.0.2 can't be used in production environment. I use two machines with two resin as a load balance cluster, one with a web-tier and a app-tier the other only a app-tier. Every file upload block it. 2009/11/30 Wesley Wu wumen...@gmail.com This bug should be marked as block because it prevents resin load-balancer and third-party web server integration from working properly. It seems caucho QA team did not pay much attention to Hmux stuff, because I suffered a lot from it... -Wesley 2009/11/29 Alex a...@caucho.com Multi-Part request error when using HmuxRequest. Thanks Wesley, I reported a bug: http://bugs.caucho.com/view.php?id=3790 Alex My resin 4.0.2 was behind an apache 2.1.x using CauchoRequest to forward all request for a virtual host to resin. If I use 8080 port without apache, everything goes fine. 2009-11-28 13:14:28.916 ERROR [server-127.0.0.1:6800-5] c.b.c.s.MultiPartRequest (103) - Unable to parse request org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Stream ended unexpectedly at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:367) [FileUploadBase.class:1.2.1] at com.buysou.cms.servlet.JakartaMultiPartRequest.parse(JakartaMultiPartRequest.java:61) [classes:na] at com.buysou.cms.servlet.MultiPartRequestWrapper.init(MultiPartRequestWrapper.java:47) [classes:na] at com.buysou.cms.servlet.CmsPageFilter.wrapRequest(CmsPageFilter.java:268) [classes:na] at com.buysou.cms.servlet.CmsPageFilter.doFilter(CmsPageFilter.java:138) [classes:na] at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:88) [resin.jar:4.0.2] at com.buysou.servlet.filters.encoding.EnhancedEncodingFilter.doFilter(EnhancedEncodingFilter.java:85) [classes:na] at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:88) [resin.jar:4.0.2] at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:183) [resin.jar:4.0.2] at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:169) [pro.jar:4.0.2] at com.caucho.server.webapp.AccessLogFilterChain.doFilter(AccessLogFilterChain.java:103) [resin.jar:4.0.2] at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:290) [resin.jar:4.0.2] at com.caucho.server.hmux.HmuxRequest.handleInvocation(HmuxRequest.java:475) [resin.jar:4.0.2] at com.caucho.server.hmux.HmuxRequest.handleRequestImpl(HmuxRequest.java:394) [resin.jar:4.0.2] at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:357) [resin.jar:4.0.2] at com.caucho.server.port.TcpConnection.handleRequestsImpl(TcpConnection.java:619) [resin.jar:4.0.2] at com.caucho.server.port.TcpConnection.handleRequests(TcpConnection.java:556) [resin.jar:4.0.2] at com.caucho.server.port.TcpConnection$AcceptTask.doTask(TcpConnection.java:1194) [resin.jar:4.0.2] at com.caucho.server.port.TcpConnection$ConnectionReadTask.runThread(TcpConnection.java:1127) [resin.jar:4.0.2] at com.caucho.server.port.TcpConnection$AcceptTask.run(TcpConnection.java:1158) [resin.jar:4.0.2] at com.caucho.util.ThreadPool$PoolThread.runTasks(ThreadPool.java:901) [resin.jar:4.0.2] at com.caucho.util.ThreadPool$PoolThread.run(ThreadPool.java:866) [resin.jar:4.0.2] Caused by: org.apache.commons.fileupload.MultipartStream$MalformedStreamException: Stream ended unexpectedly at org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:983) [MultipartStream$ItemInputStream.class:1.2.1] at org.apache.commons.fileupload.MultipartStream$ItemInputStream.read(MultipartStream.java:887) [MultipartStream$ItemInputStream.class:1.2.1] at java.io.InputStream.read(InputStream.java:85) [na:1.6.0_14] at org.apache.commons.fileupload.util.Streams.copy(Streams.java:94) [Streams.class:1.2.1] at org.apache.commons.fileupload.util.Streams.copy(Streams.java:64) [Streams.class:1.2.1] at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:362) [FileUploadBase.class:1.2.1] ... 21 common frames omitted ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Multi-Part request error when using HmuxRequest in Resin 4.0.2(GA)
Thanks, Scott. You rocks. We're planning a launch of a new version of my website on December 18. All codes in this new version rely on JSR 299 (hopefully I'll see the final ballot today). So it's a bit emergency for me to solve this problem. I'll be happy if 4.0.3 will be ready by then, but a snapshot with fixes will be ok. Or I'll have to switch back to the 4.0.2 snapshot 091013 (which has performance/logging issue and JPA issues). 2009/12/1 Scott Ferguson f...@caucho.com: Scott Ferguson wrote: Wesley Wu wrote: Without this bug fixed, 4.0.2 can't be used in production environment. I use two machines with two resin as a load balance cluster, one with a web-tier and a app-tier the other only a app-tier. Can you turn on finer logging for both machines and send the protocol part of the logs? I can't reproduce the issue here; posts are going through fine. So there must be some difference in the request or the reading that's triggering the problem. Nevermind. I found it. -- Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Multi-Part request error when using HmuxRequest in Resin 4.0.2(GA)
This bug should be marked as block because it prevents resin load-balancer and third-party web server integration from working properly. It seems caucho QA team did not pay much attention to Hmux stuff, because I suffered a lot from it... -Wesley 2009/11/29 Alex a...@caucho.com Multi-Part request error when using HmuxRequest. Thanks Wesley, I reported a bug: http://bugs.caucho.com/view.php?id=3790 Alex My resin 4.0.2 was behind an apache 2.1.x using CauchoRequest to forward all request for a virtual host to resin. If I use 8080 port without apache, everything goes fine. 2009-11-28 13:14:28.916 ERROR [server-127.0.0.1:6800-5] c.b.c.s.MultiPartRequest (103) - Unable to parse request org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Stream ended unexpectedly at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:367) [FileUploadBase.class:1.2.1] at com.buysou.cms.servlet.JakartaMultiPartRequest.parse(JakartaMultiPartRequest.java:61) [classes:na] at com.buysou.cms.servlet.MultiPartRequestWrapper.init(MultiPartRequestWrapper.java:47) [classes:na] at com.buysou.cms.servlet.CmsPageFilter.wrapRequest(CmsPageFilter.java:268) [classes:na] at com.buysou.cms.servlet.CmsPageFilter.doFilter(CmsPageFilter.java:138) [classes:na] at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:88) [resin.jar:4.0.2] at com.buysou.servlet.filters.encoding.EnhancedEncodingFilter.doFilter(EnhancedEncodingFilter.java:85) [classes:na] at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:88) [resin.jar:4.0.2] at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:183) [resin.jar:4.0.2] at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:169) [pro.jar:4.0.2] at com.caucho.server.webapp.AccessLogFilterChain.doFilter(AccessLogFilterChain.java:103) [resin.jar:4.0.2] at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:290) [resin.jar:4.0.2] at com.caucho.server.hmux.HmuxRequest.handleInvocation(HmuxRequest.java:475) [resin.jar:4.0.2] at com.caucho.server.hmux.HmuxRequest.handleRequestImpl(HmuxRequest.java:394) [resin.jar:4.0.2] at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:357) [resin.jar:4.0.2] at com.caucho.server.port.TcpConnection.handleRequestsImpl(TcpConnection.java:619) [resin.jar:4.0.2] at com.caucho.server.port.TcpConnection.handleRequests(TcpConnection.java:556) [resin.jar:4.0.2] at com.caucho.server.port.TcpConnection$AcceptTask.doTask(TcpConnection.java:1194) [resin.jar:4.0.2] at com.caucho.server.port.TcpConnection$ConnectionReadTask.runThread(TcpConnection.java:1127) [resin.jar:4.0.2] at com.caucho.server.port.TcpConnection$AcceptTask.run(TcpConnection.java:1158) [resin.jar:4.0.2] at com.caucho.util.ThreadPool$PoolThread.runTasks(ThreadPool.java:901) [resin.jar:4.0.2] at com.caucho.util.ThreadPool$PoolThread.run(ThreadPool.java:866) [resin.jar:4.0.2] Caused by: org.apache.commons.fileupload.MultipartStream$MalformedStreamException: Stream ended unexpectedly at org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:983) [MultipartStream$ItemInputStream.class:1.2.1] at org.apache.commons.fileupload.MultipartStream$ItemInputStream.read(MultipartStream.java:887) [MultipartStream$ItemInputStream.class:1.2.1] at java.io.InputStream.read(InputStream.java:85) [na:1.6.0_14] at org.apache.commons.fileupload.util.Streams.copy(Streams.java:94) [Streams.class:1.2.1] at org.apache.commons.fileupload.util.Streams.copy(Streams.java:64) [Streams.class:1.2.1] at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:362) [FileUploadBase.class:1.2.1] ... 21 common frames omitted ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin V Glassfish
Yes, congratulations to Gavin King. Competition is a good thing. I think Scott will produce products with less bugs or we'll change to Weld :) 2009/11/28 Kai Virkki kai.vir...@gmail.com Well, JBoss already has a CDI implementation called Weld, so Resin really isn't exceptional in this account. CDI is actually based on JBoss Seam and Google Guice. Cheers, -Kai On 27.11.2009, at 12.10, Wesley Wu wumen...@gmail.com wrote: As long as Scott continue to work for the Resin's future I'll never switch to other platform. I loved the WebBeans so much from December 2007, now called CDI. I don't think other vendors could produce a competitive implementation of CDI versus Resin, in at least next 12 months. They have to throw in lots of labor and money to keep up with the more than two years hard work of Scott and his stuff. The forthcoming failure of OpenJPA is an example, which can nowhere compete with Hibernate EclipseLink in every aspect. -Wesley ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] change log page broken
http://www.caucho.com/resin/changes/changes.xtp [show] javascript:show(); /var/www/hosts/www.caucho.com/webapps/resin/changes/changes.xtp:116: expected name at ` ' 114: liquercus: Drupal and OpenID (#3609, rep by B. Wu)/li 115: liquercus: QuercusParseException - missing semicolon within a scriptlet php tag. (#3668, rep by kenfoo)/li 116: liquercus: StringBuilderValue.create() is not performing a 0xFF on the character value (#3654, rep by kenfoo)/li 117: liquercus: ErrorException is missing (#3667, rep by kenfoo)/li 118: liquercus: substr_compare failed (#3662, rep by jindw)/li ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] url rewriting / search engine friendly
My filter handle the rewrite and parameter parsing, and dispatch to according controller/action with a wrapped http request. 1. user hit the url: /user/1354 2. filter knows that user request the UserController/UserServlet/UserAction/view-user.jsp with a param value 1354 (corresponding param should be the first pre-configed param, which should be id) 3. the filter wrap the http request to add param name/value pair (id=1354) 4. (optional) call your Controller/Action for additional processing using the wrapped request(probably a wrapped response for gzip/caching purpose) 5. dispatch to /UserServlet or /view-user.jsp using the wrapped request(probably a wrapped response for gzip/caching purpose) 2009/10/31 d.lo...@uib.es And why is it that a servlet filter is outside the application? I consider it to be part of the application; it is simply a matter that those services are not provided directly by the framework used to implement the logic. Otherwise each framework would have to provide that capability. I have seen both approaches (Cocoon uses the later approach) and both have their strong/weak points. In any case, I don't think there's a good answer and a bad one. S! D. S'està citant Riccardo Cohen r...@architectedulogiciel.fr: I understand your point of view : separate url management and application logic. It seems a good practice. In the same time this probably comes from the idea that search engine friendly urls are added to the application, which basically does not need it. On one hand it is true. The url /user/name is an alias of /servlet?command=showuserid=1354 in a functionnal point of view. On the other hand, you may think of the SEF url as a request by itself, and the controller is in charge of handling requests, of any syntax. So if my controller parses the url /servlet?command=showuserid=1354, why couldn't it parse the url /user/name instead directly ? This removes from the application one level of control and complexity . Am-I right ? Wesley Wu wrote: Not recommended. I think filter should handle this, which is not relative to business logic. 2009/10/30 Riccardo Cohen r...@architectedulogiciel.fr mailto:r...@architectedulogiciel.fr Thanks Wesley I'll try to use filter. Now in term of performance, isn't it better to integrate the url processing directly into the controller servlet ? Wesley Wu wrote: You may use http://tuckey.org/urlrewrite/ UrlRewriteFilter. I wrote a similar filter doing the same thing which loads rewrite config from database. 2009/10/30 Riccardo Cohen r...@architectedulogiciel.fr mailto:r...@architectedulogiciel.fr mailto:r...@architectedulogiciel.fr mailto:r...@architectedulogiciel.fr Hello I didn't have yet the opportunity to work with search engine friendly urls with resin (I did it with apache/php). I suppose that there must be a set of servlet-mapping and rewrite-dispatch in conf and some url-dedicated servlets in the application. I wonder if there is any kind of good practice with resin configuration to build SEF web sites. In the wiki I found rewrite rules for php CMS, but not for java apps. (I use resin 3,2,0) Thanks a lot. -- Riccardo Cohen Architecte du Logiciel http://www.architectedulogiciel.fr +33 (0)6.09.83.64.49 Membre du réseau http://www.reflexe-conseil-centre.org ___ resin-interest mailing list resin-interest@caucho.com mailto:resin-interest@caucho.com mailto:resin-interest@caucho.com mailto:resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com mailto:resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest -- Riccardo Cohen Architecte du Logiciel http://www.architectedulogiciel.fr +33 (0)6.09.83.64.49 Membre du réseau http://www.reflexe-conseil-centre.org ___ resin-interest mailing list resin-interest@caucho.com mailto:resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http
Re: [Resin-interest] url rewriting / search engine friendly
You may use http://tuckey.org/urlrewrite/ UrlRewriteFilter. I wrote a similar filter doing the same thing which loads rewrite config from database. 2009/10/30 Riccardo Cohen r...@architectedulogiciel.fr Hello I didn't have yet the opportunity to work with search engine friendly urls with resin (I did it with apache/php). I suppose that there must be a set of servlet-mapping and rewrite-dispatch in conf and some url-dedicated servlets in the application. I wonder if there is any kind of good practice with resin configuration to build SEF web sites. In the wiki I found rewrite rules for php CMS, but not for java apps. (I use resin 3,2,0) Thanks a lot. -- Riccardo Cohen Architecte du Logiciel http://www.architectedulogiciel.fr +33 (0)6.09.83.64.49 Membre du réseau http://www.reflexe-conseil-centre.org ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] LazyEntityManagerFactory is initialized too late to be injected into scheduled tasks
Hi Scott,
I got two new problems.
I have a scheduled task need to inject a @PersistenceUnit, as the config
below:
resin:ScheduledTask xmlns:tasks=urn:java:com.timehr.tasks
resin:cron0 2 */resin:cron
resin:task
tasks:PositionRefreshTask/
/resin:task
/resin:ScheduledTask
I turned log level to finer, and found Resin tried to initialize my task
before creating the persistence unit.
But my task need the persistence unit to be injected in it!
As long as I commented the task config lines out, my app run smoothly with
Resin showing these log lines before initialization of any my classes/beans:
[09-10-20 11:08:09.800] {Main Thread} com.caucho.jca.PoolItem init create:
PoolItem[jdbc/buysou_cms,0,ManagedConnectionImpl](active:0, total:0)
[09-10-20 11:08:09.809] {Main Thread} com.caucho.jca.PoolItem toActive
allocate PoolItem[jdbc/buysou_cms,0,ManagedConnectionImpl]
[09-10-20 11:08:09.885] {Main Thread} com.caucho.jca.PoolItem toIdle idle
PoolItem[jdbc/buysou_cms,0,ManagedConnectionImpl]
[09-10-20 11:08:10.595] {Main Thread}
com.caucho.amber.manager.AmberContainer$LazyEntityManagerFactory init Amber
creating persistence unit 'buysou_cms' created with provider
'org.hibernate.ejb.HibernatePersistence'
...
I think the amber lazy init should be earlier than scheduled tasks, or any
PU injected task should trigger amber lazy init?
Another problem, I can't use scheduled-task tag in resin-web.xml because
any task will be initialized before the InjectManager add any beans in my
classpath (except the resin related beans and persistent related beans).
Then every task which need to inject some beans in my classpath would throw
the exception:
javax.enterprise.inject.UnsatisfiedResolutionException: Can't find a bean
for 'class com.mycompany.MyBean' because no beans implementing that class
have been registered with the injection manager InjectManager[web-app:
http://default].
I guess scheduled-task was different with resin:ScheduledTask?
-Wesley
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] 4.0.2 schedule
Thanks Scott. I'll test the JPA JSR299/330 stuff. 2009/10/14 Scott Ferguson f...@caucho.com The 4.0.2 snapshot is now available. Bugs can be reported at bugs.caucho.com. The snapshot isn't clean yet, so a bug report might duplicate one of our failing regression tests, but it's better to have two reports for a bug than zero. -- Scott On Oct 12, 2009, at 2:38 PM, Scott Ferguson wrote: On Oct 12, 2009, at 1:06 PM, Jeff Schnitzer wrote: Thanks for the update. Would it be helpful if we filed bugs against trunk? I tried it out a week ago but pretty quickly ran into a problem (@Named @RequestScoped didn't show up in the request attrs). I figured you guys were still working on it and probably didn't need the distraction, but if it would be useful, we can start reporting issues. For JSR-299/330, you can now report against the trunk, since it's been cleaned up. Other stuff might want to hold up, because we're still working through important include/forward and i18n issues. -- Scott Thanks, Jeff On Monday, October 12, 2009, Scott Ferguson f...@caucho.com wrote: FYI, we're taking extra time on 4.0.2 to bring it up from a development release to a stable release. That process is taking several weeks of extra work. Our current target is the end of October, but that may slip if 4.0.2 is not ready by then. -- Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] 4.0.2 schedule
Seems 4.0.2 snapshot passed most of my web test. Passed: Thirdparty Hibernate JPA integration (* see issues below) @Inject @Qualifier @Observes (with @Qualifier bindings) @ApplicationScoped @RequestScoped Failed: @SessionScoped not tested: @InterceptorBinding I found two issues so far: 1. I have to use @PersistenceUnit(name = myPU) when I use @PersistenceUnit(unitName = myPU) resin reports com.caucho.server.webapp.WebApp setConfigException ... @PersistenceUnit(unitName='myPU') is an unknown persistence unit. No matching JPA persistence-units have been deployed 2. @SessionScoped is not going to work well in my code. I noticed that resin use Hessian to serialize all session scoped beans (good approach). But this result in I have to implement Serializable interface in my session scoped beans and beans need to be injected in them. Unfortunately that could not be done because sometimes I need to inject third party beans and initiate third party objects in my session scoped beans. I think I could only use @SessionScoped annotation on SINGLE beans, though not tested yet. Thanks Scott. Magnificent work! -Wesley ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] 4.0.2 schedule
I think I could only use @SessionScoped annotation on SINGLE beans, though not tested yet. sorry, I mean SIMPLE beans not SINGLE. -Wesley 2009/10/14 Wesley Wu wumen...@gmail.com Seems 4.0.2 snapshot passed most of my web test. Passed: Thirdparty Hibernate JPA integration (* see issues below) @Inject @Qualifier @Observes (with @Qualifier bindings) @ApplicationScoped @RequestScoped Failed: @SessionScoped not tested: @InterceptorBinding I found two issues so far: 1. I have to use @PersistenceUnit(name = myPU) when I use @PersistenceUnit(unitName = myPU) resin reports com.caucho.server.webapp.WebApp setConfigException ... @PersistenceUnit(unitName='myPU') is an unknown persistence unit. No matching JPA persistence-units have been deployed 2. @SessionScoped is not going to work well in my code. I noticed that resin use Hessian to serialize all session scoped beans (good approach). But this result in I have to implement Serializable interface in my session scoped beans and beans need to be injected in them. Unfortunately that could not be done because sometimes I need to inject third party beans and initiate third party objects in my session scoped beans. I think I could only use @SessionScoped annotation on SINGLE beans, though not tested yet. Thanks Scott. Magnificent work! -Wesley ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] resin 4.0.1 : Chinese UTF8 characters problems in Quercus
That's a long live problem which exists in all Quercushttp://caucho.com/resin/doc/quercus.xtp version. I believe that's because of the poor unicode implementation of mysql (or all db specific) functions. I raised the question to Scott one years before, yet not solved now. - Wesley 2009/10/6 smallufo small...@gmail.com Hi I am new to Quercus . I just downloaded resin 4.0.1 , want to try java-php integration. But at first step , I am stuck in the encoding problem : Both of my java and php file are encoded in UTF8 It seems Chinese words in php can successfully pass to java side , BUT , java side cannot correctly pass Chinese words back. see my attachments for detail . If you cannot see the attachment , I uploaded to here : http://i273.photobucket.com/albums/jj212/smallufo/quercus_Chinese_bug.gif I've tried every setting in http://www.caucho.com/resin/doc/quercus.xtp#encoding , but still in vain. Can anybody tell me how to solve the problem ? Thanks a lot. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
