Re: [Resin-interest] Quercus Question
Hi,
I take advantage of the situation about this email to ask Caucho's team if
we are allowed to fork the project [Quercus] on GitHub to make our own
changes/bug fixes. The project seems to run slowly (*as looked on the bug
report*) and we are making some improvements for a production environment in
our internal team.
Thanks,
Kevin Decherf
Twitter : @Kdecherf http://twitter.com/Kdecherf
On Thu, Aug 12, 2010 at 6:19 PM, Aaron Freeman aaron.free...@layerz.comwrote:
The silence is deafening, so I guess I was completely wrong-headed in
thinking you could call a .jsp as in include from a .php?
Bummer, I was hoping that was part of the benefit of having php-based
apps running under full blown Resin, instead of Quercus in stand alone
mode.
Thanks,
Aaron
On 8/12/2010 1:36 AM, Aaron Freeman wrote:
I was thinking it's possible to do something like this in a php file:
?php
if((include '../www/_header.jsp') == 'OK') {
echo 'OK';
}
?
Where the www folder has a path-mapping entry in the resin.xml.
It includes the file, but the file isn't processed by the JSP engine, so
I literally see strings like ${param.var} in the output of the call to
test.php. How do I include a .jsp in from a .php but get the JSP engine
to process it before it returns? I know I could do something like:
include( 'http:///www/_header.jsp')
but then cookies are lost as the client is the php engine, not the
browser.
Is it possible to reuse the JSP code from within the PHP environment?
Is there a link someone could shoot me that explains this?
Thanks,
Aaron
___
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.9 release
Hi Jan, Did your resin server have a busy traffic? Did u observed any memory leak or heap overflow? -Wesley ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4.0.9 release
Hi Wesley, Did your resin server have a busy traffic? Did u observed any memory leak or heap overflow? neither nor. Best regards, --- Jan. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4.0.9 release
Out of curiosity do you have multiple instances of Resin (separate JVMs)
running on that same virtual machine? If so do you use different ports
for the watchdog on both instances? We had a similar situation and it
was fixed by just running the watchdog on separate ports for each
instance of Resin. Probably not your situation, but thought I'd ask.
Aaron
On 8/13/2010 12:27 AM, Jan Kriesten wrote:
Hi Scott,
I've put up a new snapshot. On a restart, you should see additional
logging information in both the watchdog-manager.log and the
jvm-default.log that should help narrow this down.
the only new entry in the log on restart in the jvm-default.log is this:
06:44:16.969] {main} ProResin[id=] started in 81883ms
WarningService: Stopping Resin because ping did not complete in time.
[07:13:56.772] {resin-shutdown} ProServer[id=,cluster=app-tier] stopping
Shutdown Resin reason: HEALTH
Almost the same is showing up in watchdog-manager.log:
[2010/08/13 07:13:56.816] Watchdog received warning from Resin[1,pid=32039]:
Stopping Resin because ping did not complete
in time.
[2010/08/13 07:13:58.579] Watchdog detected close of Resin[,pid=32039]
exit reason: HEALTH (exit code=8)
[2010/08/13 07:13:58.579] Watchdog starting Resin[]
It's really strange, though, that it happens almost exactly every 30
minutes. The behavior didn't occor with 4.0.7 or previous versions.
Best regards, --- Jan.
___
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 Aaron, Out of curiosity do you have multiple instances of Resin (separate JVMs) running on that same virtual machine? If so do you use different ports for the watchdog on both instances? We had a similar situation and it was fixed by just running the watchdog on separate ports for each instance of Resin. Probably not your situation, but thought I'd ask. no, it's just one instance. Best regards, --- Jan. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4.0.9 release
Jan Kriesten wrote:
Hi Scott,
I've put up a new snapshot. On a restart, you should see additional
logging information in both the watchdog-manager.log and the
jvm-default.log that should help narrow this down.
the only new entry in the log on restart in the jvm-default.log is this:
06:44:16.969] {main} ProResin[id=] started in 81883ms
WarningService: Stopping Resin because ping did not complete in time.
[07:13:56.772] {resin-shutdown} ProServer[id=,cluster=app-tier] stopping
Shutdown Resin reason: HEALTH
Almost the same is showing up in watchdog-manager.log:
[2010/08/13 07:13:56.816] Watchdog received warning from Resin[1,pid=32039]:
Stopping Resin because ping did not complete
in time.
[2010/08/13 07:13:58.579] Watchdog detected close of Resin[,pid=32039]
exit reason: HEALTH (exit code=8)
[2010/08/13 07:13:58.579] Watchdog starting Resin[]
Excellent. That's exactly the kind of information I was hoping the log
would provide.
The HEALTH is an exit caused by a failed ping/health check. If Resin had
detected an OOM or thread problem, the watchdog log would have shown
MEMORY or THREAD.
It's really strange, though, that it happens almost exactly every 30
minutes. The behavior didn't occor with 4.0.7 or previous versions.
As a workaround, you can disable the ping (or PingThread) until I
figure out why that's happening.
-- Scott
Best regards, --- Jan.
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Session object casting - resin 4.0.7
I am running resin 4.0.7 and I store a user object in the session using User_Bean as a key. Everything works fine most of the time but it seems when my session expires and I have not logged out, every subsequent call to get this object returns some HashMap instead of my object or null. Since I am casting the object when I retrieve it from the session the message I get is: java.lang.ClassCastException: java.util.HashMap cannot be cast to com.ordinate.ppass.beans.UserBean Is there some reason why getting an object from the session would return a Map instead of the object? Is User_Bean some reserved word or something? The only way I have been able to get my application working again is to shutdown the server, delete everything in the resin-data folder and restart (deleting the exploded war, deploying the app again, restarting all do not work). Also, this seems to happen on resin 4.0.9 as well. thanks matt ___ 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
Wesley Wu wrote: 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.DefaultBeanManager11,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? I'll check. Do you know what the path to root is for those objects? -- 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] [ANN]VTD-XML 2.9
VTD-XML 2.9, the next generation XML Processing API for SOA and Cloud computing, has been released. Please visit https://sourceforge.net/projects/vtd-xml/files/ to download the latest version. a.. Strict Conformance a.. VTD-XML now fully conforms to XML namespace 1.0 spec b.. Performance Improvement a.. Significantly improved parsing performance for small XML files c.. Expand Core VTD-XML API a.. Adds getPrefixString(), and toNormalizedString2() d.. Cutting/Splitting a.. Adds getSiblingElementFragment() e.. A number of bug fixes and code enhancement including: a.. Fixes a bug for reading very large XML documents on some platforms b.. Fixes a bug in parsing processing instruction c.. Fixes a bug in outputAndReparse() ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Possible memory leak in Resin 4.0.9
Hi Scott, The memory leak circumstance was not spotted in Resin 4.0.5 and early 4.0.x versions. One of the inject path is: * A filter CmsPageFilter dispatch a request to a Jsp page through javax.servlet.RequestDispatcher.forward(request, response) * Jsp page called a BeanMethod custom jsp tag * The jsp tag create a VideoManager through my BeanManager wrapper (MDIObjectFactory) * VideoManager injects a PersonManager * PersonManager injects a PersonController * PersonController injects a DefaultBeanManager and a DefaultBeanReader * DefaultBeanManager and DefaultBeanReader inject a CmsPersistentUnit(@Singleton) * CmsPersistentUnit injects a javax.persistence.EntityManagerFactory (@PersistenceUnit) All those beans except CmsPersistentUnit were dependent scoped (not explicitly annotated) and should be created at its inject point and freed when the parent bean (the jsp page) was destroyed. I list three most frequently bean creation process here. #handle jsp tag which requires bean creation=== # this call should be the creation of an @Dependent (thought not explicitly annotated) beans # like com.buysou.cms.managers.DefaultBeanManager or com.buysou.cms.managers.DefaultBeanReader # (for writing/reading database through a @RequestScoped @PersistentContext) com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, CreationalContextImpl, InjectionPoint) 118 com.caucho.config.inject.InjectionTargetBuilder$FieldInjectProgram.inject(Object, CreationalContext) 117 com.caucho.config.inject.CandiProducer.inject(Object, CreationalContext) 117 com.caucho.config.inject.InjectionTargetBuilder.inject(Object, CreationalContext) 117 com.caucho.config.inject.ManagedBeanImpl.createDependent(CreationalContext) 117 com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, CreationalContextImpl, InjectionPoint) 117 com.caucho.config.inject.InjectionTargetBuilder$FieldInjectProgram.inject(Object, CreationalContext) 114 com.caucho.config.inject.CandiProducer.inject(Object, CreationalContext) 114 com.caucho.config.inject.InjectionTargetBuilder.inject(Object, CreationalContext) 114 com.caucho.config.inject.ManagedBeanImpl.createDependent(CreationalContext) 114 com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, CreationalContextImpl, InjectionPoint) 114 com.caucho.config.inject.InjectionTargetBuilder$FieldInjectProgram.inject(Object, CreationalContext) 112 com.caucho.config.inject.CandiProducer.inject(Object, CreationalContext) 112 com.caucho.config.inject.InjectionTargetBuilder.inject(Object, CreationalContext) 112 com.caucho.config.inject.ManagedBeanImpl.createDependent(CreationalContext) 111 com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, CreationalContextImpl, InjectionPoint) 111 com.caucho.config.inject.InjectionTargetBuilder$FieldInjectProgram.inject(Object, CreationalContext) 103 com.caucho.config.inject.CandiProducer.inject(Object, CreationalContext) 103 com.caucho.config.inject.InjectionTargetBuilder.inject(Object, CreationalContext) 103 com.caucho.config.inject.ManagedBeanImpl.createDependent(CreationalContext) 103 com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, CreationalContextImpl, InjectionPoint) 103 com.caucho.config.inject.InjectionTargetBuilder$FieldInjectProgram.inject(Object, CreationalContext) 89 com.caucho.config.inject.CandiProducer.inject(Object, CreationalContext) 89 com.caucho.config.inject.InjectionTargetBuilder.inject(Object, CreationalContext) 89 com.caucho.config.inject.ManagedBeanImpl.createDependent(CreationalContext) 88 com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, CreationalContextImpl, InjectionPoint) 88 com.caucho.config.inject.InjectionTargetBuilder$FieldInjectProgram.inject(Object, CreationalContext) 60 com.caucho.config.inject.CandiProducer.inject(Object, CreationalContext) 60 com.caucho.config.inject.InjectionTargetBuilder.inject(Object, CreationalContext) 60 com.caucho.config.inject.ManagedBeanImpl.createDependent(CreationalContext) 58 com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, CreationalContextImpl, InjectionPoint) 58 com.caucho.config.inject.InjectionTargetBuilder$FieldInjectProgram.inject(Object, CreationalContext) 34 com.caucho.config.inject.CandiProducer.inject(Object, CreationalContext) 34 com.caucho.config.inject.InjectionTargetBuilder.inject(Object, CreationalContext) 34 com.caucho.config.inject.ManagedBeanImpl.createDependent(CreationalContext) 33 com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl,
Re: [Resin-interest] Possible memory leak in Resin 4.0.9
My BeanManager wrapper code
@Singleton
@Startup
public class MDIObjectFactory {
private static BeanManager beanManager;
private static BeanManager getBeanManager() {
if (beanManager == null) {
try {
InitialContext ic = new InitialContext();
beanManager = (BeanManager)
ic.lookup(java:comp/BeanManager);
} catch (Exception e) {
throw new RuntimeException(e);
}
}
return beanManager;
}
...
public T T buildBean(ClassT beanClass) {
Named named = beanClass.getAnnotation(Named.class);
if (named != null) {
BeanT bean = (BeanT)
beanManager.resolve(beanManager.getBeans(named.value()));
CreationalContextT env =
beanManager.createCreationalContext(bean);
return (T) beanManager.getReference(bean,
bean.getBeanClass(), env);
}
BeanT bean = (BeanT)
beanManager.resolve(beanManager.getBeans(beanClass));
CreationalContextT env =
beanManager.createCreationalContext(bean);
return (T) beanManager.getReference(bean, beanClass, env);
}
public Object buildBean(String beanName) {
Bean bean = beanManager.resolve(beanManager.getBeans(beanName));
CreationalContext env =
beanManager.createCreationalContext(bean);
return beanManager.getReference(bean, bean.getBeanClass(), env);
}
...
}
-Wesley
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4.0.9 release
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Scott,
As a workaround, you can disable the ping (or PingThread) until I
figure out why that's happening.
as an idea, I have the following in resin.xm from an old default:
resin:if test=${resin.professional}
ping
!-- urlhttp://localhost:8080/test-ping.jsp/url --
/ping
/resin:if
So the ping configuration is actually empty. Maybe this is treated
differently with the latest releases?
Best regards, --- Jan.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (Darwin)
iEYEARECAAYFAkxmGGAACgkQME/SSH3iSFkYowCcCj+0AiAHnN01VI1tuE6TeleF
AC8An0JWk3kVZq5eNtlXuGVZAbkpdggl
=neMZ
-END PGP SIGNATURE-
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
