[Resin-interest] JPA 2.1 (was Re: Resin 4 and Java 8)
This is my workaround for JPA 2.1 on Resin. We've had to put that
upgrade aside for a while now so it hasn't been thoroughly tested and
there may be bumps down the road, but at least this allowed us to boot :-/
/** Remove Caucho's JPA implementation Amber - included in Resin -
from the list of registered persistence providers. */
public static void removeAmberPersistenceProvider() {
final PersistenceProviderResolver persistenceProviderResolver =
PersistenceProviderResolverHolder.getPersistenceProviderResolver();
persistenceProviderResolver.getPersistenceProviders(); // Make sure
the persistence provider cache has been initialized
final MapClassLoader, PersistenceProviderResolver resolvers =
(MapClassLoader, PersistenceProviderResolver)
ReflectionUtils.getPrivateField(persistenceProviderResolver, resolvers);
PersistenceProviderResolver clPersistenceProviderResolver =
resolvers.get(Thread.currentThread().getContextClassLoader());
final ListWeakReferenceClass? extends PersistenceProvider
resolverClasses = (ListWeakReferenceClass? extends
PersistenceProvider)
ReflectionUtils.getPrivateField(clPersistenceProviderResolver,
resolverClasses);
IteratorWeakReferenceClass? extends PersistenceProvider iter
= resolverClasses.iterator();
while(iter.hasNext()) {
WeakReferenceClass? extends PersistenceProvider ref =
iter.next();
if(ref.get() != null
com.caucho.amber.manager.AmberPersistenceProvider.equals(ref.get().getName()))
{
iter.remove();
}
}
}
- Original Message -
Subject: Re: [Resin-interest] [Resin] Resin 4 and Java 8
Date: Tue, 24 Mar 2015 12:44:17 -0700
From: Chris Pratt thechrispr...@gmail.com
I'm basically having the same problem that is outlined in the previous
resin-interest pose (
https://www.mail-archive.com/resin-interest@caucho.com/msg06062.html) and
on Stack Overflow (
http://stackoverflow.com/questions/26352912/jpa-2-1-not-loaded-in-resin-3-1-9),
but I'm using the latest Resin (4.0.43). I've tried following the
instructions in the sited caucho bug report (
http://bugs.caucho.com/view.php?id=5678), but I still get the same
exception. Any pointers would definitely be appreciated.
(*Chris*)
On Tue, Mar 24, 2015 at 11:37 AM, Nam Nguyen n...@caucho.com wrote:
Message: 2
Date: Tue, 24 Mar 2015 16:40:20 +
From: Chris Prattthechrispr...@gmail.com
Subject: Re: [Resin-interest] [Resin] Resin 4 and Java 8
To: General Discussion for the Resin application server
resin-interest@caucho.com
Message-ID:
CAALdY0z9yi0VE=Ac1_4U0hD7Ti74zdeEEu8=
r3riz_xjxv4...@mail.gmail.com
Content-Type: text/plain; charset=utf-8
Yes, I have it working just fine on Java 8. But, I can't seem to
get it
working with the new JPA 2.1 (from Hibernate 4.3).
(*Chris*)
Resin works with Java8. Chris, can you elaborate on the issue you are
having with JAP 2.1?
Thanks,
-- Nam
___
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
--
/Mattias
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Network based security behind Apache (X-Forwarded-For)
Duh, should have read http://www.caucho.com/resin-4.0/admin/security-authorization.xtp to the end... - Original Message - Subject: [Resin-interest] Network based security behind Apache (X-Forwarded-For) Date: Fri, 30 Jan 2015 08:35:14 +0100 From: Mattias Jiderhamn mj-li...@expertsystems.se Hi list. What options do I have if I want to use IP based security behind an Apache proxy? I want to use ip-constraint or resin:IfNetwork, but request.getRemoteAddr() will always be the IP of the proxy, and the real IP is in X-Forwarded-For header. It seems I cannot put a Servlet filter in front of Resins SecurityFilterChain (in which I could have wrapped the request and overriden getRemoteAddr())? Can I add custom com.caucho.rewrite.RequestPredicate implementations to the SecurityFilterChain somehow...??? -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Network based security behind Apache (X-Forwarded-For)
Hi list. What options do I have if I want to use IP based security behind an Apache proxy? I want to use ip-constraint or resin:IfNetwork, but request.getRemoteAddr() will always be the IP of the proxy, and the real IP is in X-Forwarded-For header. It seems I cannot put a Servlet filter in front of Resins SecurityFilterChain (in which I could have wrapped the request and overriden getRemoteAddr())? Can I add custom com.caucho.rewrite.RequestPredicate implementations to the SecurityFilterChain somehow...??? -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] JPA 2.1 + Resin
My request to update the bundled JPA API to 2.1, or at least extract the JAR for easy replacement (http://bugs.caucho.com/view.php?id=5678) was turned down with reference to the server-default / jvm-classpath config option. I have finally gotten around to trying this, with the Hibernate JPA 2.1 API (which is the only implementation I know of). The classpath is indeed overridden, however it does not work due to the Amber implementation, even if unused. This is because AmberPersistenceProvider.getProviderUtil() returns null, and the javax.persistence.PersistenceUtil implementation assumes that the ProviderUtil of all providers are non-null. I have been able to deregister Amber from the PersistenceProviderResolver using reflection, but again, this would have been sooo much easier if only there was a separate JAR. A separate JAR would also have avoided the problem with the fact that the jvm-classpath config assumes the server is spawned by the watchdog, and thus does not work with the IntelliJ IDEA plugin, that doesn't support explicitly reordering JARs. -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Resin development progress
I have a couple of outstanding issues in Mantis (that I have not posted about on the mailing list), that seems to have gotten no attention from Caucho at all. The oldest one is almost 5 months. Actually, I'm getting the impression that the development of Resin has slowed down considerably in the last year or so. The version history / change log (http://caucho.com/resin-4.0/changes/changes.xtp) confirms this. The no of releases per year has decreased from 11 releases in 2011 and 9 in 2012 to 5 last year and none so far this year. Would you please care to inform the community what Cauchos current focus and intention for Resin is, and what the release schedule for 2014 looks like? Oh, btw these are the issues I'm talking about. From my point of view most if not all of them seems trivial to fix, which makes you wonder even more. http://bugs.caucho.com/view.php?id=5587 http://bugs.caucho.com/view.php?id=5592 http://bugs.caucho.com/view.php?id=5647 http://bugs.caucho.com/view.php?id=5652 http://bugs.caucho.com/view.php?id=5678 -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Order of web-fragment.xml vs .tld
Hi list. It seems that Resin will load and initiate Servlet 3.0 web-fragment.xml before it loads and initiates any .tld files - including listeners therein - within the same .jar. This results in the AutoProbe module of http://messadmin.sourceforge.net/ causing exceptions, because it assumes the servlet context listener defined in it's taglib-autoprobe.tld has had it's contextInitialized() called before the filter in web-fragment.xml has it's init() called. This works fine in JBoss, and I'm wondering if anyone knows what the specs has to say about this? Is Resin at fault, or could MessAdmin be relying on something that simply is not defined by specs? Hi Mattias, I am filing a bug for this: http://bugs.caucho.com/view.php?id=5659 , thanks for reporting! Can you try redefining the listener in your application’s web.xml as a work around? For the record, as a workaround removing the AutoProbe module altogether and define both listener and filter in web.xml works fine. -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Order of web-fragment.xml vs .tld
Hi list. It seems that Resin will load and initiate Servlet 3.0 web-fragment.xml before it loads and initiates any .tld files - including listeners therein - within the same .jar. This results in the AutoProbe module of http://messadmin.sourceforge.net/ causing exceptions, because it assumes the servlet context listener defined in it's taglib-autoprobe.tld has had it's contextInitialized() called before the filter in web-fragment.xml has it's init() called. This works fine in JBoss, and I'm wondering if anyone knows what the specs has to say about this? Is Resin at fault, or could MessAdmin be relying on something that simply is not defined by specs? -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Maven repo
Has the Caucho Maven repo moved from http://caucho.com/m2 to somewhere else? Or has it simply not been updated in a year and a half (latest version is 4.0.30)? In the latter case - why...? -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] ExtensionManager is drive letter case sensitive
Since http://bugs.caucho.com/ is down currently, I'm posting this bug here.
When running Resin 4.0.37 under Windows, I am getting problem with the
same extension being loaded twice by
com.caucho.config.extension.ExtensionManager. The reason for this is
that in the EnumerationURL e on line 133 the same path is represented
twice, with different casing on the drive letter. I.e. it contains both
jar:file:/C:/foo/resin-pro-4.0.37/lib/jsf-impl-2.2.4.jar!/META-INF/services/javax.enterprise.inject.spi.Extension
and
jar:file:/c:/foo/resin-pro-4.0.37/lib/jsf-impl-2.2.4.jar!/META-INF/services/javax.enterprise.inject.spi.Extension
In the particular case, this results in an exception as of below and
Resin refused to boot at all.
The workaround that I have found so far is to set the RESIN_HOME
environment varible with the driver letter in upper case. With lower
case drive letter or RESIN_HOME unset, the duplicates appear.
Here is the exception in our case:
com.caucho.config.ConfigException: @Named('csfFLOWDISCOVERYCDIHELPER')
is a duplicate name for ManagedBeanImpl[FlowDiscoveryCDIHelper,
{@javax.inject.Named(value=csfFLOWDISCOVERYCDIHELPER), @Default(),
@Any()}, name=csfFLOWDISCOVERYCDIHELPER]
ManagedBeanImpl[FlowDiscoveryCDIHelper,
{@javax.inject.Named(value=csfFLOWDISCOVERYCDIHELPER), @Default(),
@Any()}, name=csfFLOWDISCOVERYCDIHELPER]
at
com.caucho.config.inject.InjectManager.addBeanByName(InjectManager.java:729)
at
com.caucho.config.inject.InjectManager.addBeanImpl(InjectManager.java:1392)
at
com.caucho.config.inject.InjectManager.addBean(InjectManager.java:1341)
at
com.caucho.config.extension.BeforeBeanDiscoveryImpl.addAnnotatedType(BeforeBeanDiscoveryImpl.java:61)
at
com.sun.faces.flow.FlowDiscoveryCDIExtension.beforeBeanDiscovery(FlowDiscoveryCDIExtension.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
com.caucho.config.extension.ExtensionManager$ExtensionObserver.notify(ExtensionManager.java:688)
at
com.caucho.config.event.EventManager.fireLocalEvent(EventManager.java:300)
at
com.caucho.config.event.EventManager.fireLocalEvent(EventManager.java:289)
at
com.caucho.config.event.EventManager.fireExtensionEvent(EventManager.java:273)
at
com.caucho.config.extension.ExtensionManager.fireBeforeBeanDiscovery(ExtensionManager.java:498)
at
com.caucho.config.inject.InjectManager.fireBeforeBeanDiscovery(InjectManager.java:3205)
at
com.caucho.config.inject.InjectManager.addBeanDiscover(InjectManager.java:1303)
at
com.caucho.config.inject.InjectManager.addBeanDiscover(InjectManager.java:1283)
at com.caucho.env.service.ResinSystem.init(ResinSystem.java:145)
at com.caucho.env.service.ResinSystem.init(ResinSystem.java:99)
at com.caucho.server.resin.Resin.init(Resin.java:236)
at com.caucho.server.resin.Resin.init(Resin.java:182)
at com.caucho.server.resin.Resin.main(Resin.java:1436)
--
/Mattias
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Resin and java:comp/ValidatorFactory
Resin ships with Hibernate Validator. I'm trying to figure out whose responsibility is it to make the ValidatorFactory exposed in JNDI as java:comp/ValidatorFactory. What we are really trying to do is using JSF 2.2 with Resin, and then Bean Validation is disabled since JSF is unable to find the factory at java:comp/ValidatorFactory (where JSF 2.1 explicitly called Validation.buildDefaultValidatorFactory()). Seems to work fine using JBoss. So is this a bug with Resin, that java:comp/Validator and java:comp/ValidatorFactory are not available by default...? -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] JSF classloader leak triggered by Resin EL
On Thu, 18 Jul 2013 10:51:52 -0700 Scott wrote: On 7/18/13 10:29 AM, Mattias Jiderhamn wrote: On Thu, 18 Jul 2013 09:42:23 -0700 Scott wrote: On 7/18/13 2:32 AM, Mattias Jiderhamn wrote: It seems that a classloader leak in the JSF API as of https://java.net/jira/browse/JAVASERVERFACES-2746 is triggered much more easily by the Caucho EL implementation than with the Sun/Glassfish one. At least from my point of view the bug still is with JSF and not Resin, but somene might find this information useful. Hmm. I'm not sure why Resin's EL would make a difference. From that description, it's a JSF bug. Do you happen to know what classes are being held? Yes. The bug is triggered when there are additional attributes added to the cached PropertyDescriptors, that implies a strong reference to the classloader. The cases I've seen involves having the javax.el.ELResolver.TYPE (=type) attribute having a class loaded within the webapp as it's value (i.e. a custom JSF component with a custom attribute). Resin adds this attribute in BeanELResolver.java line 520 (Resin 4.0.33), reached from the javax.el.BeanELResolver.BeanProperty constructors in turn called from the javax.el.BeanELResolver.BeanProperties constructor which in the Resin case is used in all five BeanELResolver methods mentioned in my latest comment. In the case of Sun/Glasfish EL, this attribute is (AFAI can see) only added by getFeatureDescriptors(). Nevertheless, I agree that it is JSF that needs fixing, not Resin. Gotcha. I can make that initialization lazy. That will only initialize the reference for getFeatureDescriptors(). The leak is already taken care of by my classloader leak prevention library [1] for any EL implementation, so there is no need on our part, but it might help someone else that don't understand the crashes or is unable to find this discussion. 1: http://java.jiderhamn.se/2012/03/04/classloader-leaks-vi-this-means-war-leak-prevention-library/ -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] JSF classloader leak triggered by Resin EL
On Thu, 18 Jul 2013 09:42:23 -0700 Scott wrote: On 7/18/13 2:32 AM, Mattias Jiderhamn wrote: It seems that a classloader leak in the JSF API as of https://java.net/jira/browse/JAVASERVERFACES-2746 is triggered much more easily by the Caucho EL implementation than with the Sun/Glassfish one. At least from my point of view the bug still is with JSF and not Resin, but somene might find this information useful. Hmm. I'm not sure why Resin's EL would make a difference. From that description, it's a JSF bug. Do you happen to know what classes are being held? Yes. The bug is triggered when there are additional attributes added to the cached PropertyDescriptors, that implies a strong reference to the classloader. The cases I've seen involves having the javax.el.ELResolver.TYPE (=type) attribute having a class loaded within the webapp as it's value (i.e. a custom JSF component with a custom attribute). Resin adds this attribute in BeanELResolver.java line 520 (Resin 4.0.33), reached from the javax.el.BeanELResolver.BeanProperty constructors in turn called from the javax.el.BeanELResolver.BeanProperties constructor which in the Resin case is used in all five BeanELResolver methods mentioned in my latest comment. In the case of Sun/Glasfish EL, this attribute is (AFAI can see) only added by getFeatureDescriptors(). Nevertheless, I agree that it is JSF that needs fixing, not Resin. -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] help on resizing image
We use JAI in one of our web apps. Have you set system properties java.awt.headless=true and java.awt.headlesslib=true ...? (Btw, for full performance, you should install JNI binaries. Thought that wouldn't be 100% Java either. And I haven't tried it.) /Mattias - Original Message - Subject: [Resin-interest] help on resizing image Date: Thu, 07 Feb 2013 11:14:00 +0100 From: Riccardo Cohen r.co...@realty-property.com Hello On my web application, I need to resize images sent via multipart forms. When I try a console application using awt on my mac (see attached code), the console application starts a real Mac application with window and menu, while my code is only calling non-gui functions (ImageIO.read...) . I'm really affraid to add this code on my server, and I wonder if this may have impact on memory, performance and stability of the server. I would rather prefer a little imaging library like jmagick or gd for java, small and efficient. It's not 100% java but it does not create windows and menus... What do you use to resize images on the server size ? Thanks a lot. -- Riccardo Cohen +33 (0)6 09 83 64 49 Société Realty-Property.com 1 rue de la Monnaie 37000 Tours France http://www.appartement-maison.fr ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Disable archive/rollback?
Is it possible to completely disable deployment archiving as described
on http://www.caucho.com/resin-4.0/admin/deploy.xtp?
Or at least disable the undocumented(?) automatic rollback?
Background: We made some configuration changes that seemed to work fine,
but turned out to be invalid. Trying to deploying a new .war resulted in
getting the contents of the previous one in the exploaded dir. Changing
config back did not help. Upon further examination of the logs, there
was an error (see below) which might itself be some kind of bug in Resin
(version 4.0.29). Fortunately I remembered having similar symptoms a
while back and then spent loads of time before we found and deleted the
.git directory under resin-data. We tried that again and then was able
to boot our application.
We would prefer disabling the archive + rollback feature altogether, as
in our case it seems only to cause confusion and problems.
The error:
[11:48:26.865] {main} java.lang.IllegalStateException:
'ddd10c59a0204e29d950c6dc5c863d4a24c59ef5' has an unknown type null
at
com.caucho.env.repository.RepositoryTagMap.init(RepositoryTagMap.java:151)
at
com.caucho.env.repository.AbstractRepository.addTagData(AbstractRepository.java:345)
at
com.caucho.env.repository.FileRepository.putTag(FileRepository.java:104)
at
com.caucho.env.repository.AbstractRepository.commitArchive(AbstractRepository.java:243)
at
com.caucho.env.deploy.ExpandDeployController.commitArchive(ExpandDeployController.java:510)
at
com.caucho.env.deploy.ExpandDeployController.extractApplication(ExpandDeployController.java:383)
at
com.caucho.env.deploy.ExpandDeployController.preConfigureInstance(ExpandDeployController.java:340)
at
com.caucho.env.deploy.DeployController.startImpl(DeployController.java:674)
at
com.caucho.env.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAutoRedeployAutoStrategy.java:77)
at
com.caucho.env.deploy.DeployController.startOnInit(DeployController.java:530)
at
com.caucho.env.deploy.DeployContainer.start(DeployContainer.java:170)
at
com.caucho.server.webapp.WebAppContainer.start(WebAppContainer.java:728)
at com.caucho.server.host.Host.start(Host.java:677)
at
com.caucho.env.deploy.DeployController.startImpl(DeployController.java:680)
at
com.caucho.env.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAutoRedeployAutoStrategy.java:77)
at
com.caucho.env.deploy.DeployController.startOnInit(DeployController.java:530)
at
com.caucho.env.deploy.DeployContainer.start(DeployContainer.java:170)
at
com.caucho.server.host.HostContainer.start(HostContainer.java:542)
at
com.caucho.server.cluster.ServletService.start(ServletService.java:1337)
at
com.caucho.server.cluster.ServletSystem.start(ServletSystem.java:72)
at
com.caucho.env.service.ResinSystem.startServices(ResinSystem.java:529)
at
com.caucho.env.service.ResinSystem.start(ResinSystem.java:496)
at
com.caucho.server.resin.Resin.start(Resin.java:817)
at
com.caucho.server.resin.Resin.initMain(Resin.java:949)
at
com.caucho.server.resin.Resin.main(Resin.java:1398)
--
/Mattias
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] System.getenv() behaves differently
I have noticed that System.getenv() behaves differently on our different Linux servers. When running stand-alone Java applications there is no issue, but on at least one server the environment variables are inherited from the watchdog process to the Resin process, and on others they are not. This can be verified with -verbose when starting Resin. I cannot find any difference in the setup (startup script + config), but on the other hand I'm not sure what I should be looking for. Any ideas? (Resin version is 4.0.29) -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Easing Development
I have reported a classloader / memory leak that I believe Scott tried to fix for 4.0.33. Haven't had time to verify yet though. Then add this library to your web app, to get rid of third party leaks: http://java.jiderhamn.se/2012/03/04/classloader-leaks-vi-this-means-war-leak-prevention-library/ /Mattias - Original Message - Subject: Re: [Resin-interest] Easing Development Date: Fri, 4 Jan 2013 04:31:03 -0800 From: Rick Mann rm...@latencyzero.com I actually deliberately restart resin quite frequently. ... Add to that a persistent leak that causes resin to gobble up memory after a few app reloads, and it's best (for me) to restart resin frequently. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] 4.0.33 ETA?
Any news on the 4.0.33 release? /Mattias --- Original Message - Subject: Re: [Resin-interest] 4.0.33 ETA? Date: Thu, 22 Nov 2012 10:17:29 -0500 From: Paul Cowan co...@caucho.com On Nov 22, 2012, at 2:46 AM, Mattias Jiderhamn wrote: Hi. We are anticipating the upcoming 4.0.33 release that should resolve a couple of our bugs. What is the ETA? We are shooting for next week for 4.0.33 release. Depending on the regressions, it could slip until the 1st week of December but probably no later than that. -- ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] 4.0.33 ETA?
Hi. We are anticipating the upcoming 4.0.33 release that should resolve a couple of our bugs. What is the ETA? -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Resin 4.0.30+ NotSerializableException: com.caucho.el.MethodExpr$MethodCall
Without having had time to look into it further, I'm wondering if anyone else has seen these exceptions moving from Resin 4.0.29 to 4.0.30 (same problem with 4.0.31 for us)? Any workaround? Caused by: java.io.NotSerializableException: com.caucho.el.MethodExpr$MethodCall at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1164) ~[na:1.6.0_30] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330) ~[na:1.6.0_30] at java.util.concurrent.ConcurrentHashMap.writeObject(ConcurrentHashMap.java:1247) ~[na:1.6.0_30] at sun.reflect.GeneratedMethodAccessor160.invoke(Unknown Source) ~[na:na] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) ~[na:1.6.0_30] at java.lang.reflect.Method.invoke(Method.java:597) ~[na:1.6.0_30] at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945) ~[na:1.6.0_30] at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1469) ~[na:1.6.0_30] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400) ~[na:1.6.0_30] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) ~[na:1.6.0_30] at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518) ~[na:1.6.0_30] at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483) ~[na:1.6.0_30] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400) ~[na:1.6.0_30] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) ~[na:1.6.0_30] at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518) ~[na:1.6.0_30] at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483) ~[na:1.6.0_30] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400) ~[na:1.6.0_30] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) ~[na:1.6.0_30] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330) ~[na:1.6.0_30] at com.sun.faces.facelets.el.TagValueExpression.writeExternal(TagValueExpression.java:186) ~[javax.faces-2.1.11.jar:2.1.11] at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1429) ~[na:1.6.0_30] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1398) ~[na:1.6.0_30] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) ~[na:1.6.0_30] at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518) ~[na:1.6.0_30] at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483) ~[na:1.6.0_30] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400) ~[na:1.6.0_30] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) ~[na:1.6.0_30] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330) ~[na:1.6.0_30] at java.util.ArrayList.writeObject(ArrayList.java:570) ~[na:1.6.0_30] at sun.reflect.GeneratedMethodAccessor72.invoke(Unknown Source) ~[na:na] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) ~[na:1.6.0_30] at java.lang.reflect.Method.invoke(Method.java:597) ~[na:1.6.0_30] at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945) ~[na:1.6.0_30] at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1469) ~[na:1.6.0_30] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400) ~[na:1.6.0_30] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) ~[na:1.6.0_30] at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1346) ~[na:1.6.0_30] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1154) ~[na:1.6.0_30] at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1346) ~[na:1.6.0_30] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1154) ~[na:1.6.0_30] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330) ~[na:1.6.0_30] at java.util.HashMap.writeObject(HashMap.java:1001) ~[na:1.6.0_30] at sun.reflect.GeneratedMethodAccessor155.invoke(Unknown Source) ~[na:na] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) ~[na:1.6.0_30] at java.lang.reflect.Method.invoke(Method.java:597) ~[na:1.6.0_30] at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945) ~[na:1.6.0_30] at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1469) ~[na:1.6.0_30] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400) ~[na:1.6.0_30] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) ~[na:1.6.0_30] at
[Resin-interest] Up-to-date remote deploy strategy
What is the current recommended approach for remote deploying from Hudson/Jenkins to recent Resin versions (4.0.29+)? It looks like the resin-maven-plugin [1] (which may have been preferable) has been abandoned? Latest version is 4.0.17 and does not seem to be working. Is command line deploy [2] the latest and greatest? What would be the recommended approach for invoking from Hudson/Jenkins? exec-maven-plugin with exec:java or exec:exec? Is the same Resin version required on both machines? 1: http://caucho.com/resin-4.0/admin/deploy-ant-maven.xtp 2: http://caucho.com/resin-4.0/admin/deploy-command-line.xtp -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Old files not removed at redeploy
We're in the process of setting up a new server and have installed Resin 4.0.29 from RPM. We have made minimal changes to the config to get up and running, and are facing an issue we haven't seen on any other Resin installation: When a .war is redeployed it seems the contents of the new .war is extracted, although the old content is not removed. This means, for example, if a JAR file is updated from foo-1.0.jar to foo-1.1.jar, when deployed on the new server we will have both foo-1.0.jar and foo-1.1.jar (and thus foo-1.0.jar will be used and this causes problems). Restarting Resin doesn't help. Once a file ends up in the expanded directory, I can only get rid of it by manual delete. Resin is currently running as root, so I can't really see how it could be an access issue. I have increased Resin logging but can't find anything abnormal in there. Are there any settings that can affect this? Anything I should look for in the log? (Any particular Resin package I should limit the logging to?) -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] javax Validation provider change between 4.0.23 and 4.0.30?
- Original Message - Subject: [Resin-interest] javax Validation provider change between 4.0.23 and 4.0.30? Date: Tue, 28 Aug 2012 03:42:24 -0700 From: Rick Mann rm...@latencyzero.com I just built a new webapp that uses javax Validation. It works on my local machine with 4.0.30, but doesn't work on my server with 4.0.23. I'm wondering if between those two, a validation provider was included in resin? The error I get on the server is: javax.validation.ValidationException: Unable to find a default provider Rick Hibernate validator implementation is under webapp-jars. Would you happen to have different classpath configs...? -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4 stability
- Original Message - Subject: [Resin-interest] Resin 4 stability Date: Thu, 19 Jul 2012 09:53:47 -0500 From: Aaron Freeman aaron.free...@layerz.com I just want to query the user community for what seems to be the most stable version of resin 4.0 out there? We have been developing and using Rein 4.0.23 and are pretty satisfied. Has anybody been using a later version in production and development and find it to be nice and stable? We're still on 4.0.23 in production 4.0.28 looked really promising, especially for JSF development, but then there was http://bugs.caucho.com/view.php?id=5120 Looking forward to evaluating 4.0.29! -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Set JSF response encoding
After a long debugging detour, I realized that response header of my JSF pages is set to Content-Type: text/html; charset=ISO-8859-1 while the content itself is UTF-8. I don't quite understand what sets ISO-8859-1 and why (although admittedly url-character-encoding is set to it). What is the most appropriate way to make the response UTF-8, alternatively undeclared encoding, preferrably for JSF pages only? -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Set JSF response encoding
Don't bother - that turned out to be the detour... /Mattias - Original Message - Subject: [Resin-interest] Set JSF response encoding Date: Wed, 27 Jun 2012 20:26:54 +0200 From: Mattias Jiderhamn mj-li...@expertsystems.se After a long debugging detour, I realized that response header of my JSF pages is set to Content-Type: text/html; charset=ISO-8859-1 while the content itself is UTF-8. I don't quite understand what sets ISO-8859-1 and why (although admittedly url-character-encoding is set to it). What is the most appropriate way to make the response UTF-8, alternatively undeclared encoding, preferrably for JSF pages only? -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] JNI timeout on multipart forms in 4.0.28
- Original Message - Subject: Re: [Resin-interest] JNI timeout on multipart forms in 4.0.28 Date: Wed, 20 Jun 2012 13:30:26 -0700 From: Scott Ferguson f...@caucho.com On 06/19/2012 02:18 PM, Scott Ferguson wrote: On 06/19/2012 01:13 AM, Mattias Jiderhamn wrote: - Original Message - Subject: Re: [Resin-interest] JNI timeout on multipart forms in 4.0.28 Date: Fri, 15 Jun 2012 11:29:12 +0200 From: Mattias Jiderhamnmj-li...@expertsystems.se I can recreate this quite easily, without any forwards. All that is needed is a large enough ( 75 parts) form. ... Were you able to recreate this? Not yet. I'm doing a bug list pass from oldest to newest. I should get to it in a day or two. Is this an SSL request? I'm duplicating it with OpenSSL, but it's an OpenSSL buffering issue (in combination with Resin's timeouts). It wouldn't affect non-SSL requests. You are right, problem only occurs with OpenSSL. Resin 4.0.25 works fine while 4.0.28 does not, with the same OpenSSL version. Does Resin 4.0.28 require a newer OpenSSL version than 4.0.25? -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] JNI timeout on multipart forms in 4.0.28
- Original Message - Subject: Re: [Resin-interest] JNI timeout on multipart forms in 4.0.28 Date: Fri, 15 Jun 2012 11:29:12 +0200 From: Mattias Jiderhamn mj-li...@expertsystems.se - Original Message - Subject: Re: [Resin-interest] JNI timeout on multipart forms in 4.0.28 Date: Thu, 14 Jun 2012 10:26:12 -0700 From: Scott Ferguson f...@caucho.com On 06/14/2012 08:21 AM, Mattias Jiderhamn wrote: I'm really glad Resin 4.0.28 is here since it resolves multiple issues we've been having lately. However, it seems a new critical issue may have been introduced since 4.0.25. I've filed this as http://bugs.caucho.com/view.php?id=5120 ... If you can create a tiny example POST that triggers the problem and send it, that should help track it down. I can recreate this quite easily, without any forwards. All that is needed is a large enough ( 75 parts) form. ... Were you able to recreate this? -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] JNI timeout on multipart forms in 4.0.28
I'm really glad Resin 4.0.28 is here since it resolves multiple issues we've been having lately. However, it seems a new critical issue may have been introduced since 4.0.25. When running on 64-bit Linux, compiled with --enable-64bit and --enable-ssl, and posting a multipart/form-data form without any file parts included, we're getting timeouts. See stacktrace below. We do not have any issues with - non-multipart forms - multipart forms containing file parts - multipart forms without file parts, when running on Windows Have there been any additional configuration parameters added, that might be worth trying out? Any other ideas? Thanks in advance. [2012-06-14 17:13:21.414] com.caucho.vfs.SocketTimeoutException: client timeout at com.caucho.vfs.JniStream.exception(JniStream.java:231) at com.caucho.vfs.JniStream.read(JniStream.java:83) at com.caucho.vfs.ReadStream.read(ReadStream.java:472) at com.caucho.server.http.ContentLengthStream.read(ContentLengthStream.java:75) at com.caucho.vfs.ReadStream.readBuffer(ReadStream.java:1239) at com.caucho.vfs.ReadStream.read(ReadStream.java:365) at com.caucho.vfs.MultipartStream.read(MultipartStream.java:420) at com.caucho.vfs.MultipartStream.read(MultipartStream.java:352) at com.caucho.vfs.ReadStream.readBuffer(ReadStream.java:1239) at com.caucho.vfs.ReadStream.readChar(ReadStream.java:571) at com.caucho.server.http.MultipartFormParser.parsePostData(MultipartFormParser.java:177) at com.caucho.server.http.AbstractCauchoRequest.parsePostQueryImpl(AbstractCauchoRequest.java:441) at com.caucho.server.http.AbstractCauchoRequest.parseQueryImpl(AbstractCauchoRequest.java:275) at com.caucho.server.http.AbstractCauchoRequest.getParts(AbstractCauchoRequest.java:232) at se.exder.servlet.ServletUtils.parseMultipart(ServletUtils.java:303) ... -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Out of PermGen space
- Original Message - Subject: Re: [Resin-interest] Out of PermGen space Date: Fri, 27 Apr 2012 11:23:41 +0200 From: Mattias Jiderhamn mj-li...@expertsystems.se I should also mention, that I have an open bug report on Resin 4.0.27 which seems to cause classloader leaks. http://bugs.caucho.com/view.php?id=5010 Has anyone had time to confirm this bug? It seems to be triggered more often when using JSF, so when developing JSF applications I need to restart the server over and over (no difference whether HotSwap is enabled or not). Would be happy to know if there is hope that this will be fixed. /Mattias In pretty much every heap dump I analyze for ZombieClassLoaderMarker these days, com.caucho.config.inject.InjectManager turns up somewhere in the path to root. Not sure if it will fix all the problems, but it sure would be interesting to try a Resin version without this issue. P.S. I did some experimenting with Resin Pro vs Open Source today, and on both found some strange paths leading to JNI Local com.caucho.env.thread2.ResinThread2. Disabling JNI (on Windows, removing resin_os.dll) seemed to postpone the crash (which again included InjectManager) substantially. Not enought statistics to draw conclustions, but there *may* be something fishy about the JNI connection under Windows. /Mattias -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Out of PermGen space
On 05/29/2012 12:27 PM, Mattias Jiderhamn wrote: - Original Message - Subject: Re: [Resin-interest] Out of PermGen space Date: Fri, 27 Apr 2012 11:23:41 +0200 From: Mattias Jiderhamnmj-li...@expertsystems.se I should also mention, that I have an open bug report on Resin 4.0.27 which seems to cause classloader leaks. http://bugs.caucho.com/view.php?id=5010 Has anyone had time to confirm this bug? It seems to be triggered more often when using JSF, so when developing JSF applications I need to restart the server over and over (no difference whether HotSwap is enabled or not). Would be happy to know if there is hope that this will be fixed. Do you have a trace to root on one of those? (We've finally found the bugtrack upload corruption issue, but haven't updated that server yet, so the current pngs aren't readable.) See http://jiderhamn.se/resin4027.png + http://jiderhamn.se/resin4027b.png Let me know if I can provide any additional info. /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Override EL implementation (help us stay with Resin)
- Original Message - Subject: Re: [Resin-interest] Override EL implementation (help us stay with Resin) Date: Mon, 23 Apr 2012 08:31:33 +0200 From: Mattias Jiderhamn mj-li...@expertsystems.se ... I reported http://bugs.caucho.com/view.php?id=5034 (which has a very easy workaround) and http://bugs.caucho.com/view.php?id=5035 (which should be no problem in production, but make development much less effective; trivial to fix so I trust it to be in the next release) Thanks. Unfortunately I was able to reproduce this one too: http://bugs.caucho.com/view.php?id=5039 This one is a bit more annoying, since the workaround requires adding dummy setters everywhere the bug is hit. And here is another one: http://bugs.caucho.com/view.php?id=5061 Seems like an easy fix. -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Out of PermGen space
Hi Rick. After having had these issues for years, I started blogging about it and how to find classloader leaks [1]. I also compiled a list of API calls and third party libraries known to trigger these leaks [2], and as you can see, it is quite common both to cause these problems yourself and to have them caused by some dependency. Having done the research, I ended up creating a small library that you can add to you web application, that will clean up strong references keeping your classloader from being garbage collected [3]. Somewhat like Tomcat has built in, but taking care of more of the known problems. I suggest you add this library to you app and watch the logs (feel free to report your findings). Having said that, I should admit that I'm still seeing PermGen crashes running under Resin, even when there are no visible strong references to my classloader. I have not had time to investigate whether this is caused by Resin (such as the HotSwap capability), or if it is some JVM bug (and possibly something with IntelliJ, as the problem increases using the IntelliJ Resin plugin). I should probably try turning HotSwap off, or try another application server - or another JVM. Someday... Good luck! /Mattias 1: http://java.jiderhamn.se/2011/12/11/classloader-leaks-i-how-to-find-classloader-leaks-with-eclipse-memory-analyser-mat/ 2: http://java.jiderhamn.se/2012/02/26/classloader-leaks-v-common-mistakes-and-known-offenders/ 3: http://java.jiderhamn.se/2012/03/04/classloader-leaks-vi-this-means-war-leak-prevention-library/ - Original Message - Subject: [Resin-interest] Out of PermGen space Date: Tue, 24 Apr 2012 13:54:40 -0700 From: Rick Mann rm...@latencyzero.com When I'm making changes to the code of a webapp, Resin kindly reloads it for me. I can usually get a handful of reloads in before Resin complains about being out of PermGen space. Is there something I'm doing wrong in my app that it leaks like this? -- Rick ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Override EL implementation (help us stay with Resin)
We have been using Resin for 10+ years, mostly very satisfied, but as we are now working with JSF we've had numerous problems related to Resin. Most of the problems are caused by Resins implementation of EL (not resolving parameters, not being able to call a method defined in a super class, requiring setter to allow getter access). We've managed some partial workarounds (such as a custom com.sun.faces.expressionFactory), but at this point it seems the only rational thing to do is to replace/override individual classes or the entire javax.el package (which Resin does not allow out of the box) - or look for another application server. I want your help to see what our workaround options are. There are obviously benefits of being able to limit the workaround to the application, so that a WAR can include any EL updates and there is no special operation required per server / when upgrading Resin etc. The fact that the application is supposed to be hosted by a third party, also means we don't know if we are even allowed to make necessary changes to the Resin installation. Here are the options I see so far: A) Configure the server to include alternative EL implementation JAR (el-api-2.2.jar) in the classpath, preceeding Resins javaee-16.jar. This could be achieved by setting CLASSPATH environment variable and should also be possible with the jvm-arg tag in Resin configuration. Drawbacks: EL cannot be updated with application, but needs separate update. Not sure hosting companies allow it. Probably not compatible with Resin IDE plugin (haven't got it working yet...), so there will be different configs in dev and production. B) Patch Resins javaee-16.jar with the contents of the other EL implementation JAR (el-api-2.2.jar). This has been tested in dev environment and seems to work. Drawbacks: EL cannot be updated with application, but needs separate update. Unlikely that hosting companies allow this. Needs to be done for every Resin upgrade (until Resin is fixed...). Hacky. C) Allow override of classes inside application (as of the Servlet spec...) by patching the Relax NG Schema of Resin configuration (env.rnc) and adding class-loaderpriority-packagejavax.el/priority-package. Drawbacks: Less likely that hosting companies allow this. Lead to other issues when testing. D) I believe it may be possible replacing for example com.sun.faces.el.ELUtils.BEAN_RESOLVER constant with another implementation, using reflection and Apache BCEL. This way, everthing would be included in WAR and no special configuration needed per server. Drawbacks: Unimplemented and untested (requires time, may not work), very hacky. There may be interdependencies between classes in the javax.el package that are broken if only single classes replaced. Are there other options? Flaws in the above reasoning? Thanks in advance, -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Override EL implementation (help us stay with Resin)
- Original Message - Subject: Re: [Resin-interest] Override EL implementation (help us stay with Resin) Date: Mon, 16 Apr 2012 09:08:23 -0700 From: Scott Ferguson f...@caucho.com On 04/16/2012 03:47 AM, Mattias Jiderhamn wrote: We have been using Resin for 10+ years, mostly very satisfied, but as we are now working with JSF we've had numerous problems related to Resin. Most of the problems are caused by Resins implementation of EL (not resolving parameters, not being able to call a method defined in a super class, requiring setter to allow getter access). Hmm. I'd assumed you were talking about the draft for JavaEE 7, because the bug report says update EL to 2.2 (and not remembering the exact bug report number.) Instead of reporting specific bugs against Resin's implementation (which we can fix), you're asking for it to be replaced? That's backwards. I'm sorry if http://bugs.caucho.com/view.php?id=5011 is misphrased. I'm still a bit of a newbie on the JEE 6+ stack. I thought javaee-16.jar only contained repackaged standard API:s. Are you saying it contains Caucho specific implementations of these API:s, javax.el.BeanELResolver in particular...? (The fact that standard API interfaces such as javax.servlet.http.HttpServletRequest and javax.transaction.UserTransaction have a Caucho licensing header in the Resin source dist makes it harder to see what is standard and what isn't) Anyway, when javaee-16.jar/javax/el is replaced with Maven dep javax.el/el-api/2.2 the problems were gone, so therefore I assumed the repackaging was based on a pre 2.2 version and Resin was not to blame for the bugs per se. But what you are saying is, that our best bet is to report each separate bug against Resin, and hope to see them fixed in the next version? /Mattias Am I understanding this right? I'd put it on a low priority, because I thought you were asking for early draft implementation of JavaEE 7, not bugs against JavaEE 6 (because your requests weren't described as JavaEE 6 bugs.) -- Scott We've managed some partial workarounds (such as a custom com.sun.faces.expressionFactory), but at this point it seems the only rational thing to do is to replace/override individual classes or the entire javax.el package (which Resin does not allow out of the box) - or look for another application server. I want your help to see what our workaround options are. There are obviously benefits of being able to limit the workaround to the application, so that a WAR can include any EL updates and there is no special operation required per server / when upgrading Resin etc. The fact that the application is supposed to be hosted by a third party, also means we don't know if we are even allowed to make necessary changes to the Resin installation. Here are the options I see so far: A) Configure the server to include alternative EL implementation JAR (el-api-2.2.jar) in the classpath, preceeding Resins javaee-16.jar. This could be achieved by setting CLASSPATH environment variable and should also be possible with thejvm-arg tag in Resin configuration. Drawbacks: EL cannot be updated with application, but needs separate update. Not sure hosting companies allow it. Probably not compatible with Resin IDE plugin (haven't got it working yet...), so there will be different configs in dev and production. B) Patch Resins javaee-16.jar with the contents of the other EL implementation JAR (el-api-2.2.jar). This has been tested in dev environment and seems to work. Drawbacks: EL cannot be updated with application, but needs separate update. Unlikely that hosting companies allow this. Needs to be done for every Resin upgrade (until Resin is fixed...). Hacky. C) Allow override of classes inside application (as of the Servlet spec...) by patching the Relax NG Schema of Resin configuration (env.rnc) and adding class-loaderpriority-packagejavax.el/priority-package. Drawbacks: Less likely that hosting companies allow this. Lead to other issues when testing. D) I believe it may be possible replacing for example com.sun.faces.el.ELUtils.BEAN_RESOLVER constant with another implementation, using reflection and Apache BCEL. This way, everthing would be included in WAR and no special configuration needed per server. Drawbacks: Unimplemented and untested (requires time, may not work), very hacky. There may be interdependencies between classes in the javax.el package that are broken if only single classes replaced. Are there other options? Flaws in the above reasoning? Thanks in advance, ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Encoding for javax.servlet.http.Part.getInputStream()
Hi. For multipart String parameters, Resin returns a UTF-8 encoded stream from javax.servlet.http.Part.getInputStream() without regards to request.getCharacterEncoding(). I cannot find whether the UTF-8 encoding is stipulated by the spec, or if this is a Resin bug. Anyone knows...? Reference? Thanks in advance. -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Change classloader precedence / priority / order
Is there a way to change the priority / order of classloaders on
different levels? The class-loader config tag claims to do this, but it
seems to me it only affects the order within the current level (such as
WEB-INF/classes vs WEB-INF/lib), and not classes already loaded by a
higher level (${resin.rootDirectory}/lib).
In particular, I need a newer javax.el implementation than what Resin
provides in lib/javaee-16.jar.
Preferrably I would just include the updated el-api and el-impl jars in
my .war (WEB-INF/lib), and somehow tell Resin that they take precedence
over the ones on resin level (without making explicit reference from
resin.xml into the particular webapp-directory).
Is that possible...?
--
/Mattias
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Change classloader precedence / priority / order
It seems this is possible via the priorityPackage setting available on
the DynamicClassLoader, however, that isn't allowed by the config Relax
NG schema. If I hack the schema (env.rnc), I'm able to configure
class-loader
priority-packagejavax.el/priority-package
(but of course that leads to other issues...).
Is there any reason for this feature to be disable, or could the schema
be update in the next release?
/Mattias
- Original Message -
Subject: [Resin-interest] Change classloader precedence / priority / order
Date: Thu, 12 Jan 2012 15:40:49 +0100
From: Mattias Jiderhamn mj-li...@expertsystems.se
Is there a way to change the priority / order of classloaders on
different levels? The class-loader config tag claims to do this, but it
seems to me it only affects the order within the current level (such as
WEB-INF/classes vs WEB-INF/lib), and not classes already loaded by a
higher level (${resin.rootDirectory}/lib).
In particular, I need a newer javax.el implementation than what Resin
provides in lib/javaee-16.jar.
Preferrably I would just include the updated el-api and el-impl jars in
my .war (WEB-INF/lib), and somehow tell Resin that they take precedence
over the ones on resin level (without making explicit reference from
resin.xml into the particular webapp-directory).
Is that possible...?
--
/Mattias
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
--
/MJ
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Starting Services at Resin Startup
There is a need for us to start few threads as soon as Resin starts up. You can use load-on-startup for a servlet that starts these threads in its init(). In web.xml: servlet servlet-name='app-init-servlet' servlet-class='servlet.that.starts.YourThreads' load-on-startup/ /servlet -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Local deploy after remote deploy
As I am anticipating an end to our class loader leaks, I'm trying out remote deployments again, and they do seem to be working in 4.0.18 - yay! However, once I have remote deployed to a server, Resin will no longer pick up .war files dropped locally in the webapps directory on that server. Or rather, if an updated WAR file is dropped there, Resin will restart the application, but still use the version of the remote deploy. Restarting Resin doesn't help either. Neither does deleting the exploded WAR dir - it will be recreated with some skeleton structure (WEB-INF/classes + WEB-INF/tmp). What I have to do is to delete the $SERVER_ROOT/resin-data/default/.git directory (yes, it took me a while to figure that out the first time...) AND restart. That is, deleting the .git directory and dropping the WAR also is not enough. I haven't bothered with detailed logging yet, but when restarting Resing (without deleting .git) this turns up in the log WebApp[production/webapp/admin.resin/ROOT] cannot read root-directory /error/ROOT When the .git directory has been deleted, there is this in the log [2011-09-29 14:40:21.723] UpdateCallback[bb167ecac021b1e0c7d46b10db03e80599f49706] repository update failed. This is under Resin 4.0.18 with versioning turned off. Is there a known bug here that has been fixed in a newer version? Could I be doing something wrong? -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4 Configuration Sanity Check
To answer one part of your question: Additionally the application is started as root and for the app tier we use user and group to change the user. When we try to do the same thing in the web-loadbalancer tier the application fails to start. Is this normal/to be expected? Is it safe for the web-tier to be running as root? In a *nix environment, it is likely that non-root users are not allowed to bind ports 1024. That is, Resin cannot answer on HTTP (80) or HTTPS (443) request unless running as root. I'd recommend using port forwarding from 80/443 to some port 1024 and then run Resin as non-root. /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin no longer deploys my war
I'm so glad you posted this Jeff, since the same thing happened to us yesterday. I still don't know how, but finally we realized that somehow the same JSP page was compiled both as case sensitive and all lower case (_myJsp__jsp.java and _myjsp__jsp.java). What really threw us off though, was the fact that when we tried to deploy this broken WAR, Resin in some mysterious way managed to deploy an old version of that WAR. We deleted the WAR, we deleted the exploded WAR archive, we restarted Resin. Versioning was and has always been off. But magically an old no-longer-existing WAR was deployed in place of the (broken) one we tried to deploy. I don't remember for sure, but possibly the magic stopped when we deleted [server.root]/resin-data/default/.git (though I couldn't find any file in there enough to match the WAR. By far.) Possibly the fact that I managed to remote deploy that same WAR for the first time earlier yesterday has something to do with this? I might wait a while until I dare to try remote deploy again... I saw that the broken WAR problem should be fixed - or handled better - in 4.0.19. Haven't tried it. However I would still like to understand how Resin could deploy a WAR that no longer existed? Is there anyway to turn it off? I sure hope that this never ever happens in production (knock on wood!), but what should we do if it does happens again? /Mattias Jeff Schnitzer wrote (2011-06-08 09:43): Dunno, I create it with ant just like every other warfile I've ever made... but now that you mention it, when I examine the jar it appears to have two copies of every classfile. Didn't notice that before! And thus the mystery is solved. Wow, this one drove me nuts. At one point I was running this war on an Appengine backend, and the eclipse config for a GAE project puts the classes in WEB-INF/classes (but conveniently hides this in the package explorer). My ant buildfile compiles the classes to a 3rd directory, then includes both those classes and the contents of WEB-INF... you get the picture. Resin could use a better error message for this :-) I'm happy to be back on Resin though. Jeff On Wed, Jun 8, 2011 at 12:26 AM, Mattias Jiderhamn mj-li...@expertsystems.se wrote: Jeff, is it possible that there is something strange about the WAR file itself, like the compression...? May I ask how the WAR is created? Have you compared checksums between where it is created and where it is deployed so it isn't messed up in some transfer? /Mattias Jeff Schnitzer wrote (2011-06-07 02:49): ... FWIW, a simple stripped-down war file does deploy. So presumably it's something about my WARfile. But there's nothing about my WAR that is special - it deploys just fine on other containers. If I unjar it by hand, it deploys just fine on Resin. Jeff ___ 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 -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin no longer deploys my war
Jeff, is it possible that there is something strange about the WAR file itself, like the compression...? May I ask how the WAR is created? Have you compared checksums between where it is created and where it is deployed so it isn't messed up in some transfer? /Mattias Jeff Schnitzer wrote (2011-06-07 02:49): ... FWIW, a simple stripped-down war file does deploy. So presumably it's something about my WARfile. But there's nothing about my WAR that is special - it deploys just fine on other containers. If I unjar it by hand, it deploys just fine on Resin. Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Writer and OutputStream mixup in 4.0.10...?
We're still seeing this issue at random under 4.0.18 :-( http://bugs.caucho.com/view.php?id=4290 /Mattias Scott Ferguson wrote (2010-11-17 18:50): Mattias Jiderhamn wrote: Scott Ferguson wrote (2010-11-12 18:01): Mattias Jiderhamn wrote: Since upgrading to Resin 4.0.10 this error has turned up now and then in our log files, however we have sofar been unable to reproduce it ourselves. Could it be a Resin bug...? java.lang.IllegalStateException: getWriter() can't be called after getOutputStream(). at com.caucho.server.http.HttpServletResponseImpl.getWriter(HttpServletResponseImpl.java:166) I assume you're never calling getOutputStream() in any of the tags or included files? If we were, we should be able to reproduce it and it would turn up a lot more often in production. We've only seen it logged six times in three weeks. Thanks for the update. That's quite a bit different, since it sounds like a timing/race error. That exception is required by the spec if you call getOutputStream() followed by getWriter(). Could it be related to flushing somehow? Such as if an exception was thrown after flushing...? Or possibly one of the reused connections not being cleared properly. It'll take a bit of work to track this down. -- Scott /Mattias I'm filing this as http://bugs.caucho.com/view.php?id=4290. -- Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin no longer deploys my war
Sounds like a file permission issue, but you've checked that, haven't you...? /Mattias - Original Message - Subject: [Resin-interest] Resin no longer deploys my war Date: Tue, 24 May 2011 01:52:04 -0700 From: Jeff Schnitzer j...@infohazard.org I tried upgrading to 4.0.18 recently and deployment seems broken. Normally I copy my war file over webapps/ROOT.war, restart appserver, and it works. Now it seems the only way I can get a deployment working is by: 1) Deleting webapps/ROOT (the directory) 2) Manually un-jaring ROOT.war 3) Deleting the resin-data directory If I don't do #3, Resin recreates an old version of my app, not the new contents of ROOT.war. If I don't do #2, Resin creates an empty web project. This is really, insanely confusing :-( Jeff ___ 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 no longer deploys my war
Just do double check, you are running both the watchdog process and the actual Resin instance as root? Anything on the finest logging level? /Mattias - Original Message - Subject: Re: [Resin-interest] Resin no longer deploys my war Date: Tue, 24 May 2011 02:26:44 -0700 From: Jeff Schnitzer j...@infohazard.org It does sound like that, but I'm running Resin as root. Jeff On Tue, May 24, 2011 at 1:56 AM, Mattias Jiderhamn mj-li...@expertsystems.se wrote: Sounds like a file permission issue, but you've checked that, haven't you...? /Mattias - Original Message - Subject: [Resin-interest] Resin no longer deploys my war Date: Tue, 24 May 2011 01:52:04 -0700 From: Jeff Schnitzer j...@infohazard.org I tried upgrading to 4.0.18 recently and deployment seems broken. Normally I copy my war file over webapps/ROOT.war, restart appserver, and it works. Now it seems the only way I can get a deployment working is by: 1) Deleting webapps/ROOT (the directory) 2) Manually un-jaring ROOT.war 3) Deleting the resin-data directory If I don't do #3, Resin recreates an old version of my app, not the new contents of ROOT.war. If I don't do #2, Resin creates an empty web project. This is really, insanely confusing :-( Jeff ___ 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 -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Multiple instances of the same webapp after redeploy in 4.0.16 (strange!!!)
Scott Ferguson wrote (2011-04-05 01:25):
On 04/04/2011 10:02 AM, Mattias Jiderhamn wrote:
Scott Ferguson wrote (2011-04-04 18:47):
On 04/04/2011 12:43 AM, Mattias Jiderhamn wrote:
While evaluating Resin 4.0.16 we are seeing something that makes me
really concerned. It appears as if after a redeploy there can be
two instances of our main app running.
I was made aware of this by noticing that timed servlets (run-at
... /) were having concurrency issues and logging the same event
twice within the same second.
This made me add some extra logging in a load-on-startup/
servlet, and I can actually see that at some reploys, the same web
app is initialized twice - in different, concurrent threads and
different classloaders.
For example one instance may be initialized by
Thread[http://*:8080-776,5,main] and at the same time (give or take
a few seconds) another one by Thread[resin-366,5,main].
I cannot deliberately recreate it by simply redeploying (which
makes it less likely to be a configuration issue). But it happens
about daily on our test server; possibly issuing requests on a
session in the app while redeploying is a factor.
We are not using versioning.
dependency-check-interval is set to 20 seconds.
The extra app does not appear in the admin console.
How can we figure out what is going on here???
Are you using version=true and/or versioned web-apps? With
versioned web-apps, Resin is supposed to have two versions running
at the same time while it migrates sessions from the old version to
the new version.
As stated above, we are not using versioning.
(And if we we're, should the old version be re-initialized when
deploying a new version...?)
Do you have logs for these events? The WebApp start/stop should be
logged at the info level and be in the jvm-default.log.
I can't yet see how this is happening, though I have found a related
issue with 503s.
The main thing I'd be looking for is:
{thread1} WebApp[/foo] start
{thread2} WebApp[/foo] stop
{thread2} WebApp[/foo] start
{threadX} WebApp[/foo] stop
VS
{thread1} WebApp[/foo] start
{thread2} WebApp[/foo] start
...
In other words, an actual simultaneous start compared to an erroneous
restart.
Yes, there are multiple WebApp starts in the log:
[2011-04-05 15:03:51.905] WebApp[production/webapp/default/ROOT] starting
...
[2011-04-05 15:03:59.062] WebApp[production/webapp/default/ROOT] starting
(the app takes more than 8 seconds to initialize, so they are concurrent
inits)
I haven't configured the default logs to include the thread, but from my
own logging, I can see that the first start is in
Thread[http://*:8080-343,5,main] and the second in
Thread[http://*:8080-349,5,main], in different classloaders
I caught the above starts with finer logging level. Should I extract
the part around this time and send to you, Scott?
--
/Mattias
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Multiple instances of the same webapp after redeploy in 4.0.16 (strange!!!)
While evaluating Resin 4.0.16 we are seeing something that makes me really concerned. It appears as if after a redeploy there can be two instances of our main app running. I was made aware of this by noticing that timed servlets (run-at ... /) were having concurrency issues and logging the same event twice within the same second. This made me add some extra logging in a load-on-startup/ servlet, and I can actually see that at some reploys, the same web app is initialized twice - in different, concurrent threads and different classloaders. For example one instance may be initialized by Thread[http://*:8080-776,5,main] and at the same time (give or take a few seconds) another one by Thread[resin-366,5,main]. I cannot deliberately recreate it by simply redeploying (which makes it less likely to be a configuration issue). But it happens about daily on our test server; possibly issuing requests on a session in the app while redeploying is a factor. We are not using versioning. dependency-check-interval is set to 20 seconds. The extra app does not appear in the admin console. How can we figure out what is going on here??? -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Multiple instances of the same webapp after redeploy in 4.0.16 (strange!!!)
Scott Ferguson wrote (2011-04-04 18:47): On 04/04/2011 12:43 AM, Mattias Jiderhamn wrote: While evaluating Resin 4.0.16 we are seeing something that makes me really concerned. It appears as if after a redeploy there can be two instances of our main app running. I was made aware of this by noticing that timed servlets (run-at ... /) were having concurrency issues and logging the same event twice within the same second. This made me add some extra logging in a load-on-startup/ servlet, and I can actually see that at some reploys, the same web app is initialized twice - in different, concurrent threads and different classloaders. For example one instance may be initialized by Thread[http://*:8080-776,5,main] and at the same time (give or take a few seconds) another one by Thread[resin-366,5,main]. I cannot deliberately recreate it by simply redeploying (which makes it less likely to be a configuration issue). But it happens about daily on our test server; possibly issuing requests on a session in the app while redeploying is a factor. We are not using versioning. dependency-check-interval is set to 20 seconds. The extra app does not appear in the admin console. How can we figure out what is going on here??? Are you using version=true and/or versioned web-apps? With versioned web-apps, Resin is supposed to have two versions running at the same time while it migrates sessions from the old version to the new version. As stated above, we are not using versioning. (And if we we're, should the old version be re-initialized when deploying a new version...?) -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4: hibernate objects in HTTP session causing org.hibernate.LazyInitializationException
By default Resin 4 uses Hessian for serialization of session data.
Hessian tries to traverse uninitialized Hibernate associations by
reflection, causing LazyInitializationException when serializing.
For that reason, we are using Java serialization instead of Hessian for
session data.
Here is how to configure:
session-config
...
serialization-typejava/serialization-type
/session-config
/Mattias
Keith Fetterman wrote (2011-03-25 23:42):
We have a custom Authenticator that extends resin's
com.caucho.server.security.AbstractAuthenticator. In our custom
authenticator, I am storing a Hibernate object that contains a HashSet
of other Hibernate objects in my HTTP session. When I restart Resin
(Resin 4.0.16), I am getting the following stack trace that is caused by
a org.hibernate.LazyInitializationException when I access the first
Web page after the server is started.
It looks like resin is deserializing the Hibernate object from resin's
session persistence and then trying to populate the Set of associated
Hibernate objects, but the Set object that originally contained the
associated Hibernate objects does not exist. I am guessing that is the
problem because I see the following cause:
[11-03-25 14:56:04.683] {http://*:8082-1}
com.caucho.hessian.io.HessianFieldException:
com.marinersupply.common.authentication.ApplicationUser.roles:
java.util.Set cannot be assigned from null
I am using the java.util.HashSet to contain the associated Hibernate
objects. If this is the problem, why isn't resin also serializing the
HashSet?
Doesn't Resin's session serialization serialize objects associated with
objects that are in the HTTP session?
Does resin's session persistence mechanism invoke the methods on the
objects stored in the session when it serializes or unserializes the
objects from the session store?
The reason that I ask this problem is that I get the following Exception:
Caused by: org.hibernate.LazyInitializationException: failed to
lazily initialize a collection, no session or session was closed
Why is resin invoking Hibernate to perform a lazy load of associated
objects on my hibernate object? I've seen cause the error above when it
tried to persist the hibernate object at the end of processing an HTTP
request. We use a servlet filter to close the Hibernate session. It
looks like the act of persisting the session is occurring after resin
has returned from this filter because the Hibernate session was closed.
My question again is why is resin invoking the methods on the object
that in turn makes a request to hibernate to lazy load the associated
objects?
Is resin using Hibernate as a part of its default session persistence
implementation?
We didn't see any of these errors when we were running Resin 3.0.28.
But, in Resin 3.0.28, we were using Resin's MySQL session persistence.
In resin 4.0.16, we are using Resin's default session persistence store.
I would appreciate any ideas on what might be going so I can track down
the problem.
Thanks,
Keith
[11-03-25 14:56:04.680] {http://*:8082-1}
com.caucho.hessian.io.HessianFieldException:
com.marinersupply.common.authentication.ApplicationUser.roles:
java.util.Set cannot be assigned from null
at
com.caucho.hessian.io.UnsafeDeserializer.logDeserializeError(UnsafeDeserializer.java:790)
at
com.caucho.hessian.io.UnsafeDeserializer$ObjectFieldDeserializer.deserialize(UnsafeDeserializer.java:421)
at
com.caucho.hessian.io.UnsafeDeserializer.readObject(UnsafeDeserializer.java:239)
at
com.caucho.hessian.io.UnsafeDeserializer.readObject(UnsafeDeserializer.java:150)
at
com.caucho.hessian.io.Hessian2Input.readObjectInstance(Hessian2Input.java:2212)
at
com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:1719)
at
com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:1703)
at
com.caucho.hessian.io.UnsafeDeserializer$ObjectFieldDeserializer.deserialize(UnsafeDeserializer.java:417)
at
com.caucho.hessian.io.UnsafeDeserializer.readObject(UnsafeDeserializer.java:239)
at
com.caucho.hessian.io.UnsafeDeserializer.readObject(UnsafeDeserializer.java:150)
at
com.caucho.hessian.io.Hessian2Input.readObjectInstance(Hessian2Input.java:2212)
at
com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:2133)
at
[Resin-interest] What is http://admin.resin ?
After upgrading to Resin 4.0.15/16, there is a new virutal host (or whatever it is) in the WebApps section of the admin console, that I've never noticed before. The name is http://admin.resin; and it contains only a root webapp (/) with an uptime as long as Resin has been running. What is this? Is it using any additional memory compared to earlier versions of Resin? Is there a way to turn it off? -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Admin console not updated by make script
I just noticed that installing Resin on Linux using ./configure ... --without-resin-init.d --prefix=/path-to-use; make; make install does not update the admin console pages in /path-to-use/admin Could this be related to the problem with the docs dir reported by Bill Au yesterday (http://bugs.caucho.com/view.php?id=4445) or should I file a separate bug? -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Remote deploy still broken in 4.0.16
Giving the resin-deploy Ant task another try in Resin 4.0.16, I get
resin-home is requried by resin-deploy
Adding a resin-home attribute to the resin-deploy tag as in
resin-deploy server=foo.com port=80
warfile=${war.file.path}
user=foo password=bar
commitmessage=test commitMessage=Test
version=0.1
resin-home=${resin.path}
/
results in resin-deploy doesn't support the resin-home attribute
Sigh
--
/Mattias
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] ROOT.war not expanded when explicitly defined in resin.xml
Have you tried without versioning=true? -- /Mattias - Original Message - Subject: [Resin-interest] ROOT.war not expanded when explicitly defined in resin.xml Date: Mon, 21 Mar 2011 17:03:31 -0700 From: Keith Fetterman kfetter...@go2marine.com I am experiencing a problem in resin 4.0.16 where resin is not expanding the ROOT.war file if I explicitly define the root webapp in resin.xml file. In resin.xml, I have the tag web-app id=/ root-directory=webapps/ROOT/ defined under my host tag. I also have the tag web-app-deploy path=webapps versioning=true/ defined under my host-default tag. When I update the ROOT.war file in my webapps directory, the war file is not being expanded into the webapps/ROOT directory. I have tried both shutting down resin, updating the ROOT.war file and then starting resin, and I've tried updating ROOT.war while resin is running. If I remove the tag web-app id=/ root-directory=webapps/ROOT/ from the resin.xml file, then ROOT.war expansion occurs. Do I need to add an attribute to the web-app id=/ root-directory=webapps/ROOT/ tag to get the war file to expand? Also, what is the difference between the attribute root-directory and document-directory in the web-app tag? I noticed in the resin documentation that root-directory is mentioned in the list of attributes but document-directory is not on the following page: http://caucho.com/resin/reference.xtp#web-app But, if you look at the examples, they all show web-app id='/apache' document-directory='/usr/local/apache/htdocs' Thanks, Keith -- - Keith Fetterman Direct: 206-319-9434 Mariner Supply, Inc. 206-780-5670 http://www.go2marine.com kfetter...@go2marine.com http://www.boatersline.com ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4.0.14+ slow to boot
Scott Ferguson wrote (2011-03-02 18:10): On 03/02/2011 02:53 AM, Mattias Jiderhamn wrote: We're looking forward to upgrading from 4.0.10 to 4.0.15, but during testing we notice 4.0.15 takes way longer to boot our application. Results on different machines range from twice the time to 4-5 times as long. It seems that the Spring/Hibernate initialization is taking most of the time (just by debug outputs, no profiling yet) Narrowing it down, it changed between 4.0.13 and 4.0.14. Is anyone else seeing this? Would this be expected for any reason (like XML parser, DTD resolving)??? (We have primarily tested this on Windows with a Resin Pro license that should be valid for the update) I may have just hit this and fixed it (I need to verify the specific change - there are two.) Resin's classloader does some analysis and caching to improve resource/class loading performance. This speeds up Spring/Hibernate initialization considerably. Some of that caching was causing problems with GC, so it was reversed. I'll see how it can be fixed. Great. Is there a bug entry I can keep track of to see when I should try the snapshop? /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Resin 4.0.14+ slow to boot
We're looking forward to upgrading from 4.0.10 to 4.0.15, but during testing we notice 4.0.15 takes way longer to boot our application. Results on different machines range from twice the time to 4-5 times as long. It seems that the Spring/Hibernate initialization is taking most of the time (just by debug outputs, no profiling yet) Narrowing it down, it changed between 4.0.13 and 4.0.14. Is anyone else seeing this? Would this be expected for any reason (like XML parser, DTD resolving)??? (We have primarily tested this on Windows with a Resin Pro license that should be valid for the update) -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Hudson on Resin 4.0.12
Never got an answer so I posted a bug at http://bugs.caucho.com/view.php?id=4301 /Mattias Mattias Jiderhamn wrote (2010-11-18 10:20): Has anyone been able to run Hudson [1] on Resin 4.0.12...? It's running just fine on 4.0.10, but when accessing the main page / context root under 4.0.12, a directory listing of the root of the WAR is sent with Content-Type application/octet-stream Accessing sub pages, such as /manage, seems to work fine. 1: http://hudson-ci.org ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Hudson on Resin 4.0.12
Has anyone been able to run Hudson [1] on Resin 4.0.12...? It's running just fine on 4.0.10, but when accessing the main page / context root under 4.0.12, a directory listing of the root of the WAR is sent with Content-Type application/octet-stream Accessing sub pages, such as /manage, seems to work fine. 1: http://hudson-ci.org/ -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Writer and OutputStream mixup in 4.0.10...?
Scott Ferguson wrote (2010-11-12 18:01): Mattias Jiderhamn wrote: Since upgrading to Resin 4.0.10 this error has turned up now and then in our log files, however we have sofar been unable to reproduce it ourselves. Could it be a Resin bug...? java.lang.IllegalStateException: getWriter() can't be called after getOutputStream(). at com.caucho.server.http.HttpServletResponseImpl.getWriter(HttpServletResponseImpl.java:166) at com.caucho.server.http.ToCharResponseAdapter$ToCharResponseStreamWrapper.writeNext(ToCharResponseAdapter.java:140) at com.caucho.server.http.ToCharResponseStream.flushCharBuffer(ToCharResponseStream.java:389) at com.caucho.server.http.ToCharResponseStream.flushBuffer(ToCharResponseStream.java:338) at com.caucho.server.http.ResponseAdapter.finish(ResponseAdapter.java:344) at com.caucho.jsp.PageContextImpl.release(PageContextImpl.java:1444) at com.caucho.jsp.PageManager.freePageContext(PageManager.java:217) at _jsp._html._orders._invoices._invoiceStatisticsList__jsp._jspService(_invoiceStatisticsList__jsp.java:45) ... I assume you're never calling getOutputStream() in any of the tags or included files? If we were, we should be able to reproduce it and it would turn up a lot more often in production. We've only seen it logged six times in three weeks. That exception is required by the spec if you call getOutputStream() followed by getWriter(). Could it be related to flushing somehow? Such as if an exception was thrown after flushing...? /Mattias I'm filing this as http://bugs.caucho.com/view.php?id=4290. -- 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] Writer and OutputStream mixup in 4.0.10...?
Since upgrading to Resin 4.0.10 this error has turned up now and then in our log files, however we have sofar been unable to reproduce it ourselves. Could it be a Resin bug...? java.lang.IllegalStateException: getWriter() can't be called after getOutputStream(). at com.caucho.server.http.HttpServletResponseImpl.getWriter(HttpServletResponseImpl.java:166) at com.caucho.server.http.ToCharResponseAdapter$ToCharResponseStreamWrapper.writeNext(ToCharResponseAdapter.java:140) at com.caucho.server.http.ToCharResponseStream.flushCharBuffer(ToCharResponseStream.java:389) at com.caucho.server.http.ToCharResponseStream.flushBuffer(ToCharResponseStream.java:338) at com.caucho.server.http.ResponseAdapter.finish(ResponseAdapter.java:344) at com.caucho.jsp.PageContextImpl.release(PageContextImpl.java:1444) at com.caucho.jsp.PageManager.freePageContext(PageManager.java:217) at _jsp._html._orders._invoices._invoiceStatisticsList__jsp._jspService(_invoiceStatisticsList__jsp.java:45) ... -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Remote deployment
)
at
com.caucho.hessian.io.BasicSerializer.writeObject(BasicSerializer.java:273)
at
com.caucho.hessian.io.Hessian2Output.writeObject(Hessian2Output.java:421)
at
com.caucho.hessian.io.UnsafeSerializer$ObjectFieldSerializer.serialize(UnsafeSerializer.java:293)
Am I still doing something wrong???
/Mattias
Scott Ferguson skrev:
Mattias Jiderhamn wrote:
After adding a commitmessage, which according to the Wiki is optional,
I'm told I need to add aresin:DeployService / tag.
When reading http://www.caucho.com/resin/admin/deploy.xtp carefully, the
text saysresin:DeployService / but the example shows
resin:RemoteDeploy/
Maybe update the docs?
Thanks. I've filed this.
The timeout looks like something we're working on for 4.0.7. Basically,
the first request is using the keepalive timeout, when that timeout
should only apply to following requests.
-- Scott
I'm still getting the client side exception however. Possibly this in
the server logs is related???
[2010-04-25 09:39:02.116] dep...@resin.caucho
[2010-04-25 09:39:02.116] 3L/* defun
com.caucho.server.admin.DeployCommitListQuery [_commitList] */
[2010-04-25 09:39:02.116] object
com.caucho.server.admin.DeployCommitListQuery (#0)
[2010-04-25 09:39:02.117] _commitList: list [string (#1)
[2010-04-25 09:39:02.117] 0: 1e784a641b0ca613561d8ceebc93f0c3697464ed
.
[2010-04-25 09:39:02.557] 1963: 4595088616403c1f77e7c439381bebdf850116d0
[2010-04-25 09:39:02.557] 1964: 45978c1f355a0ee077bd4b9bcc175645237699a0
[2010-04-25 09:39:02.558] TcpConnection[id=4] closing connection
TcpConnection[id=http--8080-4,http://*:8080,CLOSED], total=8
[2010-04-25 09:39:02.559] com.caucho.vfs.ClientDisconnectException:
unknown exception=-1
at com.caucho.vfs.JniStream.exception(JniStream.java:156)
at com.caucho.vfs.JniStream.write(JniStream.java:121)
at com.caucho.vfs.WriteStream.close(WriteStream.java:1223)
at
com.caucho.server.connection.TcpConnection.closeImpl(TcpConnection.java:1002)
at com.caucho.server.connection.TcpConnection.close(TcpConnection.java:960)
at
com.caucho.server.connection.TcpDuplexController.closeImpl(TcpDuplexController.java:209)
at
com.caucho.server.connection.TcpDuplexController.close(TcpDuplexController.java:187)
at
com.caucho.server.connection.TcpDuplexController.serviceRead(TcpDuplexController.java:174)
at
com.caucho.server.connection.TcpConnection$DuplexReadTask.doTask(TcpConnection.java:1304)
at
com.caucho.server.connection.TcpConnection$ConnectionReadTask.runThread(TcpConnection.java:1137)
at
com.caucho.server.connection.TcpConnection$DuplexReadTask.run(TcpConnection.java:1283)
at com.caucho.util.ThreadPool$PoolThread.runTasks(ThreadPool.java:901)
at com.caucho.util.ThreadPool$PoolThread.run(ThreadPool.java:866)
[2010-04-25 09:39:02.562] TcpDuplexController[null,closed] was not
processing any data. Shutting down.
[2010-04-25 09:39:02.562] TcpDuplexController[null,closed] was not
processing any data. Shutting down.
[2010-04-25 09:39:02.562] 1968: 45a23eb4953a8caf415afc5820887d160bfbb035
[2010-04-25 09:39:02.562] 1969: 45a40c537ed3cc0d8b271d3ad4105d4a36af9402
...
[2010-04-25 09:39:03.577] 10978: fff16ae185861a99959807fb2247cef6da0c7a3b
[2010-04-25 09:39:03.577] 10979: fff3417c3c850b61159094928644cca69153
[2010-04-25 09:39:03.577] packet-end
/Mattias
Mattias Jiderhamn wrote (2010-04-23 16:17):
Turned on finest logging. This could possibly be related.
[2010-04-23 16:13:34.097] com.caucho.hessian.io.HessianFieldException:
com.caucho.server.admin.DeployCommitListQuery._commitList: expected
string at end of file
...
Mattias Jiderhamn wrote (2010-04-23 16:05):
I thought I'd try out remote deployment but the documentation is a bit
inconsistent.
According to http://www.caucho.com/resin/admin/deploy.xtp there should
be aresin:RemoteDeploy/tag in the configuration, however this tag is
not mentioned at http://blog.caucho.com/?p=134 and does not seem to
exist (in 4.0.3).
When trying remote deploy via Ant without that tag (but with
resin:RemoteAdminService /), I end up with this timeout.
com.caucho.bam.TimeoutException:
com.caucho.bam.querymanager$queryfuturei...@12884e0 query timeout
DeployCommitListQuery[] {to:dep...@resin.caucho}
Anything obvious missing or how to debug?
--
/Mattias
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] resin.exe server root directory in 4.0.10
Scott Ferguson wrote (2010-08-31 18:54): Mattias Jiderhamn wrote: Trying to launch Resin 4.0.10 on Windows with the -server-root / -server_root / -root-directory / --root-directory but resin.exe seems to ignore all of them. Is there an undocumented change, or is there a bug in resin.exe in the 4.0.10 (pro) release? Do you see the same issue with java -jar lib/resin.jar start? No that works fine. Alex wrote (2010-08-31 20:36): That's a bug in resin.exe. Yes, that's what I thought. For the mailing list record, here is the Mantis issue http://bugs.caucho.com/view.php?id=4196 -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Custom startup recommendation
(I am not by far a *nix wizz, nor the admin of our production servers, so please bear with me) Historically we have edited the /etc/init.d/resin script to customize the Resin startup, such as setting the server root directory or assigning CPU cores with taskdef. In the 4.0.x branch this file is overwritten at each minor upgrade by make install. Does this mean this is (no longer) the recommended way of configuring the startup, and there is some other means we should look at instead...? -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] resin.exe server root directory in 4.0.10
Trying to launch Resin 4.0.10 on Windows with the -server-root / -server_root / -root-directory / --root-directory but resin.exe seems to ignore all of them. Is there an undocumented change, or is there a bug in resin.exe in the 4.0.10 (pro) release? -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Custom startup recommendation
We are on RedHat Enterprise Linux 4/5. Note that the question is not the configuration itself, but *where* is the proper place for such configuration. The file we use now is overwritten with the one which ships with Resin on every Resin update. /Mattias jkowall wrote (2010-08-31 14:19): Depends on the version of Unix you are on exactly. I customized the init script quite a bit, so I don't use the one which ships with Resin. Which version/distribution are you using? I can share the one I use if you'd like. -jk On Tue, Aug 31, 2010 at 4:10 AM, Mattias Jiderhamn mj-li...@expertsystems.se mailto:mj-li...@expertsystems.se wrote: (I am not by far a *nix wizz, nor the admin of our production servers, so please bear with me) Historically we have edited the /etc/init.d/resin script to customize the Resin startup, such as setting the server root directory or assigning CPU cores with taskdef. In the 4.0.x branch this file is overwritten at each minor upgrade by make install. Does this mean this is (no longer) the recommended way of configuring the startup, and there is some other means we should look at instead...? -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Custom startup recommendation
How then are you supposed to go about upgrading Resin? Is there a parameter to the configure script to avoid creating/overwriting /etc/init.d/resin? If not, could such parameter be added...? /Mattias jkowall wrote (2010-08-31 14:45): On RHEL, it should be /etc/init.d/ for sure, and you manage the startup scripts with /sbin/sysconfig -jk On Tue, Aug 31, 2010 at 8:38 AM, Mattias Jiderhamn mj-li...@expertsystems.se mailto:mj-li...@expertsystems.se wrote: We are on RedHat Enterprise Linux 4/5. Note that the question is not the configuration itself, but *where* is the proper place for such configuration. The file we use now is overwritten with the one which ships with Resin on every Resin update. /Mattias jkowall wrote (2010-08-31 14:19): Depends on the version of Unix you are on exactly. I customized the init script quite a bit, so I don't use the one which ships with Resin. Which version/distribution are you using? I can share the one I use if you'd like. -jk On Tue, Aug 31, 2010 at 4:10 AM, Mattias Jiderhamn mj-li...@expertsystems.se mailto:mj-li...@expertsystems.se wrote: (I am not by far a *nix wizz, nor the admin of our production servers, so please bear with me) Historically we have edited the /etc/init.d/resin script to customize the Resin startup, such as setting the server root directory or assigning CPU cores with taskdef. In the 4.0.x branch this file is overwritten at each minor upgrade by make install. Does this mean this is (no longer) the recommended way of configuring the startup, and there is some other means we should look at instead...? -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] cxf / soap with 4.0.8
That's about what I had. However geronimo-javamail_1.4_spec-1.6.jar seemed unnecessary, plus I added spring.jar (3 MB) to config the services, but maybe Resin CanDI works just as well? /Mattias Riccardo Cohen wrote (2010-07-22 11:14): Ooops ... it actually works all right with lib/soap/ subdirectory, I just modified the wrong file... :) By the way I noticed a very interesting file in the CXF lib directory : WHICH_JARS !! Could make my program work with only 12 libs/6Mb: commons-logging-1.1.1.jar cxf-2.2.9.jar geronimo-activation_1.1_spec-1.0.2.jar geronimo-annotation_1.0_spec-1.1.1.jar geronimo-javamail_1.4_spec-1.6.jar geronimo-stax-api_1.0_spec-1.0.1.jar jaxb-api-2.1.jar jaxb-impl-2.1.13.jar neethi-2.0.4.jar wsdl4j-1.6.2.jar wstx-asl-3.2.9.jar XmlSchema-1.4.5.jar It begins to be reasonable ! Riccardo Cohen wrote: Hello With 4.0.8 the sample given http://wiki.caucho.com/CXF works. I can now create a soap service and call it. I can also generate wsdl with /adlsoap?wsdl request and could generate java classes from wsdl with cxf's wsdl2java. These 2 steps could be added to the wiki :) Now there are some details: - I still need to unzip package 3.1.9 to find the resin-support.jar which is needed, I suppose this could be added also in 4.0.8 package ? - I would like to put cxf libraries in a subfolder of lib, so I added this to web-app conf : class-loader library-loader path=WEB-INF/lib/soap/ /class-loader but it did not work. Thanks ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Remote deployment
After adding a commitmessage, which according to the Wiki is optional,
I'm told I need to add a resin:DeployService / tag.
When reading http://www.caucho.com/resin/admin/deploy.xtp carefully, the
text says resin:DeployService / but the example shows
resin:RemoteDeploy/
Maybe update the docs?
I'm still getting the client side exception however. Possibly this in
the server logs is related???
[2010-04-25 09:39:02.116] dep...@resin.caucho
[2010-04-25 09:39:02.116] 3L/* defun
com.caucho.server.admin.DeployCommitListQuery [_commitList] */
[2010-04-25 09:39:02.116] object
com.caucho.server.admin.DeployCommitListQuery (#0)
[2010-04-25 09:39:02.117] _commitList: list [string (#1)
[2010-04-25 09:39:02.117] 0: 1e784a641b0ca613561d8ceebc93f0c3697464ed
.
[2010-04-25 09:39:02.557] 1963: 4595088616403c1f77e7c439381bebdf850116d0
[2010-04-25 09:39:02.557] 1964: 45978c1f355a0ee077bd4b9bcc175645237699a0
[2010-04-25 09:39:02.558] TcpConnection[id=4] closing connection
TcpConnection[id=http--8080-4,http://*:8080,CLOSED], total=8
[2010-04-25 09:39:02.559] com.caucho.vfs.ClientDisconnectException:
unknown exception=-1
at com.caucho.vfs.JniStream.exception(JniStream.java:156)
at com.caucho.vfs.JniStream.write(JniStream.java:121)
at com.caucho.vfs.WriteStream.close(WriteStream.java:1223)
at
com.caucho.server.connection.TcpConnection.closeImpl(TcpConnection.java:1002)
at com.caucho.server.connection.TcpConnection.close(TcpConnection.java:960)
at
com.caucho.server.connection.TcpDuplexController.closeImpl(TcpDuplexController.java:209)
at
com.caucho.server.connection.TcpDuplexController.close(TcpDuplexController.java:187)
at
com.caucho.server.connection.TcpDuplexController.serviceRead(TcpDuplexController.java:174)
at
com.caucho.server.connection.TcpConnection$DuplexReadTask.doTask(TcpConnection.java:1304)
at
com.caucho.server.connection.TcpConnection$ConnectionReadTask.runThread(TcpConnection.java:1137)
at
com.caucho.server.connection.TcpConnection$DuplexReadTask.run(TcpConnection.java:1283)
at com.caucho.util.ThreadPool$PoolThread.runTasks(ThreadPool.java:901)
at com.caucho.util.ThreadPool$PoolThread.run(ThreadPool.java:866)
[2010-04-25 09:39:02.562] TcpDuplexController[null,closed] was not
processing any data. Shutting down.
[2010-04-25 09:39:02.562] TcpDuplexController[null,closed] was not
processing any data. Shutting down.
[2010-04-25 09:39:02.562] 1968: 45a23eb4953a8caf415afc5820887d160bfbb035
[2010-04-25 09:39:02.562] 1969: 45a40c537ed3cc0d8b271d3ad4105d4a36af9402
...
[2010-04-25 09:39:03.577] 10978: fff16ae185861a99959807fb2247cef6da0c7a3b
[2010-04-25 09:39:03.577] 10979: fff3417c3c850b61159094928644cca69153
[2010-04-25 09:39:03.577] packet-end
/Mattias
Mattias Jiderhamn wrote (2010-04-23 16:17):
Turned on finest logging. This could possibly be related.
[2010-04-23 16:13:34.097] com.caucho.hessian.io.HessianFieldException:
com.caucho.server.admin.DeployCommitListQuery._commitList: expected
string at end of file
...
Mattias Jiderhamn wrote (2010-04-23 16:05):
I thought I'd try out remote deployment but the documentation is a bit
inconsistent.
According to http://www.caucho.com/resin/admin/deploy.xtp there should
be aresin:RemoteDeploy/ tag in the configuration, however this tag is
not mentioned at http://blog.caucho.com/?p=134 and does not seem to
exist (in 4.0.3).
When trying remote deploy via Ant without that tag (but with
resin:RemoteAdminService /), I end up with this timeout.
com.caucho.bam.TimeoutException:
com.caucho.bam.querymanager$queryfuturei...@12884e0 query timeout
DeployCommitListQuery[] {to:dep...@resin.caucho}
Anything obvious missing or how to debug?
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Remote deployment
I thought I'd try out remote deployment but the documentation is a bit
inconsistent.
According to http://www.caucho.com/resin/admin/deploy.xtp there should
be a resin:RemoteDeploy/ tag in the configuration, however this tag is
not mentioned at http://blog.caucho.com/?p=134 and does not seem to
exist (in 4.0.3).
When trying remote deploy via Ant without that tag (but with
resin:RemoteAdminService /), I end up with this timeout.
com.caucho.bam.TimeoutException:
com.caucho.bam.querymanager$queryfuturei...@12884e0 query timeout
DeployCommitListQuery[] {to:dep...@resin.caucho}
Anything obvious missing or how to debug?
--
/Mattias
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Remote deployment
Turned on finest logging. This could possibly be related.
[2010-04-23 16:13:34.097] com.caucho.hessian.io.HessianFieldException:
com.caucho.server.admin.DeployCommitListQuery._commitList: expected
string at end of file
at
com.caucho.hessian.io.UnsafeDeserializer.logDeserializeError(UnsafeDeserializer.java:768)
at
com.caucho.hessian.io.UnsafeDeserializer$ObjectFieldDeserializer.deserialize(UnsafeDeserializer.java:421)
at
com.caucho.hessian.io.UnsafeDeserializer.readObject(UnsafeDeserializer.java:239)
at
com.caucho.hessian.io.UnsafeDeserializer.readObject(UnsafeDeserializer.java:150)
at
com.caucho.hessian.io.Hessian2Input.readObjectInstance(Hessian2Input.java:2188)
at com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:2109)
at com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:2093)
at com.caucho.hmtp.HmtpReader.readPacket(HmtpReader.java:153)
at
com.caucho.remote.HmtpServlet$WebSocketHandler.onRead(HmtpServlet.java:201)
at
com.caucho.server.http.HttpServletRequestImpl$WebSocketContextImpl.onRead(HttpServletRequestImpl.java:2490)
at
com.caucho.server.connection.TcpDuplexController.serviceRead(TcpDuplexController.java:161)
at
com.caucho.server.connection.TcpConnection$DuplexReadTask.doTask(TcpConnection.java:1304)
at
com.caucho.server.connection.TcpConnection$ConnectionReadTask.runThread(TcpConnection.java:1137)
at
com.caucho.server.connection.TcpConnection$DuplexReadTask.run(TcpConnection.java:1283)
at com.caucho.util.ThreadPool$PoolThread.runTasks(ThreadPool.java:901)
at com.caucho.util.ThreadPool$PoolThread.run(ThreadPool.java:866)
Caused by: com.caucho.hessian.io.HessianProtocolException: expected
string at end of file
at com.caucho.hessian.io.Hessian2Input.error(Hessian2Input.java:2882)
at com.caucho.hessian.io.Hessian2Input.expect(Hessian2Input.java:2807)
at com.caucho.hessian.io.Hessian2Input.readString(Hessian2Input.java:1362)
at
com.caucho.hessian.io.BasicDeserializer.readLengthList(BasicDeserializer.java:589)
at com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:1731)
at
com.caucho.hessian.io.UnsafeDeserializer$ObjectFieldDeserializer.deserialize(UnsafeDeserializer.java:417)
... 14 more
Mattias Jiderhamn wrote (2010-04-23 16:05):
I thought I'd try out remote deployment but the documentation is a bit
inconsistent.
According to http://www.caucho.com/resin/admin/deploy.xtp there should
be aresin:RemoteDeploy/ tag in the configuration, however this tag is
not mentioned at http://blog.caucho.com/?p=134 and does not seem to
exist (in 4.0.3).
When trying remote deploy via Ant without that tag (but with
resin:RemoteAdminService /), I end up with this timeout.
com.caucho.bam.TimeoutException:
com.caucho.bam.querymanager$queryfuturei...@12884e0 query timeout
DeployCommitListQuery[] {to:dep...@resin.caucho}
Anything obvious missing or how to debug?
--
/Mattias
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Accessing resin-admin
Thanks, that worked.
I tried adding resin:Allow (or security-constraint) also to add some
IP filtering (resin:IfNetwork vs ip-constraint) and then the
authenticator seems to be overridden. In case the request comes from a
trusted IP range, no login is required.
I have to add resin:And resin:IfUserInRole role=resin-admin/ also.
Is that intended...?
Btw, in order to not mess up the login page I set url-pattern=*.php.
Any risk this will change in a future release without further notice?
Maybe it's better/safer to allow /images/* and *.css?
/Mattias
Emil Ong wrote (2010-04-16 23:17):
Hi Mattias,
Are you using a custom resin.xml/resin.conf? If so, you might try
copying theresin:AdminAuthenticator configuration from the default.
It looks like this:
resin:AdminAuthenticator
resin:import path=${__DIR__}/admin-users.xml optional=true/
/resin:AdminAuthenticator
This part of the install document may also be helpful:
http://caucho.com/resin-4.0/admin/starting-resin-install.xtp#Creating%20a%20password%20for%20the%20Resin%20Administration%20Console
Best,
Emil
On Fri, Apr 16, 2010 at 09:46:33AM +0200, Mattias Jiderhamn wrote:
I feel like a newbie for having to ask this, but admittedly I have never
used the J2EE authentication mechanism since we have a proprietary one.
I'm trying to set up resin-admin following a combination of the
instructions at
http://caucho.com/resin-4.0/admin/resin-admin-console.xtp and the
instructions shown when accessing the admin app.
I have configured the web-app and had it generate a admin-users.xml so
that I can log in. However I have no access, apparently since my user is
not in the resin-admin role.
Doing a bit of debugging I end up in a NullAuthenticator that only
accepts the user role. So I guess I need to configure some other
authenticator, right...?
--
/Mattias
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] IllegalStateException at session load
Last week we saw a whole bunch of these exceptions. Removing resin_data_default.db and resin_mnode_default.db and restarting Resin removed the problem, but possibly there is something there that needs attention. java.lang.IllegalStateException at com.caucho.db.sql.QueryContext.unlock(QueryContext.java:546) at com.caucho.db.sql.QueryContext.close(QueryContext.java:591) at com.caucho.db.sql.UpdateQuery.execute(UpdateQuery.java:117) at com.caucho.db.jdbc.PreparedStatementImpl.execute(PreparedStatementImpl.java:344) at com.caucho.db.jdbc.PreparedStatementImpl.executeUpdate(PreparedStatementImpl.java:311) at com.caucho.server.distcache.MnodeStore.updateUpdateTime(MnodeStore.java:607) at com.caucho.server.distcache.AbstractDataCacheManager.saveLocalUpdateTime(AbstractDataCacheManager.java:690) at com.caucho.server.distcache.AbstractDataCacheManager.saveUpdateTime(AbstractDataCacheManager.java:628) at com.caucho.server.distcache.AbstractDataCacheManager.updateIdleTime(AbstractDataCacheManager.java:503) at com.caucho.server.distcache.AbstractDataCacheManager.getMnodeValue(AbstractDataCacheManager.java:250) at com.caucho.server.distcache.ProCacheEntry.getMnodeValue(ProCacheEntry.java:106) at com.caucho.distcache.AbstractCache.getExtCacheEntry(AbstractCache.java:452) at com.caucho.server.session.SessionImpl.load(SessionImpl.java:562) at com.caucho.server.session.SessionManager.createSession(SessionManager.java:1282) at com.caucho.server.connection.AbstractCauchoRequest.createSession(AbstractCauchoRequest.java:248) at com.caucho.server.connection.AbstractCauchoRequest.getSession(AbstractCauchoRequest.java:191) at ... ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Lots of Connection reset
Scott Ferguson wrote (2010-01-13 18:07): Mattias Jiderhamn wrote: Scott, I notice that in com.caucho.hessian.server.HessianSkeleton there are lots of out.close() but no out.flush(). Could unflushed buffers be what is causing this? At least then difference in output size could explain why it works sometimes on the production server and always in test environment. (There is a 200 status in the server log regardless of the result on the client and the size of the response is about 200 kB) I wouldn't think that would make a difference, as long as the flush/close for the request always occurs at the end of the request. The 4.0.3 hessian did change the i/o handling, because of the URL disconnect() that I'd added for testing purposes (the 4.0.3 change generalized the http connection and made it pluggable.) It's possible the disconnect() was causing problems, which might not be a problem in the new version. I'll cross my fingers and wait. Thanks. /Mattias -- Scott /Mattias Mattias Jiderhamn wrote (2010-01-08 21:24): I was able to see the error myself today. It occurs within 3 seconds from the Hessian call, so I doubt this is some kind of timeout issue. I can't see any traces of this on the server side. Any other ideas??? Should I add some debugging code somewhere? /Mattias Scott Ferguson wrote (2009-12-16 15:56): Mattias Jiderhamn wrote: Nope - standalone Resin. It would be a different issue. This looks like a timeout issue, while the previous one was a protocol problem. On the server side, are you seeing any timeout of that connection? Or does changing the socket-timeout avoid the issue? -- Scott /Mattias Wesley Wu wrote (2009-12-16 11:10): 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 mj-li...@expertsystems.se: 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 -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest -- /Mattias
Re: [Resin-interest] Lots of Connection reset
Scott, I notice that in com.caucho.hessian.server.HessianSkeleton there are lots of out.close() but no out.flush(). Could unflushed buffers be what is causing this? At least then difference in output size could explain why it works sometimes on the production server and always in test environment. (There is a 200 status in the server log regardless of the result on the client and the size of the response is about 200 kB) /Mattias Mattias Jiderhamn wrote (2010-01-08 21:24): I was able to see the error myself today. It occurs within 3 seconds from the Hessian call, so I doubt this is some kind of timeout issue. I can't see any traces of this on the server side. Any other ideas??? Should I add some debugging code somewhere? /Mattias Scott Ferguson wrote (2009-12-16 15:56): Mattias Jiderhamn wrote: Nope - standalone Resin. It would be a different issue. This looks like a timeout issue, while the previous one was a protocol problem. On the server side, are you seeing any timeout of that connection? Or does changing the socket-timeout avoid the issue? -- Scott /Mattias Wesley Wu wrote (2009-12-16 11:10): 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 mj-li...@expertsystems.se: 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 -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Lots of Connection reset
I was able to see the error myself today. It occurs within 3 seconds from the Hessian call, so I doubt this is some kind of timeout issue. I can't see any traces of this on the server side. Any other ideas??? Should I add some debugging code somewhere? /Mattias Scott Ferguson wrote (2009-12-16 15:56): Mattias Jiderhamn wrote: Nope - standalone Resin. It would be a different issue. This looks like a timeout issue, while the previous one was a protocol problem. On the server side, are you seeing any timeout of that connection? Or does changing the socket-timeout avoid the issue? -- Scott /Mattias Wesley Wu wrote (2009-12-16 11:10): 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 mj-li...@expertsystems.se: 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 -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Lots of Connection reset
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 -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Lots of Connection reset
Nope - standalone Resin. /Mattias Wesley Wu wrote (2009-12-16 11:10): 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 mj-li...@expertsystems.se: 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 -- /Mattias ___ 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 -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin License Question
One theory is that it is the last date you may purchase a renewal, before you have to buy a new license? /Mattias Rob Lockstone wrote (2009-12-15 22:18): I see in our resin license file a version-expire-date tag and an expire-date tag. The version-expire-date tag corresponds to the date our license expires, but what is the expire-date? I see it's several months after the version-expire-date, but I couldn't find an explanation for what it means. Rob ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Potential class loader leaks
Scott, can you tell me whether you've been able to reproduce this scenario?
/Mattias
Mattias Jiderhamn wrote (2009-12-11 08:34):
Scott Ferguson wrote (2009-12-11 00:23):
Mattias Jiderhamn wrote:
So I've spent another day hunting that lo(ooo)ng standing PermGen memory
leak in our application and/or Resin.
I made a new discovery which shouldn't be an issue, but could
potentially fix problems.
From my investigation it seems that whenever the application is
reloaded, a reference to the old
com.caucho.loader.EnvironmentClassLoader is kept in
com.caucho.hessian.io.SerializerFactory._defaultFactory. I agree that in
theory this shouldn't happen, since the ClassLoader is a weak reference
key, /however/ if I add some code to the application shutdown,
explicitly removing the EnvironmentClassLoader from _defaultFactory
using reflection, the garbage collector is able to unload these classes.
I changed this in 4.0.2 (with some more changes in 4.0.3). Even though
the key is a weak reference, the value is a strong reference.
Indeed, this has been fixed in the latest snapshot! Good job!
Sorry for not testing against that...
I should mention though, that there is still a minimum of two
EnvironmentClassLoaders for the given application after reloading at
least once. The former one seem to stick around somehow. We have
discussed this before, Scott; how references are kept inside
com.caucho.server.dispatch.Invocation, at least in a low traffic (dev /
debugging) environment.
On a web-app change the Invocation cache is cleared, so there shouldn't
be any old references there.
Could you please double check that? For example, what happens to the
503:ed requests received during redeployment?
I have an examplifying YourKit (freely available EAP) snapshot I could
send you if it helps.
Here is what I'm getting, which seems repeatable over and over in my
environment:
Startup: 9k loaded classes, no unloaded classes, 49 MB PermGen
First redeployment: 15k loaded classes, no unloaded classes, 77 MB
PermGen = one extra instance of the app with 6k classes loaded.
Assumed a total of 2 classloaders
Second redeployment: 15k loaded classes, 6k unloaded classes, 77 MB
PermGen = initial/first(?) instance GC:ed and a new one loaded. Still
2 classloaders.
Third redeployment: 21k loaded classes, 6k unloaded classes, 105 MB
PermGen = one extra instance of the app with 6k classes loaded,
nothing GC:ed. Assumed a total of 3 classloaders
Fourth redeployment: 21k loaded classes, 12k unloaded classes, 105 MB
PermGen = second(?) instance GC:ed and a new one loaded. Still 3
classloaders.
(Fifth redeployment: 15k loaded classes, 24k unloaded classes, 77 MB
PermGen = third and fourth(?) instance GC:ed and a new one loaded. 2
classloaders. Haven't repeated this test enough to build a thesis)
Not sure if this a real problem, but ideally the
class loader of the previous version should be available for garbage
collection before the classes of the new version are loaded ('cause
there is no turning back anyway, is there...?).
In the past this could be a problem with JNI because a JNI library can
only be loaded in one classloader (that may have been changed but it
always was a JDK restriction.)
Are you saying this shouldn't be a issue in 4.0.2/snapshot running on
JDK 1.6?
--
/Mattias
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Potential class loader leaks
Mattias Jiderhamn wrote (2009-12-11 08:34): I should mention though, that there is still a minimum of two EnvironmentClassLoaders for the given application after reloading at least once. The former one seem to stick around somehow. We have discussed this before, Scott; how references are kept inside com.caucho.server.dispatch.Invocation, at least in a low traffic (dev / debugging) environment. On a web-app change the Invocation cache is cleared, so there shouldn't be any old references there. Could you please double check that? For example, what happens to the 503:ed requests received during redeployment? I have an examplifying YourKit (freely available EAP) snapshot I could send you if it helps. Here is what I'm getting, which seems repeatable over and over in my environment: Startup: 9k loaded classes, no unloaded classes, 49 MB PermGen First redeployment: 15k loaded classes, no unloaded classes, 77 MB PermGen = one extra instance of the app with 6k classes loaded. Assumed a total of 2 classloaders Second redeployment: 15k loaded classes, 6k unloaded classes, 77 MB PermGen = initial/first(?) instance GC:ed and a new one loaded. Still 2 classloaders. Third redeployment: 21k loaded classes, 6k unloaded classes, 105 MB PermGen = one extra instance of the app with 6k classes loaded, nothing GC:ed. Assumed a total of 3 classloaders Fourth redeployment: 21k loaded classes, 12k unloaded classes, 105 MB PermGen = second(?) instance GC:ed and a new one loaded. Still 3 classloaders. (Fifth redeployment: 15k loaded classes, 24k unloaded classes, 77 MB PermGen = third and fourth(?) instance GC:ed and a new one loaded. 2 classloaders. Haven't repeated this test enough to build a thesis) I should probably point out that garbage collection was forced a couple of times before noting these numbers, so it shouldn't be a cased of delayed GC. -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Potential class loader leaks
So I've spent another day hunting that lo(ooo)ng standing PermGen memory
leak in our application and/or Resin.
I made a new discovery which shouldn't be an issue, but could
potentially fix problems.
From my investigation it seems that whenever the application is
reloaded, a reference to the old
com.caucho.loader.EnvironmentClassLoader is kept in
com.caucho.hessian.io.SerializerFactory._defaultFactory. I agree that in
theory this shouldn't happen, since the ClassLoader is a weak reference
key, /however/ if I add some code to the application shutdown,
explicitly removing the EnvironmentClassLoader from _defaultFactory
using reflection, the garbage collector is able to unload these classes.
I should mention though, that there is still a minimum of two
EnvironmentClassLoaders for the given application after reloading at
least once. The former one seem to stick around somehow. We have
discussed this before, Scott; how references are kept inside
com.caucho.server.dispatch.Invocation, at least in a low traffic (dev /
debugging) environment. Not sure if this a real problem, but ideally the
class loader of the previous version should be available for garbage
collection before the classes of the new version are loaded ('cause
there is no turning back anyway, is there...?). Otherwise you always
have to set MaxPermSize to at least twice as much as the application
actually needs.
In some profiling session I've also seen references from logging and
index-cache-writer threads, which might be worth looking into.
Scott, could you tell me if anything can be done to the issues mentioned
above?
--
/Mattias
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Potential class loader leaks
Scott Ferguson wrote (2009-12-11 00:23):
Mattias Jiderhamn wrote:
So I've spent another day hunting that lo(ooo)ng standing PermGen memory
leak in our application and/or Resin.
I made a new discovery which shouldn't be an issue, but could
potentially fix problems.
From my investigation it seems that whenever the application is
reloaded, a reference to the old
com.caucho.loader.EnvironmentClassLoader is kept in
com.caucho.hessian.io.SerializerFactory._defaultFactory. I agree that in
theory this shouldn't happen, since the ClassLoader is a weak reference
key, /however/ if I add some code to the application shutdown,
explicitly removing the EnvironmentClassLoader from _defaultFactory
using reflection, the garbage collector is able to unload these classes.
I changed this in 4.0.2 (with some more changes in 4.0.3). Even though
the key is a weak reference, the value is a strong reference.
Indeed, this has been fixed in the latest snapshot! Good job!
Sorry for not testing against that...
I should mention though, that there is still a minimum of two
EnvironmentClassLoaders for the given application after reloading at
least once. The former one seem to stick around somehow. We have
discussed this before, Scott; how references are kept inside
com.caucho.server.dispatch.Invocation, at least in a low traffic (dev /
debugging) environment.
On a web-app change the Invocation cache is cleared, so there shouldn't
be any old references there.
Could you please double check that? For example, what happens to the
503:ed requests received during redeployment?
I have an examplifying YourKit (freely available EAP) snapshot I could
send you if it helps.
Here is what I'm getting, which seems repeatable over and over in my
environment:
Startup: 9k loaded classes, no unloaded classes, 49 MB PermGen
First redeployment: 15k loaded classes, no unloaded classes, 77 MB
PermGen = one extra instance of the app with 6k classes loaded. Assumed
a total of 2 classloaders
Second redeployment: 15k loaded classes, 6k unloaded classes, 77 MB
PermGen = initial/first(?) instance GC:ed and a new one loaded. Still 2
classloaders.
Third redeployment: 21k loaded classes, 6k unloaded classes, 105 MB
PermGen = one extra instance of the app with 6k classes loaded, nothing
GC:ed. Assumed a total of 3 classloaders
Fourth redeployment: 21k loaded classes, 12k unloaded classes, 105 MB
PermGen = second(?) instance GC:ed and a new one loaded. Still 3
classloaders.
(Fifth redeployment: 15k loaded classes, 24k unloaded classes, 77 MB
PermGen = third and fourth(?) instance GC:ed and a new one loaded. 2
classloaders. Haven't repeated this test enough to build a thesis)
Not sure if this a real problem, but ideally the
class loader of the previous version should be available for garbage
collection before the classes of the new version are loaded ('cause
there is no turning back anyway, is there...?).
In the past this could be a problem with JNI because a JNI library can
only be loaded in one classloader (that may have been changed but it
always was a JDK restriction.)
Are you saying this shouldn't be a issue in 4.0.2/snapshot running on
JDK 1.6?
--
/Mattias
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] 4.0.2 schedule
Resin 4.0.2 can now be found on the download page, and for anyone else wondering, the syntax to use Java session serialization seems to be like this: session-config ... serialization-typejava/serialization-type /session-config Mattias Mattias Jiderhamn wrote (2009-10-14 08:55): This reminds me; what is the syntax for enabling Java serialization for persistent store (as of http://bugs.caucho.com/view.php?id=3648)? /Mattias Wesley Wu wrote (2009-10-13 23:07): Yes, I turned on use-persistent-store/ (simply copied from my previous 4.0.0 conf file). When I turned it off (commented them out) !-- enable persistent sessions session-config use-persistent-store/ /session-config -- @SessionScope worked fine. Thanks. -Wesley 2009/10/14 Scott Ferguson f...@caucho.com mailto:f...@caucho.com 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 use-persistent-store/ 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 -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Hibernate lazy loading with Quercus
Alex wrote (2009-11-24 06:01):
Hello,
we try to do the following on our php/EJB3 application :
• find a given client from its lastname using a stateless bean ()
• load his orders using the getter
[code]
$clients = $client_eao-findBySample($sample_client,false,false);
var_dump($clients[0]-getOrders());
[/code]
Seems that the objects no longer have the association with valid session, so
either the Session or PersistenceManager should be kept around to fill the
objects in upon use. Forcing eager load could also be used I think.
Alex.
I assume the easiest route here is to use a Filter to achieve
session/transaction per request.
/Mattias
We get the usual LazyInitializationException :
[10:41:03.300] {http--8080-6$31582617}
org.hibernate.LazyInitializationException: failed to lazily initialize a
collection of role: com.opticneo.entity.client.Client.orders, no session or
session was closed
If we were using Hessian, before returning the list of clients we would have
made a copy of the list (using beanlib) before it is serialized (in ordre to
avoid LazyInitializationException)
With Quercus, we do not have to do this. Good ! But we face the
LazyInitializationException again when trying to access the complex attributes.
What is the best way to handle this ? (maybe by taking control over the
transaction from the php)
Thanks for your help.
Regards
--
Vincent LAUGIER
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Tabulation evil
I have been asking myself the same question... Jeff Schnitzer wrote (2009-10-28 00:41): This is really just a point of curiosity... What editor are you guys using at Caucho? I've noticed all the code is formatted using a bizarre combination of tabs and spaces, like this: 1 indent = 4 spaces 2 indents = 1 tab 3 indents = 1 tab + 4 spaces 4 indents = 2 tabs 5 indents = 2 tabs + 4 spaces ...which, setting aside longstanding religious wars about tabs vs spaces, seems to combine the worst characteristics of each approach. I'm not really complaining, since Eclipse will fix it for me with two mouse clicks, but I'm terribly curious to know what editor can even be configured to abuse code like that :-) Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] NoSuchMethodError
Given your previous posts I assume you've just upgraded from 3.0 and in that case, you need to make sure the WEB-INF/work directory is cleared so JSPs can be compiled by the new Resin version. /Mattias - Original Message - Subject: [Resin-interest] NoSuchMethodError Date: Thu, 1 Oct 2009 10:25:33 -0400 From: Rom Sok Hi, I am trying to deploy my application on Resin 3.1.9 and when I access my app at localhost:8080/ I get the following error on the Resin console: [10:20:58.631] java.lang.NoSuchMethodError: com.caucho.jsp.JavaPage.addDepend(Ljava/util/ArrayList;L com/caucho/make/PersistentDependency;)V [10:20:58.631] at _jsp._home__jsp.init(_home__jsp.java:181) [10:20:58.631] at com.caucho.jsp.JspManager.preload(JspManager.java:320) [10:20:58.631] at com.caucho.jsp.JspManager.compile(JspManager.java:218) [10:20:58.631] at com.caucho.jsp.JspManager.createPage(JspManager.java:171) [10:20:58.631] at com.caucho.jsp.JspManager.createPage(JspManager.java:150) [10:20:58.631] at com.caucho.jsp.PageManager.getPage(PageManager.java:248) [10:20:58.631] at com.caucho.jsp.PageManager.getPage(PageManager.java:178) [10:20:58.631] at com.caucho.jsp.PageManager.getPage(PageManager.java:161) [10:20:58.631] at com.caucho.jsp.QServlet.getSubPage(QServlet.java:295) [10:20:58.631] at com.caucho.jsp.QServlet.getPage(QServlet.java:210) [10:20:58.631] at com.caucho.server.dispatch.PageFilterChain.compilePage(PageFilterChain.java:238) [10:20:58.631] at com.caucho.server.dispatch.PageFilterChain.doFilter(PageFilterChain.java:145) [10:20:58.631] at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:187) [10:20:58.631] at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:265) [10:20:58.631] at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:273) [10:20:58.631] at com.caucho.server.port.TcpConnection.run(TcpConnection.java:682) [10:20:58.631] at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:743) [10:20:58.631] at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:662) [10:20:58.631] at java.lang.Thread.run(Thread.java:619) Could you please let me know what it means and how to remove it? Thanks. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Avoid HTTP/1.1 requires host
Is there any setting which would allow Resin to silently ignore connections that cause the following error? com.caucho.server.dispatch.BadRequestException: HTTP/1.1 requires host at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:261) at com.caucho.server.port.TcpConnection.handleRequests(TcpConnection.java:579) at com.caucho.server.port.TcpConnection$AcceptTask.doAccept(TcpConnection.java:1357) at com.caucho.server.port.TcpConnection$KeepaliveTask.run(TcpConnection.java:1435) at com.caucho.util.ThreadPool$PoolThread.runTasks(ThreadPool.java:874) at com.caucho.util.ThreadPool$PoolThread.run(ThreadPool.java:787) -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Cookie security over SSL (https) connections - Sent Using Google Toolbar
I think you need to make sure you are using an SSL connection
(request.isSecure()) before you create the Cookies in the first place.
The behaviour when changing a non-secure cookie to a secure one may be
browser dependant.//
//
/Mattias
//
//Abhinav Gupta wrote (2009-09-10 14:34):
Thanks Jeff,
But we are creating no cookies by our own. Our requirement is to just
secure the Apache OR Resin created Cookies for session management.
So we created a generic filter for that.
Regards,
Abhinav
[Resin-interest] Cookie security over SSL (https) connections
http://maillist.caucho.com/pipermail/resin-interest/2009-September/004027.html
[Resin-interest] Cookie security over SSL (https) connections
*Jeff Schnitzer* jeff at infohazard.org
mailto:resin-interest%40caucho.com?Subject=%5BResin-interest%5D%20Cookie%20security%20over%20SSL%20%28https%29%20connectionsIn-Reply-To=915837840909090344ye834f35t23cbd41bd44c423b%40mail.gmail.com
/Wed Sep 9 09:30:32 CDT 2009/
* Previous message: [Resin-interest] Cookie security over SSL
(https) connections
http://maillist.caucho.com/pipermail/resin-interest/2009-September/004026.html
* *Messages sorted by:* [ date ]
http://maillist.caucho.com/pipermail/resin-interest/2009-September/date.html#4027
[ thread ]
http://maillist.caucho.com/pipermail/resin-interest/2009-September/thread.html#4027
[ subject ]
http://maillist.caucho.com/pipermail/resin-interest/2009-September/subject.html#4027
[ author ]
http://maillist.caucho.com/pipermail/resin-interest/2009-September/author.html#4027
Why aren't you creating the cookies with setSecure(true) in the first place?
If you have tons of legacy code that sets cookies, why not create a
Filter that wraps HttpServletResponse (there is a convenient
HttpServletResponseWrapper for this), intercepts the addCookie()
method calls, and calls setSecure(true)?
If you want this value set, you need to set it outbound, not after
they've already been to the browser.
Jeff
On Wed, Sep 9, 2009 at 3:44 AM, Abhinav Guptaabhinav at appirio.com
http://maillist.caucho.com/mailman/listinfo/resin-interest wrote:
/ Hi All,
//
//
// This problem is regarding cookie security over SSL(https). We are running
a
// J2EE webapplication, our motive is to get the cookie's isSecure flag set
// to true. We tried researching around the resin config settings for this
but
// no luck. Details of the approach we tried and the issue faced are
elaborated
// below.
//
// Enviornment Details
//
// 1. Resin 3.1.7 server running a webapplication called tool
// 2. Apache is in the front forwarding/redirecting all inbound traffic to
the
// resin server.
// 3. Apache is setup with trusted SSL certificates from godaddy.
//
//
// Problem Details
//
// By default for all secure https requests, resin is sending cookies back
with
// isSecure flag as false.
// We tried looking for resin config settings to fix this, but can't find any
// setting. So we created a Servlet filter in our webapp
// to trap all inbound requests and manually set the isSecure flag to true.
//
// This servlet filter approach partially fixed the problem. We are saying
// partially because there are two cookies created by
// the application in browser.
//
// Cookie 1: Its path is domain name/ and the isSecure flag is false
// Cookie 2: Its path is domain name/tools and the isSecure flag is
true
//
// So Cookie 2 is as expected, but Cookie 1 is not coming secured, to fix
this
// we tried deploying the same servlet filter in the ROOT webapp of resin.
But
// the problem persisted as before.
//
//
// Here is the servlet filter code.
//
// public class CookieFilter implements Filter {
//
// public void doFilter(ServletRequest req, ServletResponse res,
// FilterChain chain) throws ServletException, IOException {
// // Secure if its a Http based request
// if (req instanceof HttpServletRequest) {
// HttpServletRequest httpReq = (HttpServletRequest) req;
// HttpServletResponse httpRes = (HttpServletResponse) res;
// Cookie[] cookies = httpReq.getCookies();
// if (cookies != null cookies.length 0) {
// for (Cookie cookie : cookies) {
// // Make the cookie secure
// cookie.setSecure(true);
// // Add it to the response
// httpRes.addCookie(cookie);
// }
// }
// }
// chain.doFilter(req, res);
// }
//
// public void init(FilterConfig arg0) throws ServletException {
// }
//
// public void destroy() {
// }
//
// }
//
// Please suggest.
//
// Regards,
// Abhinav
/
[Resin-interest] HttpSessionBindingListener.valueUnbound() not always called in Resin 4...?
After about a week with Resin 4.0.1 in production environment, we have twice seen symptoms indicating that a value implementing HttpSessionBindingListener has been removed from a session, without its valueUnbound() method being called. Has anyone else seen this? Are there any circumstances where such behavior should be expected...? -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Non-Hessian file store?
http://docs.jboss.org/hibernate/stable/core/reference/en/html/transactions.html#transactions-basics-apptx Jon Stevens wrote (2009-08-26 21:48): You put Hibernate objects into the session? jon On Wed, Aug 26, 2009 at 8:37 AM, Mattias Jiderhamn mj-li...@expertsystems.se mailto:mj-li...@expertsystems.se wrote: In Resin 4 persistent-store type=file seems to use Hessian for serializing the session values. This causes some trouble for us since Hessian in some cases tries to access uninitialized Hibernate collections after the session/transaction is closed. Is there a way to revert Resin 4 to the old behaviour...? -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Non-Hessian file store?
Well, there are different opinions about DTOs too. I assume you've heard (Spring developer) Rod Johnsons take on the matter...? /Mattias Jon Stevens wrote (2009-08-27 17:35): Yea, just cause Hibernate has that feature doesn't mean it is a good feature. =) You may want to consider the DTO pattern... http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html I've found that over time, the pain of creating and dealing with DTO's is mitigated by the cleanliness of it and you don't run into weird issues like you are running into... jon On Thu, Aug 27, 2009 at 12:05 AM, Mattias Jiderhamn mj-li...@expertsystems.se mailto:mj-li...@expertsystems.se wrote: http://docs.jboss.org/hibernate/stable/core/reference/en/html/transactions.html#transactions-basics-apptx Jon Stevens wrote (2009-08-26 21:48): You put Hibernate objects into the session? jon On Wed, Aug 26, 2009 at 8:37 AM, Mattias Jiderhamn mj-li...@expertsystems.se mailto:mj-li...@expertsystems.se wrote: In Resin 4 persistent-store type=file seems to use Hessian for serializing the session values. This causes some trouble for us since Hessian in some cases tries to access uninitialized Hibernate collections after the session/transaction is closed. Is there a way to revert Resin 4 to the old behaviour...? -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Non-Hessian file store?
In Resin 4 persistent-store type=file seems to use Hessian for serializing the session values. This causes some trouble for us since Hessian in some cases tries to access uninitialized Hibernate collections after the session/transaction is closed. Is there a way to revert Resin 4 to the old behaviour...? -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] min-free-memory
What happened to the min-free-memory config tag in Resin 4? Still available? Where to put it? -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] min-free-memory
Emil Ong wrote (2009-08-20 17:28): On Thu, Aug 20, 2009 at 05:21:45PM +0200, Mattias Jiderhamn wrote: What happened to the min-free-memory config tag in Resin 4? Still available? Where to put it? Hi Mattias, It has changed to memory-free-min. Which, for the record, is a child of server-default -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Non-interpreted EL expressions?
Is there a way to make Resin not try interpreting EL expressions in JSP
pages (while still using fast jstl)?
We have custom tags with string attributes which are evaluated as EL
expressions using the Apache Taglibs implementation. After updating to
4.0, Resin refuses to treat these attributes as Strings.
Example:
com.caucho.jsp.JspLineParseException:
/html/partners/partner_addressEdit.jsp:30: EL expression
'${defaultAddress.address}' is only allowed for attributes with
rtexprvalue='true'.
...
30:exder:get value=${defaultAddress.address}
...
at com.caucho.jsp.java.JspNode.error(JspNode.java:1883)
at com.caucho.jsp.java.JspNode.error(JspNode.java:1872)
at com.caucho.jsp.java.JspNode.generateParameterValue(JspNode.java:1292)
...
When adding rtexprvaluetrue/rtexprvalue to the .tld, Resin will
evaluate the expression and pass the String value of the result as the
attribute of the tag. The tag will then try to evaluate this String
value as if it was an EL expression (using the Apache) implementation,
which of course does not give the expected result.
Do we have to change the implementation of all the tags to use
com.caucho.el.Expr instead, or is there another way?
--
/Mattias
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Updating Hessian in Resin 4.0 deployments
Hessian was extracted to a separate hessian.jar in the Resin dist a while back, which made it possible to upgrade Hessian without changing Resin version. For some reason hessian was moved back into resin.jar. /Mattias Scott Ferguson wrote (2009-06-18 00:16): On Jun 17, 2009, at 2:10 PM, Rick Mann wrote: On Jun 17, 2009, at 13:58:29, Scott Ferguson wrote: On Jun 17, 2009, at 1:48 PM, Rick Mann wrote: If I download/build a separate Hessian library and drop it into my WEB- INF/lib directory, will it get used instead of the one built-in to Resin? No, you need to put the replacement in the CLASSPATH (so it's loaded before the resin.jar). In Java, the parent classloaders have priority (that order is needed because of class cast issues.) So any hessian in WEB-INF/lib would be ignored. Hmm. I've always tried to steer far clear of putting anything on the CLASSPATH when running servlet containers. I don't know if I learned that back when I used Tomcat, or if it was something Resin recommended. Well, it's normally not a good idea, but it's how you would override hessian. A better alternative would be for me to get to a place where I build resin and run my build; this would allow me to insert logging to help me figure out problems when I run into them all across resin, let alone just Hessian. But Hessian is my most urgent need right now. Are there instructions for building Resin anywhere? You should be able to just download the source and use ant. I think we cleared up the dependencies (with the exception of 'ant dist'). -- Scott -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] No sessions in Resin 4
Scott Ferguson wrote (2009-06-05 18:11): On Jun 3, 2009, at 10:59 PM, Mattias Jiderhamn wrote: Done a bit more debugging and I have arrived at com.caucho.server.distcache.FileCacheManager.put() which does nothing but return null!? Should persistent-store type=file work at all...? Yikes. All of our testing for sessions was against Resin Pro, which uses the cluster version. I've refactored the code, and added open source testing for the basic session behavior. I though I'd try this out by building Resin from trunk using Ant but I'm running into multiple issues when compiling with JDK 1.6.0_11. Is there documentation somewhere on building Resin from sources...? /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] No sessions in Resin 4
Scott Ferguson wrote (2009-06-03 23:52): On Jun 3, 2009, at 1:08 PM, Mattias Jiderhamn wrote: Scott Ferguson wrote (2009-06-03 21:17): Can you check the permissions, particularly of the resin-data directory? We had some trouble at the end of the release cycle with permissions issues on the created directories, and it's possible we didn't catch all of the cases. I'm pretty sure it's not related to permissions. Running with full permissions, tried deleting resin-data dir and it is recreated. Should I send you the files in it??? Sure. The important ones should be resin_data_default.db and resin_mnode_default.db. Done a bit more debugging and I have arrived at com.caucho.server.distcache.FileCacheManager.put() which does nothing but return null!? Should persistent-store type=file work at all...? I've added a bug report for the junction issue. It's not something I'm familiar with. I don't think there is a junction issue. I've had this configuration for a long time just changing the target of the junction/symbolic link. But somehow the RESIN_HOME environment variable takes precedence over the resin.exe location and that affects sessions somehow. Yes, that is exactly what is happening, so I was running 3.1.8 when the sessions worked... *blush* /Mattias Scott Ferguson wrote (2009-06-02 23:50): On Jun 2, 2009, at 12:29 PM, Mattias Jiderhamn wrote: I wrote on resin.conf = null when upgrading to Resin 4 (2009-06-02 06:48): Sitting here trying to upgrade the dev environment to Resin 4.0 with minimal changes to configuration and startup scripts. On Windows I'm up and running ... I apparently jumped the gun here. I am not up and running on Windows either. While picking up my resin.conf, Resin does not handle sessions but resets them on every request. Example fine log, first request: [20:56:44.359] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] new [20:56:44.359] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] create session ... Subsequent request: [20:57:27.250] Http[11] Cookie: JSESSIONID=aaaQKDKMBgGTm9hnkvIgs [20:57:27.750] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] reset [20:57:27.750] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] reset [20:57:27.750] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] new [20:57:27.750] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] create session The reset is normally a message that something went wrong in loading the session. I'll need to see if we can either improve the information or just fix the issue. The bug is at http://bugs.caucho.com/view.php?id=3545 Tried to find a configuration fault by debugging, but I end up really confused. When com.caucho.server.session.SessionImpl.save() is entered, I have a couple of values in the session, but when stepping into the isValid() the _values Map is suddenly empty??? Here is my session config: persistent-store type=file init pathc:\temp\resin-sessions/path always-savetrue/always-save /init /persistent-store FYI, this is ignored, currently, because the persistent store is always available (it lives in resin-data). You do still need use- persistent-store to enable the session to use it. -- Scott + session-config use-persistent-store / session-max4096/session-max session-timeout30/session-timeout /session-config -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Memory leak - in Resin?
My initial testing indicates that the leak indeed has been fixed in 4.0! I'll have to get back on this once I have our real application up and running in 4.0 /Mattias Mattias Jiderhamn wrote (2009-04-02 11:23): Scott Ferguson wrote (2009-03-30 18:20): On Mar 30, 2009, at 3:54 AM, Mattias Jiderhamn wrote: After drawing the conclusion below, it isn't very far away to realize it probably has to do with some static (i.e. class loader specific) member of EnvironmentClassLoader. And just as I thought, the heart of the problem is private static EnvironmentLocalArrayListAddLoaderListener _addLoaderListeners More specifically, if line 234 of com.caucho.server.resin.Resin is commented out, the leak is removed (assuming my HttpRequest._invocation patch is also applied) // Environment.addChildLoaderListener(new WebBeansAddLoaderListener()) Scott, you said the WebBeans caches were not to blame because they are classloader local. Well, it seems something about this classloader locality isn't working the way it should, doesn't it...? Do you have enough info to try to fix this in a future (hopefully soon to be released) 3.1 release? In the early work with 4.0, I'd cleaned a number of dead links (primarily WebBeans, but also some JMX). I believe the current 4.0 still has a few left, so I'll need to run a final pass at the end of the release cycle. Are you saying this won't be fixed in the 3.1 branch? I'm assuming the 4.0 production release is still months ahead? Could we provide you any additional information to change your mind...? ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] resin.conf = null when upgrading to Resin 4
Scott Ferguson wrote (2009-06-02 07:23): On Jun 1, 2009, at 9:48 PM, Mattias Jiderhamn wrote: Sitting here trying to upgrade the dev environment to Resin 4.0 with minimal changes to configuration and startup scripts. On Windows I'm up and running after a strange problem with a simple solution (deleting a default directory so that Resin would accept the explicit document-directory). On Linux however I'm still struggling. I think the heart of the problem is that Resin for some reason does not accept me trying to point out our old resin.conf file. [2009/06/02 06:33:08.066] resin.home = /u/resin/resin/ [2009/06/02 06:33:08.066] resin.root = /u/dna/exder.server.root [2009/06/02 06:33:08.066] resin.conf = null The arguments when starting Resin are -conf /u/dna/exder.server.root/conf/resin.conf -server-root /u/dna/exder.server.root and I also tried -conf /u/dna/exder.server.root/conf/resin.conf -root-directory /u/dna/exder.server.root Would anyone care to spare my time by telling me what I'm doing wrong here...? That's odd. What does the -verbose show as the command line passed to the Resin instance? Also, do you see the same with start as with non-start Actually, without start seems to work fine. -verbose command is then: /usr/java/jdk1.5.0_11/bin/java \ -Djava.util.logging.manager=com.caucho.log.LogManagerImpl \ -Djava.system.class.loader=com.caucho.loader.SystemClassLoader \ -Djavax.management.builder.initial=com.caucho.jmx.MBeanServerBuilderImpl \ -Djava.awt.headless=true \ -Dresin.home=/u/resin/resin/ \ -Xss1m \ -Xmn256M \ -Xms512M \ -Xmx1024M \ -XX:MaxPermSize=128M \ -d64 \ -server \ com.caucho.server.resin.Resin \ --root-directory \ /u/dna/exder.server.root \ -conf \ /u/dna/exder.server.root/conf/resin.conf \ -socketwait \ 51562 \ -verbose \ -server-root \ /u/dna/exder.server.root With start the command is /usr/java/jdk1.5.0_11/bin/java \ -Djava.util.logging.manager=com.caucho.log.LogManagerImpl \ -Djava.system.class.loader=com.caucho.loader.SystemClassLoader \ -Djavax.management.builder.initial=com.caucho.jmx.MBeanServerBuilderImpl \ -Djava.awt.headless=true \ -Dresin.home=/u/resin/resin/ \ -Xss1m \ -Xmn256M \ -Xms512M \ -Xmx1024M \ -XX:MaxPermSize=128M \ -Djava.util.logging.manager=com.caucho.log.LogManagerImpl \ -Djavax.management.builder.initial=com.caucho.jmx.MBeanServerBuilderImpl \ -Djava.awt.headless=true \ -Dresin.home=/u/resin/resin/ \ -Dresin.root=/u/dna/exder.server.root \ -Djava.util.logging.manager=com.caucho.log.LogManagerImpl \ -Djavax.management.builder.initial=com.caucho.jmx.MBeanServerBuilderImpl \ -Djava.awt.headless=true \ -Dresin.home=/u/resin/resin/ \ -Dresin.root=/u/dna/exder.server.root \ -d64 \ -server \ com.caucho.server.resin.Resin \ --root-directory \ /u/dna/exder.server.root \ -conf \ /u/dna/exder.server.root/conf/resin.conf \ -socketwait \ 51666 \ -verbose \ -server-root \ /u/dna/exder.server.root \ start \ --log-directory \ /u/dna/exder.server.root/log /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] No sessions in Resin 4
I wrote on resin.conf = null when upgrading to Resin 4 (2009-06-02 06:48): Sitting here trying to upgrade the dev environment to Resin 4.0 with minimal changes to configuration and startup scripts. On Windows I'm up and running ... I apparently jumped the gun here. I am not up and running on Windows either. While picking up my resin.conf, Resin does not handle sessions but resets them on every request. Example fine log, first request: [20:56:44.359] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] new [20:56:44.359] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] create session ... Subsequent request: [20:57:27.250] Http[11] Cookie: JSESSIONID=aaaQKDKMBgGTm9hnkvIgs [20:57:27.750] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] reset [20:57:27.750] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] reset [20:57:27.750] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] new [20:57:27.750] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] create session Tried to find a configuration fault by debugging, but I end up really confused. When com.caucho.server.session.SessionImpl.save() is entered, I have a couple of values in the session, but when stepping into the isValid() the _values Map is suddenly empty??? Here is my session config: persistent-store type=file init pathc:\temp\resin-sessions/path always-savetrue/always-save /init /persistent-store + session-config use-persistent-store / session-max4096/session-max session-timeout30/session-timeout /session-config -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
