[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: `' expected `>' at `<'. Closing tags must close immediately after the tag name. 46: config: app-oinf in cluster wasn't picked up properly (#5004) 47: cloud: EC2elastic server with "ext:" address and missing cluster-system-key (#5015)servlet: add header-size-max and header-count-max (#4986, rep by Deepak Ramaprasad) 49: deploy: web-socket issue causing large deployment problems (#5113, rep by Alexey Abashev) 50: servlet: multipart-mime with forward parameters was double-parsing (#4896) -- 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 > 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 工体北路8号三里屯SOHO办公D座1103 邮编100027 [image: U3%8Y%PN7N{6ZGQY1F)PI_P] www.yinyuetai.com * * <>___ 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
[Resin-interest] too many user transaction pool broken message in log
Hi, After upgrading to Resin 4.0.14, in resin.log I found too many exceptions but I've got no idea why they were thrown. When using 4.0.10 there were no such exception logs with the same webapp code. 2~4 times per seconds. 4.0.13 also have the issue. java.lang.IllegalStateException: Internal error: user transaction pool broken because poolItems exist, but no transaction is active. at com.caucho.transaction.UserTransactionImpl.abortTransaction(UserTransactionImpl.java:419) at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:213) at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:792) at com.caucho.network.listen.TcpSocketLink.handleRequest(TcpSocketLink.java:685) at com.caucho.network.listen.TcpSocketLink.handleRequestsImpl(TcpSocketLink.java:665) at com.caucho.network.listen.TcpSocketLink.handleRequests(TcpSocketLink.java:613) at com.caucho.network.listen.AcceptTask.doTask(AcceptTask.java:104) at com.caucho.network.listen.ConnectionReadTask.runThread(ConnectionReadTask.java:98) at com.caucho.network.listen.ConnectionReadTask.run(ConnectionReadTask.java:81) at com.caucho.network.listen.AcceptTask.run(AcceptTask.java:67) 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
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 : > Thanks. I've fixed it for the next release (changing to ConcurrentHashMap) > > - Scott > > Wesley Wu wrote: >> Or this method sync the wrong map? >> >> private Set> resolveAllBeans() >> { >> synchronized (_beanMap) { >> LinkedHashSet> beans = new LinkedHashSet>(); >> >> for (ArrayList comp : _selfBeanMap.values()) { >> for (TypedBean typedBean : comp) { >> beans.add(typedBean.getBean()); >> } >> } >> >> return beans; >> } >> } >> >> maybe should synchronized (_selfBeanMap) instead. >> >> -Wesley >> >> >> 2010/11/30 Wesley Wu : >> >>> 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] InjectManager._selfBeanMap should be ConcurrentHashMap?
Or this method sync the wrong map? private Set> resolveAllBeans() { synchronized (_beanMap) { LinkedHashSet> beans = new LinkedHashSet>(); for (ArrayList comp : _selfBeanMap.values()) { for (TypedBean typedBean : comp) { beans.add(typedBean.getBean()); } } return beans; } } maybe should synchronized (_selfBeanMap) instead. -Wesley 2010/11/30 Wesley Wu : > 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] InjectManager._selfBeanMap should be ConcurrentHashMap?
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
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== 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"> Note: The purpose of line is to load com.buysou.cms.config.BeanRewriteConfig at startup. After I removed the line 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 : > 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=== >> >> >> 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";> >> >> >> com.buysou.cms.jms.qpid.pool.XaPooledConnectionFactory >> >> >> >> >> 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=== 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";> com.buysou.cms.jms.qpid.pool.XaPooledConnectionFactory 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] Possible memory leak in Resin 4.0.9
I'll tried to do so. 2010/8/20 Scott Ferguson : > Wesley Wu wrote: >> 2010/8/20 Scott Ferguson : >> >>> 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
2010/8/20 Scott Ferguson : > 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
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 : > 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] ConcurrentModificationException when InjectManager.findByName
Thanks Scott. Is my code causing this error as Aaron said? -Wesley 2010/8/20 Scott Ferguson : > 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.g
[Resin-interest] ConcurrentModificationException when InjectManager.findByName
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://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] 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 buildBean(Class beanClass) { Named named = beanClass.getAnnotation(Named.class); if (named != null) { Bean bean = (Bean) beanManager.resolve(beanManager.getBeans(named.value())); CreationalContext env = beanManager.createCreationalContext(bean); return (T) beanManager.getReference(bean, bean.getBeanClass(), env); } Bean bean = (Bean) beanManager.resolve(beanManager.getBeans(beanClass)); CreationalContext 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
Re: [Resin-interest] Possible memory leak in Resin 4.0.9
(ServletRequest, ServletResponse, FilterChain) 8 com.caucho.server.dispatch.FilterFilterChain.doFilter(ServletRequest, ServletResponse)8 com.buysou.servlet.filters.encoding.EnhancedEncodingFilter.doFilter(ServletRequest, ServletResponse, FilterChain) 8 com.caucho.server.dispatch.FilterFilterChain.doFilter(ServletRequest, ServletResponse)8 com.caucho.server.webapp.WebAppFilterChain.doFilter(ServletRequest, ServletResponse)8 com.caucho.server.webapp.AccessLogFilterChain.doFilter(ServletRequest, ServletResponse)8 com.caucho.server.dispatch.ServletInvocation.service(ServletRequest, ServletResponse)8 com.caucho.server.hmux.HmuxRequest.handleInvocation() 8 com.caucho.server.hmux.HmuxRequest.handleRequestImpl() 8 com.caucho.server.hmux.HmuxRequest.handleRequest() 8 com.caucho.network.listen.TcpSocketLink.dispatchRequest() 8 com.caucho.network.listen.TcpSocketLink.handleRequestsImpl(boolean) 8 com.caucho.network.listen.TcpSocketLink.handleRequests(boolean) 8 Hope these help. -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
[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 : > 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: >> >> >> > url="jdbc:mysql://192.168.1.2:3306/bbsee?useUnicode=true&characterEncoding=utf8" >> class="com.mysql.jdbc.Driver"> >> >> >> false >> >> 1500 >> 1024 >> 5 >> 1024 >> >> 30s >> 6h >> 1d >> 30s >> >> >> -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: false 1500 1024 5 1024 30s 6h 1d 30s -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
[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
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 > 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 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";> 1.0 ... has not problem in classes/META-INF 2010/7/5 Rick Mann : > > 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
Re: [Resin-interest] Resin 4.0.8 passed the tck?
Another minor issue about file uploading. I used commons upload to parse the request: org.apache.commons.fileupload.parseRequest but now it don't parsed it well. Instead all upload files all turned into something like: myUploadFile.file myUploadFile.filename myUploadFile.content-type plain fields. Is that the requirement of Servlet 3.0 spec? Should I respect this change and permanently modify my low level code according to it? -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
[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] 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
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 ThreadLocal to null. This worked for me in the last three years in several heavy loaded websites. -Wesley 2010/3/31 Scott Ferguson > 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
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 > 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
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
try { ut.begin(); CourseBean updateCourse = _manager.find(CourseBean.class, new Integer(1)); updateCourse.setCourse("Magic"); ut.commit(); } catch (Exception e) { e.printStackTrace(); } will work. -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 > > 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
one possibility of the problem: * Tasks was now initialized before any(maybe some of) @ApplicationScoped/@Singleton bean initialized. * If a task need to inject a bean which was not prepared by the CanDI container yet (I.E. an EntityManagerFactory) , it will not be injected. 2010/3/14 Hontvári József > The workaround recommended by Wesley would work (using > javax.enterprise.inject.Instance, I tried it, it doesn't throw > StackOverflowError), assuming that there is only one instance, but there is > more then one in my case. > Using setter injection instead of constructor injection, but using @Startup > doesn't work either, StackOverflowError is thrown here too. > > > Hontvári József írta: > > I have downloaded 4.0.4 but it still throws StackOverflowError on the same > example configuration file. > > Scott Ferguson írta: > > Hontvári József wrote: > > > The name of the first class is misleading (maybe Scheduled... would have > been better, it is executing scheduled tasks itself), Resin's scheduler > hasn't been involved in the configuration. But the issue is either the > same or we have two independent issues. If I remove the constructor > initialization by creating an empty constructor and use setter instead > of it, then the CanDI initialization does completes. However, if I add > @Startup annotation, so a class instance is actually created, then I > again receive StackOverflow. > > > > Thanks. I have this fixed for 4.0.4. > > -- Scott > > > Wesley Wu írta: > > > > 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 : > > > > > 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 like the test EL expression, > although it could also be the contents of the if. > > Also, it's possible that adding a in the > section will show the stack trace. > > -- Scott > > > > > ___ > resin-interest mailing > listresin-inter...@caucho.comhttp://maillist.caucho.com/mailman/listinfo/resin-interest > > > ___ > resin-interest mailing > listresin-inter...@caucho.comhttp://maillist.caucho.com/mailman/listinfo/resin-interest > > > -- > > ___ > resin-interest mailing > listresin-inter...@caucho.comhttp://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] 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 : > 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 like the test EL expression, > although it could also be the contents of the if. > > Also, it's possible that adding a in the > 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 > > > > > > submittedMailQueue > > #{primaryTransmitter} > > > > > > primaryTransmitter > > #{submittedMailQueue} > > > > > > #{primaryTransmitter} > > > > > 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}
Re: [Resin-interest] Where is javax.inject.Current ?
the docs should be updated I can't agree more. :) 2010/2/7 smallufo : > Oops , thanks for replying so soon. > BTW , the docs should be updated ... > > 2010/2/7 Wesley Wu >> >> according to the JSR299 & JSR330 final spec >> >> should use javax.inject.Inject instead >> >> 2010/2/7 smallufo : >> > 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
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 : > 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] @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 : > 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 === >> >> 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"> >> >> >> MyServlet >> com.mycompany.servlet.MyServlet >> >> >> MyServlet >> /MyServlet >> >> >> >> = >> >> 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
[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 === 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"> MyServlet com.mycompany.servlet.MyServlet MyServlet /MyServlet = 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] 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] WebSocket binary stream read error
My log output this error: [09-12-23 04:24:00.017] {hmtp-aaa-to-aaa-2} com.caucho.hemp.broker.HempMemoryQueue consumeQueue java.lang.IllegalStateException: WebSocket binary must begin with a 0x80 packet at 0x51 (Q) [09-12-23 04:24:00.017] {hmtp-aaa-to-aaa-2} at com.caucho.hessian.io.Hessian2StreamingInput$StreamingInputStream.readChunkLength(Hessian2StreamingInput.java:216) [09-12-23 04:24:00.017] {hmtp-aaa-to-aaa-2} at com.caucho.hessian.io.Hessian2StreamingInput$StreamingInputStream.startPacket(Hessian2StreamingInput.java:142) [09-12-23 04:24:00.017] {hmtp-aaa-to-aaa-2} at com.caucho.hessian.io.Hessian2StreamingInput.startPacket(Hessian2StreamingInput.java:82) [09-12-23 04:24:00.017] {hmtp-aaa-to-aaa-2} at com.caucho.hmtp.HmtpReader.readPacket(HmtpReader.java:86) [09-12-23 04:24:00.017] {hmtp-aaa-to-aaa-2} at com.caucho.server.cluster.HmuxQueue.authenticate(HmuxQueue.java:259) [09-12-23 04:24:00.017] {hmtp-aaa-to-aaa-2} at com.caucho.server.cluster.HmuxQueue.openStream(HmuxQueue.java:191) [09-12-23 04:24:00.017] {hmtp-aaa-to-aaa-2} at com.caucho.server.cluster.HmuxQueue.dispatch(HmuxQueue.java:110) [09-12-23 04:24:00.017] {hmtp-aaa-to-aaa-2} at com.caucho.hemp.broker.HempMemoryQueue.consumeQueue(HempMemoryQueue.java:330) [09-12-23 04:24:00.017] {hmtp-aaa-to-aaa-2} at com.caucho.hemp.broker.HempMemoryQueue.run(HempMemoryQueue.java:388) [09-12-23 04:24:00.017] {hmtp-aaa-to-aaa-2} at com.caucho.util.ThreadPool$PoolThread.runTasks(ThreadPool.java:901) [09-12-23 04:24:00.017] {hmtp-aaa-to-aaa-2} 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 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
Re: [Resin-interest] HempMemoryQueue Exception when synchronizing sessions between two nodes in a cluster
I gave some code for the request: Cache cache = cacheManager.getCache("forumPageCache"); cache.put("forum_1_page_1", postListInForum1Page1); cache.put("forum_1_page_2", postListInForum1Page2); cache.put("forum_1_page_3", postListInForum1Page3); cache.put("forum_2_page_1", postListInForum2Page1); cache.put("forum_2_page_2", postListInForum2Page2); When forum2 got a new post, then the page1 & page2 of forum2 should be stale and must be removed, while all pages in forum1 remained valid. My request : I should remove the stale cache entries ("forum_2_page1" & "forum_2_page2") by a maintainable manner? I want to do some search like this List cacheKeys = myCacheKeySearcher.doSearch(new SearchCriteria("forumId = 2")); for (String key : cacheKeys) { cache.remove(key); } Normally the search capability will be implemented by a lucene in-memory IndexSearcher. And I'll use a CacheEventListener or some AOP interceptor to synchronize the cache keys to the keys index store. My problem is: While I could index and search all the index keys in one JVM, how could I synchronized the keys index store (a lucene memory store) across the cluster? -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
Fortunately I found ehcache's concept is very like Jbosscache with regional eviction and cache loader. I really did not know ehcache had gone such far in the last two years, otherwise I should have evaluated it intensively :p That means my abstract cache layer won't need too much modification to accommodate ehcache. One of the feature I think ehcache may miss is the searchability of cache entries by key or property values. I've used Jbosscache Searchable edition (which use lucene) and it did some trick for me to search given cache entries and let them go stale. Any corrections or suggestions? Thanks very much, Jon. -Wesley 2009/12/19 Wesley Wu : > Great Jon, you help me to make a critical decision (not to use JBC any > more and switch to EHC & Terracotta). > > I'll give it a shot. > > -Wesley > > 2009/12/19 Jon Stevens : >> yep, i've had several conversations with the cto of terracotta and they are >> very on the ball about their products. >> jon >> >> On Thu, Dec 17, 2009 at 11:42 PM, Wesley Wu wrote: >>> >>> 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 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
Great Jon, you help me to make a critical decision (not to use JBC any more and switch to EHC & Terracotta). I'll give it a shot. -Wesley 2009/12/19 Jon Stevens : > yep, i've had several conversations with the cto of terracotta and they are > very on the ball about their products. > jon > > On Thu, Dec 17, 2009 at 11:42 PM, Wesley Wu wrote: >> >> 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 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
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 : > 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 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 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
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. 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 : > 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
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
[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} com.caucho.hemp.brok
Re: [Resin-interest] Lots of Connection reset
If u'r using apache or other web server backended by resin instead of running resin standalone, I think the 1202 snapshot should fix this issue. 2009/12/16 Mattias Jiderhamn : > We are seeing a lot of "Connection reset" with Hessian since the upgrade > of our production environment to 4.0.2 (both client and server). Would > this be related to the problems already reported against 4.0.2 and thus > fixed in the snapshot? > > Caused by: com.caucho.hessian.io.HessianFieldException: > se.exder.marketplace.api.MarketplaceAddressDTO.addressName: Connection reset > at > com.caucho.hessian.io.JavaDeserializer.logDeserializeError(JavaDeserializer.java:726) > at > com.caucho.hessian.io.JavaDeserializer$StringFieldDeserializer.deserialize(JavaDeserializer.java:639) > at > com.caucho.hessian.io.JavaDeserializer.readObject(JavaDeserializer.java:286) > at > com.caucho.hessian.io.JavaDeserializer.readObject(JavaDeserializer.java:178) > at > com.caucho.hessian.io.Hessian2Input.readObjectInstance(Hessian2Input.java:2110) > at > com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:2030) > at > com.caucho.hessian.io.CollectionDeserializer.readLengthList(CollectionDeserializer.java:93) > at > com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:1689) > at > com.caucho.hessian.io.Hessian2Input.readReply(Hessian2Input.java:351) > at com.caucho.hessian.client.HessianProxy.invoke(HessianProxy.java:241) > ... 39 more > Caused by: java.net.SocketException: Connection reset > at java.net.SocketInputStream.read(SocketInputStream.java:168) > at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) > at java.io.BufferedInputStream.read1(BufferedInputStream.java:258) > at java.io.BufferedInputStream.read(BufferedInputStream.java:317) > at > sun.net.www.http.ChunkedInputStream.readAheadBlocking(ChunkedInputStream.java:525) > at > sun.net.www.http.ChunkedInputStream.readAhead(ChunkedInputStream.java:582) > at > sun.net.www.http.ChunkedInputStream.read(ChunkedInputStream.java:669) > at java.io.FilterInputStream.read(FilterInputStream.java:116) > at > sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2391) > at > com.caucho.hessian.io.Hessian2Input.readBuffer(Hessian2Input.java:2704) > at com.caucho.hessian.io.Hessian2Input.read(Hessian2Input.java:2676) > at > com.caucho.hessian.io.Hessian2Input.parseUTF8Char(Hessian2Input.java:2501) > at > com.caucho.hessian.io.Hessian2Input.parseChar(Hessian2Input.java:2492) > at > com.caucho.hessian.io.Hessian2Input.readString(Hessian2Input.java:1328) > at > com.caucho.hessian.io.JavaDeserializer$StringFieldDeserializer.deserialize(JavaDeserializer.java:635) > ... 47 more > > -- > > > > > > ___ > 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] 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 Map 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 Map 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
[Resin-interest] hmux broken pipe
when running resin in load-balance cluster with a web-tier(one server) and a app-tier(two server) my app-tier console display the error [09-12-15 00:14:34.369] {server-192.168.1.5:6801-34} com.caucho.java.JavaCompiler compileInt Compiling _jsp/_person/_Index__jsp.java [09-12-15 00:14:34.723] {server-192.168.1.5:6801-34} com.caucho.java.JavaCompiler compileInt Compiling _jsp/_person/_Header__jsp.java [09-12-15 00:14:53.096] {hmtp-aaa-to-aaa-31} com.caucho.server.cluster.HmuxQueue dispatch java.net.SocketException: Write failed: Broken pipe [09-12-15 00:14:53.096] {hmtp-aaa-to-aaa-31}at jrockit.net.SocketNativeIO.writeBytesPinned(Native Method) [09-12-15 00:14:53.096] {hmtp-aaa-to-aaa-31}at jrockit.net.SocketNativeIO.socketWrite(SocketNativeIO.java:73) [09-12-15 00:14:53.096] {hmtp-aaa-to-aaa-31}at java.net.SocketOutputStream.socketWrite0(SocketOutputStream.java) [09-12-15 00:14:53.096] {hmtp-aaa-to-aaa-31}at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) [09-12-15 00:14:53.096] {hmtp-aaa-to-aaa-31}at java.net.SocketOutputStream.write(SocketOutputStream.java:137) [09-12-15 00:14:53.096] {hmtp-aaa-to-aaa-31}at com.caucho.vfs.TcpStream.write(TcpStream.java:150) [09-12-15 00:14:53.096] {hmtp-aaa-to-aaa-31}at com.caucho.vfs.WriteStream.flush(WriteStream.java:367) [09-12-15 00:14:53.096] {hmtp-aaa-to-aaa-31}at com.caucho.server.cluster.ClusterStream.writeYield(ClusterStream.java:626) [09-12-15 00:14:53.096] {hmtp-aaa-to-aaa-31}at com.caucho.server.cluster.HmuxQueue.dispatch(HmuxQueue.java:132) [09-12-15 00:14:53.096] {hmtp-aaa-to-aaa-31}at com.caucho.hemp.broker.HempMemoryQueue.consumeQueue(HempMemoryQueue.java:415) [09-12-15 00:14:53.096] {hmtp-aaa-to-aaa-31}at com.caucho.hemp.broker.HempMemoryQueue.run(HempMemoryQueue.java:473) [09-12-15 00:14:53.096] {hmtp-aaa-to-aaa-31}at com.caucho.util.ThreadPool$PoolThread.runTasks(ThreadPool.java:901) [09-12-15 00:14:53.096] {hmtp-aaa-to-aaa-31}at com.caucho.util.ThreadPool$PoolThread.run(ThreadPool.java:866) [09-12-15 00:14:53.096] {hmtp-aaa-to-aaa-31} I'm using resin 4.0.2.s20091202 snapshot on CentOS 5.2 x86 linux compiled with JNI, with a evaluation PRO lisence. JDK: jrockit 1.6.0_14 x86 I thinks maybe caused by directive. Any ideas? -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
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 : > 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 : >> >>> I think the win32/win64 dlls should be recompiled against the new >>> modification. >>> >>> 2009/12/3 Wesley Wu : >>> >>>> 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 : >>>> >>>>> 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()
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 : > I think the win32/win64 dlls should be recompiled against the new > modification. > > 2009/12/3 Wesley Wu : >> 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 : >>> 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-
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 : > 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 : >> 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 pars
Re: [Resin-interest] new Resin 4.0 snapshot
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 : > 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}
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 : > 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 : >> >>> 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
Another SEVERE issues with this snapshot. All "POST" request was dramatically CHANGED to "GET" request. -Wesley 2009/12/3 Scott Ferguson : > 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
Re: [Resin-interest] new Resin 4.0 snapshot
Thanks Scott. This snapshot finally fix it all. I'll have to fix it for you if you don't get this snapshot out in a week :) -Wesley 2009/12/3 Scott Ferguson : > 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
Re: [Resin-interest] Multi-Part request error when using HmuxRequest in Resin 4.0.2(GA)
Thanks Scott. I think the blocking was resolved but another exception occurred: 2009-12-01 09:24:58.789 ERROR [server--6800-6] c.b.c.s.CmsPageFilter (213) - java.lang.IllegalStateException: forward() not allowed after buffer has committed. at com.caucho.server.webapp.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:163) at com.caucho.server.webapp.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:114) at com.buysou.cms.pageactions.TemplateForwardResolution.execute(TemplateForwardResolution.java:37) at com.buysou.cms.servlet.CmsPageFilter.doFilter(CmsPageFilter.java:211) at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:88) at com.buysou.servlet.filters.encoding.EnhancedEncodingFilter.doFilter(EnhancedEncodingFilter.java:85) at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:88) at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:183) at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:169) at com.caucho.server.webapp.AccessLogFilterChain.doFilter(AccessLogFilterChain.java:103) at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:290) at com.caucho.server.hmux.HmuxRequest.handleInvocation(HmuxRequest.java:475) at com.caucho.server.hmux.HmuxRequest.handleRequestImpl(HmuxRequest.java:394) at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:357) at com.caucho.server.port.TcpConnection.handleRequestsImpl(TcpConnection.java:619) at com.caucho.server.port.TcpConnection.handleRequests(TcpConnection.java:556) at com.caucho.server.port.TcpConnection$AcceptTask.doTask(TcpConnection.java:1194) at com.caucho.server.port.TcpConnection$ConnectionReadTask.runThread(TcpConnection.java:1127) at com.caucho.server.port.TcpConnection$AcceptTask.run(TcpConnection.java:1158) at com.caucho.util.ThreadPool$PoolThread.runTasks(ThreadPool.java:901) at com.caucho.util.ThreadPool$PoolThread.run(ThreadPool.java:866) After I processed the posted file attachment and then attempted forwarding to a jsp page, it told me: forward() not allowed after buffer has committed. I don't think I had written anything to the response before the forwarding. If I use 8080 port, everything goes fine. 2009/12/1 Scott Ferguson : > Wesley Wu wrote: >> 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. >> > > I've uploaded a new snapshot, so it would be great if you can check if > this fix is the same one as you're seeing. > > -- Scott >> 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 : >> >>> 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 >> >> > > > > > ___ > 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 : > 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)
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 > > 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 >> >> > 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.(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
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 > > 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.(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 > 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 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] Multi-Part request error when using HmuxRequest in Resin 4.0.2(GA)
Multi-Part request error when using HmuxRequest. 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.(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 -Wesley ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin V Glassfish
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] change log page broken
http://www.caucho.com/resin/changes/changes.xtp [show] /var/www/hosts/www.caucho.com/webapps/resin/changes/changes.xtp:116: expected name at ` ' 114: quercus: Drupal and OpenID (#3609, rep by B. Wu) 115: quercus: QuercusParseException - missing semicolon within a scriptlet php tag. (#3668, rep by kenfoo) 116: quercus: StringBuilderValue.create() is not performing a "& 0xFF" on the character value (#3654, rep by kenfoo) 117: quercus: ErrorException is missing (#3667, rep by kenfoo) 118: quercus: substr_compare failed (#3662, rep by jindw) ___ 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 > 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 : > > > 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=showuser&id=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=showuser&id=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 >> <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 >> <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 and 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
Re: [Resin-interest] url rewriting / search engine friendly
Not recommended. I think filter should handle this, which is not relative to business logic. 2009/10/30 Riccardo Cohen > 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 > <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 and 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> > > http://maillist.caucho.com/mailman/listinfo/resin-interest > > > > > > > > > > > > ___ > > resin-interest mailing list > > 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 > 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] 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 > 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 and 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] UnsatisfiedLinkError: com/caucho/vfs/JniSocketImpl.writeCloseNative
Every request cause this stacktrace [09-10-29 00:26:51.777] {http--80-6} com.caucho.server.webapp.ErrorPageManager sendServletErrorImpl java.lang.UnsatisfiedLinkError: com/caucho/vfs/JniSocketImpl.writeCloseNative [09-10-29 00:26:51.777] {http--80-6} at com.caucho.vfs.JniSocketImpl.write(JniSocketImpl.java:301) [09-10-29 00:26:51.777] {http--80-6} at com.caucho.vfs.JniStream.write(JniStream.java:117) [09-10-29 00:26:51.777] {http--80-6} at com.caucho.vfs.WriteStream.close(WriteStream.java:1160) [09-10-29 00:26:51.777] {http--80-6} at com.caucho.server.http.HttpResponseStream.closeNext(HttpResponseStream.java:179) [09-10-29 00:26:51.777] {http--80-6} at com.caucho.server.connection.ResponseStream.finish(ResponseStream.java:684) [09-10-29 00:26:51.777] {http--80-6} at com.caucho.server.connection.ResponseStream.close(ResponseStream.java:829) [09-10-29 00:26:51.777] {http--80-6} at com.caucho.server.connection.AbstractHttpResponse.finishInvocation(AbstractHttpResponse.java:975) [09-10-29 00:26:51.777] {http--80-6} at com.caucho.server.connection.AbstractHttpResponse.close(AbstractHttpResponse.java:908) [09-10-29 00:26:51.777] {http--80-6} at com.caucho.server.connection.HttpServletResponseImpl.close(HttpServletResponseImpl.java:1480) [09-10-29 00:26:51.777] {http--80-6} at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:200) [09-10-29 00:26:51.777] {http--80-6} at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:291) [09-10-29 00:26:51.777] {http--80-6} at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:783) [09-10-29 00:26:51.777] {http--80-6} at com.caucho.server.port.TcpConnection.handleRequestsImpl(TcpConnection.java:567) [09-10-29 00:26:51.777] {http--80-6} at com.caucho.server.port.TcpConnection.handleRequests(TcpConnection.java:507) [09-10-29 00:26:51.777] {http--80-6} at com.caucho.server.port.TcpConnection$AcceptTask.doTask(TcpConnection.java:1131) [09-10-29 00:26:51.777] {http--80-6} at com.caucho.server.port.TcpConnection$ConnectionReadTask.runThread(TcpConnection.java:1059) [09-10-29 00:26:51.777] {http--80-6} at com.caucho.server.port.TcpConnection$AcceptTask.run(TcpConnection.java:1091) [09-10-29 00:26:51.777] {http--80-6} at com.caucho.util.ThreadPool$PoolThread.runTasks(ThreadPool.java:900) [09-10-29 00:26:51.777] {http--80-6} at com.caucho.util.ThreadPool$PoolThread.run(ThreadPool.java:867) This exception occurs in both windows x86 and x64. -Wesley ___ 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: 0 2 * 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 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 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 was different with ? -Wesley ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] 4.0.2 schedule
Yes, I turned on (simply copied from my previous 4.0.0 conf file). When I turned it off (commented them out) @SessionScope worked fine. Thanks. -Wesley 2009/10/14 Scott Ferguson > > On Oct 13, 2009, at 1:49 PM, Wesley Wu wrote: > > > 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 > > > Thanks. I've added that as http://bugs.caucho.com/view.php?id=3708. > > > 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. > > > Do you have enabled? The sample resin.xml does > enable it, but you might want to change that if you don't want persistent > store. > > > > > Thanks Scott. Magnificent work! > > > thanks! > > -- 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] 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 > 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
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
Thanks Scott. I'll test the JPA & JSR299/330 stuff. 2009/10/14 Scott Ferguson > 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 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] resin 4.0.1 : Chinese UTF8 characters problems in Quercus
That's a long live problem which exists in all Quercus<http://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 > 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
Re: [Resin-interest] Integrating Resin with NetBeans
I'm using Intellij IDEA which supports Resin 3.x. After some modification of the resin plugin, I managed to support 4.0.x in IDEA. Eclipse should support resin too. I don't know if NetBeans supports Resin 4.0.x. :-( -Wesley 2009/9/17 Rom Sok > Hi, > > I am trying to set up NetBeans to build a Web App, and it requires > specifying the server I will be using. It is a shame that I can't set it up > generically without tying it to a particular server, but anyway, I am using > Resin, and cannot find it in the list of servers NetBeans gives. > Could someone please tell me how I can add Resin to that list? > > Thanks. > > ___ > 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] chunked encoding issue in HmuxResponse
Thanks Scott. I found my resolution will cause another bug :( so don't use my code. waiting for the 4.0.2 :) - Wesley 2009/9/17 Scott Ferguson > > On Sep 14, 2009, at 5:11 AM, Wu Wesley wrote: > > > affected version: Resin 4.0.0 & 4.0.1 > > reproducible: every time > > > > HmuxResponse.writeHeadersInt should not always return false, > > otherwise in ResponseStream "write-chunk5" will never happen if > > _chunkedEncoding==false. > > > > this result in UTF8Writer produces a reproducible error. > > I've just filed this as http://bugs.caucho.com/view.php?id=3686, > although we've already redesigned that code significantly, so it may > not apply > > -- Scott > > > > > I modified HmuxResponse.writeHeadersInt to add some lines below: > > > > > > // add by wesley start > > boolean hasContentLength = false; > > // add by wesley end > > if (_contentLength >= 0) { > > cb.clear(); > > cb.append(_contentLength); > > _req.writeHeader("Content-Length", cb); > > // add by wesley start > > hasContentLength = true; > > // add by wesley end > > } else if (length >= 0) { > > cb.clear(); > > cb.append(length); > > _req.writeHeader("Content-Length", cb); > > // add by wesley start > > hasContentLength = true; > > // add by wesley end > > } > > > > ... > > > > // add by wesley start > > boolean isChunked = false; > > if (!hasContentLength && !isHead) { > > isChunked = true; > > } > > return isChunked; > > // add by wesley start > > } > > > > and everything goes fine. > > > > -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] chunked encoding issue in HmuxResponse
affected version: Resin 4.0.0 & 4.0.1 reproducible: every time HmuxResponse.writeHeadersInt should not always return false, otherwise in ResponseStream "write-chunk5" will never happen if _chunkedEncoding==false. this result in UTF8Writer produces a reproducible error. I modified HmuxResponse.writeHeadersInt to add some lines below: // add by wesley start boolean hasContentLength = false; // add by wesley end if (_contentLength >= 0) { cb.clear(); cb.append(_contentLength); _req.writeHeader("Content-Length", cb); // add by wesley start hasContentLength = true; // add by wesley end } else if (length >= 0) { cb.clear(); cb.append(length); _req.writeHeader("Content-Length", cb); // add by wesley start hasContentLength = true; // add by wesley end } ... // add by wesley start boolean isChunked = false; if (!hasContentLength && !isHead) { isChunked = true; } return isChunked; // add by wesley start } and everything goes fine. -Wesley ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Bug when Injecting beans in different scope with bytecode java.lang.VerifyError
TcpConnection.java:1252) at com.caucho.util.ThreadPool$PoolThread.runTasks(ThreadPool.java:866) at com.caucho.util.ThreadPool$PoolThread.run(ThreadPool.java:779) Caused by: java.lang.VerifyError: (class: test/TestBean$ScopeProxy, method: evilMethod2 signature: (IIILjava/lang/String;)Ljava/lang/String;) Expecting to find object/array on stack at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389) at java.lang.Class.getConstructors(Class.java:1459) at com.caucho.config.bytecode.ScopeAdapter.generateProxy(ScopeAdapter.java:163) at com.caucho.config.bytecode.ScopeAdapter.(ScopeAdapter.java:59) at com.caucho.config.bytecode.ScopeAdapter.create(ScopeAdapter.java:64) at com.caucho.config.inject.SimpleBean.getScopeAdapter(SimpleBean.java:450) at com.caucho.config.inject.InjectManager.getInstanceToInject(InjectManager.java:1454) at com.caucho.config.program.FieldComponentProgram.inject(FieldComponentProgram.java:91) at com.caucho.config.inject.ComponentImpl.createNoInit(ComponentImpl.java:316) at com.caucho.server.dispatch.ServletConfigImpl.createServletImpl(ServletConfigImpl.java:895) at com.caucho.server.dispatch.ServletConfigImpl.createServlet(ServletConfigImpl.java:810) ... 14 more servlet is good when evilMethod and evilMethod2 were both commented. I believe this is due to a bug in com.caucho.bytecode.JavaClass. -Wesley ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Any chance to support an out ofboxJSR299implementation for GAE?
Guice 1.0 lacks too many features of JSR299. I switched from Spring to Guice in 2007, then switched from Guice to Resin JSR299 draft in early 2008. - Original Message - From: "Scott Hernandez" To: "General Discussion for the Resin application server" Sent: Thursday, April 23, 2009 1:47 PM Subject: Re: [Resin-interest] Any chance to support an out ofboxJSR299implementation for GAE? > There is also Guice, and it works on GAE. Just saying... > > On Wed, Apr 22, 2009 at 10:12 PM, wesley wrote: >> Thanks. >> >> My app is heavily depending on Resin CanDI. >> >> Hope we'll get an out-of-box Resin CanDI before Gavin King's JSR299 RI >> 1.0 >> final release :) >> >> - Original Message - >> From: "Emil Ong" >> To: "General Discussion for the Resin application server" >> >> Sent: Thursday, April 23, 2009 12:37 PM >> Subject: Re: [Resin-interest] Any chance to support an out ofbox >> JSR299implementation for GAE? >> >> >>> On Wed, Apr 22, 2009 at 04:31:43PM -0700, Scott Ferguson wrote: >>>> Not in GAE because their security manager doesn't allow >>>> Thread.setContextClassLoader. We're restricted to using the web-app's >>> >>> I just got word that they are planning to make >>> Thread.setContextClassLoader() available soon, so that may be an option. >>> >>> Emil >>> >>>> classloader. I'm pretty sure we can create child classloaders (for >>>> proxy/enhancement), but I haven't checked yet. >>>> >>>> -- Scott >>>> >>>> >>>> > >>>> > >>>> > -Wesley >>>> > >>>> > >>>> > - Original Message - >>>> > From: Scott Ferguson >>>> > To: General Discussion for the Resin application server >>>> > Sent: Thursday, April 16, 2009 2:47 AM >>>> > Subject: Re: [Resin-interest] Any chance to support an out of box >>>> > JSR299implementation for GAE? >>>> > >>>> > >>>> > >>>> > >>>> > On Apr 15, 2009, at 10:20 AM, wesley wrote: >>>> > >>>> > >>>> > Hi there, >>>> > >>>> > I wonder if Resin could distribute a library to support an out of >>>> > box >>>> > JSR299 implementation for Google App Engine. >>>> > We know Resin can't run on GAE now, but I think Resin's >>>> > implementation >>>> > of CanDI may be run on GAE. >>>> > Is there any plan for this? >>>> > >>>> > >>>> > Hmm. That's an interesting thought. Resin's CanDI is in resin- >>>> > kernel.jar >>>> > and doesn't depend on Resin itself, with the important exception of >>>> > the >>>> > Request and Session scopes. >>>> > >>>> > >>>> > Some of the Interception features wouldn't be available because of >>>> > the >>>> > current Google limitations on file writing (and probably missing >>>> > javac), >>>> > because Resin generates Java code instead of writing bytecode >>>> > directly. >>>> > >>>> > >>>> > There would be a few changes needed because Resin CanDI does expect >>>> > Resin >>>> > classloaders, but I think that would be straightforward to change. >>>> > >>>> > >>>> > -- Scott >>>> > >>>> > >>>> > >>>> > regards >>>> > -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 >>> >>> >>> Emil Ong >>> Chief Evangelist >>> Caucho Technology, Inc. >>> Tel. (858) 456-0300 >>> mailto:e...@caucho.com >>> http://blog.caucho.com/ >>> >>> Caucho: Reliable Open Source >>> --> Resin: application server >>> --> Quercus: PHP in Java >>> --> Java CanDI: contexts and dependency injection >>> >>> >>> ___ >>> 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] Any chance to support an out ofbox JSR299implementation for GAE?
Thanks. My app is heavily depending on Resin CanDI. Hope we'll get an out-of-box Resin CanDI before Gavin King's JSR299 RI 1.0 final release :) - Original Message - From: "Emil Ong" To: "General Discussion for the Resin application server" Sent: Thursday, April 23, 2009 12:37 PM Subject: Re: [Resin-interest] Any chance to support an out ofbox JSR299implementation for GAE? > On Wed, Apr 22, 2009 at 04:31:43PM -0700, Scott Ferguson wrote: >> Not in GAE because their security manager doesn't allow >> Thread.setContextClassLoader. We're restricted to using the web-app's > > I just got word that they are planning to make > Thread.setContextClassLoader() available soon, so that may be an option. > > Emil > >> classloader. I'm pretty sure we can create child classloaders (for >> proxy/enhancement), but I haven't checked yet. >> >> -- Scott >> >> >> > >> > >> > -Wesley >> > >> > >> > - Original Message - >> > From: Scott Ferguson >> > To: General Discussion for the Resin application server >> > Sent: Thursday, April 16, 2009 2:47 AM >> > Subject: Re: [Resin-interest] Any chance to support an out of box >> > JSR299implementation for GAE? >> > >> > >> > >> > >> > On Apr 15, 2009, at 10:20 AM, wesley wrote: >> > >> > >> > Hi there, >> > >> >I wonder if Resin could distribute a library to support an out of >> > box >> > JSR299 implementation for Google App Engine. >> >We know Resin can't run on GAE now, but I think Resin's >> > implementation >> > of CanDI may be run on GAE. >> >Is there any plan for this? >> > >> > >> > Hmm. That's an interesting thought. Resin's CanDI is in resin- >> > kernel.jar >> > and doesn't depend on Resin itself, with the important exception of >> > the >> > Request and Session scopes. >> > >> > >> > Some of the Interception features wouldn't be available because of the >> > current Google limitations on file writing (and probably missing >> > javac), >> > because Resin generates Java code instead of writing bytecode >> > directly. >> > >> > >> > There would be a few changes needed because Resin CanDI does expect >> > Resin >> > classloaders, but I think that would be straightforward to change. >> > >> > >> > -- Scott >> > >> > >> > >> > regards >> > -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 > > > Emil Ong > Chief Evangelist > Caucho Technology, Inc. > Tel. (858) 456-0300 > mailto:e...@caucho.com > http://blog.caucho.com/ > > Caucho: Reliable Open Source > --> Resin: application server > --> Quercus: PHP in Java > --> Java CanDI: contexts and dependency injection > > > ___ > 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] Any chance to support an out of box JSR299implementation for GAE?
1. For bytecode generation: I can afford to use compile time weaver of byte code enhancer. 2. For classloader: Can we load resin's classloader at startup via servlet filter or listener and then use it for all class loading? -Wesley - Original Message - From: Scott Ferguson To: General Discussion for the Resin application server Sent: Thursday, April 16, 2009 2:47 AM Subject: Re: [Resin-interest] Any chance to support an out of box JSR299implementation for GAE? On Apr 15, 2009, at 10:20 AM, wesley wrote: Hi there, I wonder if Resin could distribute a library to support an out of box JSR299 implementation for Google App Engine. We know Resin can't run on GAE now, but I think Resin's implementation of CanDI may be run on GAE. Is there any plan for this? Hmm. That's an interesting thought. Resin's CanDI is in resin-kernel.jar and doesn't depend on Resin itself, with the important exception of the Request and Session scopes. Some of the Interception features wouldn't be available because of the current Google limitations on file writing (and probably missing javac), because Resin generates Java code instead of writing bytecode directly. There would be a few changes needed because Resin CanDI does expect Resin classloaders, but I think that would be straightforward to change. -- Scott regards -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] Any chance to support an out of box JSR299 implementation for GAE?
Hi there, I wonder if Resin could distribute a library to support an out of box JSR299 implementation for Google App Engine. We know Resin can't run on GAE now, but I think Resin's implementation of CanDI may be run on GAE. Is there any plan for this? regards -Wesley___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Why Apache?
Thanks Scott. How about Lighttpd? -Wesley - Original Message - From: "Scott Ferguson" To: "General Discussion for the Resin application server" Sent: Wednesday, March 11, 2009 2:30 AM Subject: Re: [Resin-interest] Why Apache? > > On Mar 10, 2009, at 11:14 AM, wesley wrote: > >> Hi Scott, >> >>Here is my long wait question : >> >>How to configure Resin run with nginx? > > Hmm. nginx has a http proxy > http://wiki.codemongers.com/NginxHttpProxyModule > . > > However, it looks like they only support HTTP/1.0 on the backend, > which is a big limitation because keepalives are very important in a > proxy configuration. I'd assumed they supported HTTP/1.1. That's > actually a problem. > > We could add a FastCgi frontend interface to Resin, which would let it > run behind nginx efficiently. (e.g. for Resin 4.0.1 or 4.0.2 whenever > we upgrade our own FastCgi.) > > -- Scott > >> >> >> regards >> Wesley >> >> - Original Message - >> From: "Scott Ferguson" >> To: "General Discussion for the Resin application server" >> >> Sent: Wednesday, March 11, 2009 1:52 AM >> Subject: Re: [Resin-interest] Why Apache? >> >> >>> >>> On Mar 10, 2009, at 10:44 AM, Rachel McConnell wrote: >>> >>>> Static file serving, perhaps? I don't know the current benchmarks >>>> but >>>> Apache has always had the reputation of being very fast for static >>>> files, whereas that's not what resin is optimized for. >>>> >>>> I say this from the POV of not using Apache at all, though: we use >>>> resin behind HAProxy for load balancing, and a lighttpd instance for >>>> image files. >>> >>> Actually, Resin's static file performance matches Apache's, because >>> Apache really isn't all that fast. >>> >>> If you really need ultra fast static files, then something like >>> lighttpd or nginx would be a better choice than Apache. >>> >>> -- Scott >>>> >>>> >>>> Rachel >>>> >>>> On Tue, Mar 10, 2009 at 10:14 AM, Aaron Freeman >>>> wrote: >>>>> After watching a few of these threads about people using mod_caucho >>>>> with >>>>> Apache, it dawned on me to ask an open-ended question: >>>>> >>>>> Why use Apache at all? >>>>> >>>>> I am sure there are good reasons for it out there, so I am just >>>>> curious what >>>>> the use-case is for using Apache plus Resin instead of using just >>>>> Resin? >>>>> >>>>> >>>>> >>>>> ___ >>>>> 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] Why Apache?
Hi Scott, Here is my long wait question : How to configure Resin run with nginx? regards Wesley - Original Message - From: "Scott Ferguson" To: "General Discussion for the Resin application server" Sent: Wednesday, March 11, 2009 1:52 AM Subject: Re: [Resin-interest] Why Apache? > > On Mar 10, 2009, at 10:44 AM, Rachel McConnell wrote: > >> Static file serving, perhaps? I don't know the current benchmarks but >> Apache has always had the reputation of being very fast for static >> files, whereas that's not what resin is optimized for. >> >> I say this from the POV of not using Apache at all, though: we use >> resin behind HAProxy for load balancing, and a lighttpd instance for >> image files. > > Actually, Resin's static file performance matches Apache's, because > Apache really isn't all that fast. > > If you really need ultra fast static files, then something like > lighttpd or nginx would be a better choice than Apache. > > -- Scott >> >> >> Rachel >> >> On Tue, Mar 10, 2009 at 10:14 AM, Aaron Freeman >> wrote: >>> After watching a few of these threads about people using mod_caucho >>> with >>> Apache, it dawned on me to ask an open-ended question: >>> >>> Why use Apache at all? >>> >>> I am sure there are good reasons for it out there, so I am just >>> curious what >>> the use-case is for using Apache plus Resin instead of using just >>> Resin? >>> >>> >>> >>> ___ >>> 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] A config question about IIS ISAPI plugin
Hi there, I'm using IIS as the frontend contacting resin by isapi_srun.dll. I've trouble to find the document about how to configure the params below: connect-timeout live-time dead-time which /caucho-status servlet showed me. The running value I saw in my webapp: connect-timeout: 2 live-time: 10 dead-time: 20 The connect-timeout was too low to make IIS sometimes think the backend resin could not be contacted as returns HTTP 5xx to client. How could I configure these params in httpd.conf or anywhere? BTW: I know exactly how to configure timeout/pool/keepalive params for apache plugin. I'm using Resin 3.1.7a. regards -Wesley___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Typo in resin c src file resin.def?
Hi Scott, I need to recompile win32 src to platform AMD64. Other projects recompiled successfully except project "resin". Visual Studio generated three errors complaining that "Java_com_caucho_boot_JniProcess_getMaxFd" "Java_com_caucho_boot_JniProcess_setMaxFd" symbols not found. I double checked the source code and win32 dll file and found it probably a type error. I edited these two line in "resin.def" file to Java_com_caucho_boot_JniProcess_getFdMax Java_com_caucho_boot_JniProcess_setFdMax and successfully rebuilt it. The recompiled 64bit resin.dll worked fine. -Wesley___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 3.2.0 is available
Great work! I will try to migrate my busy web app from 3.1.5.s080331 to 3.2.0. :-) - Original Message - From: "Scott Ferguson" <[EMAIL PROTECTED]> To: "General Discussion for the Resin application server" Sent: Thursday, August 07, 2008 11:58 PM Subject: [Resin-interest] Resin 3.2.0 is available > Resin 3.2.0 is now available at the usual download > http://caucho.com/download > . Release notes are at http://caucho.com/resin/changes/resin-3.2.0.xtp. > > Resin 3.2.x is the development branch. We have a full roadmap of > stuff to add to 3.2.x, so 3.2.x will be changing considerably for each > release. For sites that don't want that kind of code-upheaval, use > the 3.1.x stable branch. > > Much of the 3.2.0 work was underlying refactoring and distribution/ > release refactoring. Jars have been merged, so resin.jar and > javaee-16.jar are the only needed jars for Resin OpenSource. Resin > Pro also needs pro.jar. Also, the resin.xml replaces resin.conf (to > make editors/mail happy), and a bunch of smaller changes in the > distribution layout. > > The 3.2.0 release now includes a 32-bit debian package at the download > site, which will make installation easier for Debian Linux sites > including Ubuntu. > > For administration, the /resin-admin has been reworked and enhanced. > New capabilities include: > * graphing of critical statistics > * revised and enhanced summary page > * monitoring and display of slow requests > * new JMX page displaying all MBeans and attributes in the system > * revised web-app page including start/stop/restart > > For alerts, we've added a "mail:" log-handler, which can email you a > compilation of the severe and critical log messages (this is very > handy.) > > The threading and socket management has been refactored to better > handle comet and jabber connections. During the checkout process, we > loaded it with 25,000 simultaneous comet connections as a stress test. > > The distributed sessions have been reworked to use BAM as the > underlying transport, and the database restructured to handle planned > distributed object enhancements like distributed caching, and better > startup performance. Both the threading and session refactorings are > major changes, so sites relying on them should do their own stress > testing. > > Our JSF implementation now includes a handy debugging page, to better > show the state of the JSF system. The example at > http://caucho.com/resin/examples/jsf-webbeans.xtp > shows this capability (see the bottom right corner.) > > BAM (http://caucho.com/resin/doc/bam.xtp) has been refactored and > cleaned up. It can now act as a SEDA/queue replacement for memory- > based JMS queues. The client and service have been simplified, so the > housekeeping overhead is now minimal. In addition, you can now > program to BAM using PHP, which is a very cool feature. > > Share and Enjoy! > > -- 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] Quercus mysql multibyte character-set problem
Hi Scott, I've found this bug fixed, thanks. Was it included in the nearest snapshot? -Wesley - Original Message - From: "Scott Ferguson" <[EMAIL PROTECTED]> To: "General Discussion for the Resin application server" Sent: Monday, May 19, 2008 11:09 PM Subject: Re: [Resin-interest] Quercus mysql multibyte character-set problem On May 17, 2008, at 12:44 AM, wesley wrote: PHP function mysql_query & mysql_fetch_x cannot handle myltibyte column data. I've test for resin version 3.1.5/3.1.6 and 3.2.0 snapshot, also mysql 4.1.22/5.0.51b/5.1.23rc/6.0.4/alpha as well as mysql-connector- java-3.1.14/5.1.x. This issue can be reproduced in every combination. Thanks. I've filed this as http://bugs.caucho.com/view.php?id=2676. The solution may be a bit tricky because the JDBC driver normally handles i18n in Java, while PHP normally just deals with the unencoded bytes. Have you checked the behavior with unicode.semantics="on"? (i.e. PHP 6 mode). If that's enabled, then Quercus strings are 16-bit like Java, not 8-bit like PHP 5. That may be more compatible with the JDBC driver (and really is the right direction moving forward.) -- Scott Test case: test.php = Output should be: 你好 我好 你好 我好 Output now was: `} } `} } =resin-web.xml=== http://caucho.com/ns/resin";> jdbc/discuz jdbc:mysql://localhost:3306/test? useUnicode=true&characterEncoding=UTF-8 root password 200 java:comp/env/jdbc/discuz UTF-8 false UTF-8 UTF-8 index.php = mysql db script=== -- MySQL dump 10.13 Distrib 5.1.24-rc, for Win32 (ia32) -- -- Host: localhostDatabase: test -- -- -- Server version 5.1.24-rc-community /*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */; /*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */; /*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */; /*!40101 SET NAMES utf8 */; /*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */; /*!40103 SET TIME_ZONE='+00:00' */; /*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */; /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */; /*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */; /*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */; -- -- Table structure for table `test` -- DROP TABLE IF EXISTS `test`; SET @saved_cs_client = @@character_set_client; SET character_set_client = utf8; CREATE TABLE `test` ( `name` varchar(20) DEFAULT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8; SET character_set_client = @saved_cs_client; -- -- Dumping data for table `test` -- LOCK TABLES `test` WRITE; /*!4 ALTER TABLE `test` DISABLE KEYS */; INSERT INTO `test` VALUES (0xe4bda0e5a5bd); INSERT INTO `test` VALUES (0xe68891e5a5bd); /*!4 ALTER TABLE `test` ENABLE KEYS */; UNLOCK TABLES; /*!40103 SET [EMAIL PROTECTED] */; /*!40101 SET [EMAIL PROTECTED] */; /*!40014 SET [EMAIL PROTECTED] */; /*!40014 SET [EMAIL PROTECTED] */; /*!40101 SET [EMAIL PROTECTED] */; /*!40101 SET [EMAIL PROTECTED] */; /*!40101 SET [EMAIL PROTECTED] */; /*!40111 SET [EMAIL PROTECTED] */; -- Dump completed on 2008-05-17 6:35:33 = -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