[Resin-interest] JPA 2.1 (was Re: Resin 4 and Java 8)

[Mattias Jiderhamn]

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 Map resolvers =
 (Map) 
ReflectionUtils.getPrivateField(persistenceProviderResolver, "resolvers");
 PersistenceProviderResolver clPersistenceProviderResolver = 
resolvers.get(Thread.currentThread().getContextClassLoader());

 final List>> 
resolverClasses = (List>>)
ReflectionUtils.getPrivateField(clPersistenceProviderResolver, 
"resolverClasses");
 Iterator>> iter 
= resolverClasses.iterator();
 while(iter.hasNext()) {
   WeakReference> 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 

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  wrote:

 > > Message: 2
 > > Date: Tue, 24 Mar 2015 16:40:20 +
 > > From: Chris Pratt
 > > Subject: Re: [Resin-interest] [Resin] Resin 4 and Java 8
 > > To: General Discussion for the Resin application server
 > > 
 > > Message-ID:
 > >  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


-- 

   



___
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)

[Mattias Jiderhamn]

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 

Hi list. What options do I have if I want to use IP based security
behind an Apache proxy?

I want to use  or , 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...???

-- 




___
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)

[Mattias Jiderhamn]

Hi list. What options do I have if I want to use IP based security 
behind an Apache proxy?


I want to use  or , 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...???


--

  

___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] JPA 2.1 + Resin

[Mattias Jiderhamn]

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  /   
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  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.

-- 

   



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Resin and java:comp/ValidatorFactory

[Mattias Jiderhamn]

I reported the problem below as a bug at 
http://bugs.caucho.com/view.php?id=5587 which was marked as fixed to 
version 4.0.40

The release notes for 4.0.40 says "bind java:comp/BeanValidation 
(#5587)" and I can confirm in the code that the JNDI name in use indeed 
is java:comp/BeanValidation, rather than java:comp/ValidatorFactory
Problem is, AFAI can see this does not solve the original issue. When 
replacing javax.faces-2.1.24.jar with jsf-api-2.2.5.jar + 
jsf-impl-2.2.5.jar bean validation does not work. I still have to 
configure java:comp/ValidatorFactory within our application.

(Googling "java:comp/BeanValidation" only has 1 hit: the Resin 4.0.40 
release notes mentioned above, so where does that even come from...?)

Should I create a new issue, or will 
http://bugs.caucho.com/view.php?id=5587 be reopened?

For the record, seems that Mojarra 2.2.7 will take care of container 
backwards compatibility https://java.net/jira/browse/JAVASERVERFACES-3183

  

> 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...?


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] Resin development progress

[Mattias Jiderhamn]

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

-- 

   


___
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

[Mattias Jiderhamn]

>> 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 s 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.

-- 

   


___
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

[Mattias Jiderhamn]

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 s 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?


--

  

___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] Maven repo

[Mattias Jiderhamn]

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...?

-- 

   


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] ExtensionManager is drive letter case sensitive

[Mattias Jiderhamn]

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 Enumeration 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.(ResinSystem.java:145)
  at com.caucho.env.service.ResinSystem.(ResinSystem.java:99)
  at com.caucho.server.resin.Resin.(Resin.java:236)
  at com.caucho.server.resin.Resin.(Resin.java:182)
  at com.caucho.server.resin.Resin.main(Resin.java:1436)

-- 

   


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] Resin and java:comp/ValidatorFactory

[Mattias Jiderhamn]

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...?

-- 

   


___
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

[Mattias Jiderhamn]

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/

-- 

   



___
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

[Mattias Jiderhamn]

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.

-- 

   



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] JSF classloader leak triggered by Resin EL

[Mattias Jiderhamn]

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.

-- 

   


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] help on resizing image

[Mattias Jiderhamn]

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.)

  

- Original Message -
Subject: [Resin-interest] help on resizing image
Date: Thu, 07 Feb 2013 11:14:00 +0100
From: Riccardo Cohen 

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




___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] Disable archive/rollback?

[Mattias Jiderhamn]

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.(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)

-- 

   


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] System.getenv() behaves differently

[Mattias Jiderhamn]

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)

-- 

   


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Easing Development

[Mattias Jiderhamn]

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/

  

- Original Message -
Subject: Re: [Resin-interest] Easing Development
Date: Fri, 4 Jan 2013 04:31:03 -0800
From: Rick Mann 

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

[Resin-interest] Last Resource Commit Optimization / Last Resource Gambit

[Mattias Jiderhamn]

Is there any way to achieve Last Resource Commit Optimization / Last 
Resource Gambit with Resins XA/JTA implementation...?

-- 

   


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] 4.0.33 ETA?

[Mattias Jiderhamn]

Any news on the 4.0.33 release?

   

--- Original Message -
Subject: Re: [Resin-interest] 4.0.33 ETA?
Date: Thu, 22 Nov 2012 10:17:29 -0500
From: Paul Cowan 

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?

[Mattias Jiderhamn]

Hi. We are anticipating the upcoming 4.0.33 release that should resolve 
a couple of "our" bugs. What is the ETA?

-- 

   


___
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

[Mattias Jiderhamn]

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 
java.io.ObjectOutputStream.writeObje

[Resin-interest] Up-to-date remote deploy strategy

[Mattias Jiderhamn]

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

-- 

   


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] Old files not removed at redeploy

[Mattias Jiderhamn]

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?)

-- 

   


___
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?

[Mattias Jiderhamn]

- 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 


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...?


--

  


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Resin 4 stability

[Mattias Jiderhamn]

- Original Message -
Subject: [Resin-interest] Resin 4 stability
Date: Thu, 19 Jul 2012 09:53:47 -0500
From: "Aaron Freeman" 
>
> 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!

-- 

   


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Set JSF response encoding

[Mattias Jiderhamn]

Don't bother - that turned out to be the detour...



- Original Message -
Subject: [Resin-interest] Set JSF response encoding
Date: Wed, 27 Jun 2012 20:26:54 +0200
From: Mattias Jiderhamn 

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  is set to it).

What is the most appropriate way to make the response UTF-8,
alternatively undeclared encoding, preferrably for JSF pages only?

--



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] Set JSF response encoding

[Mattias Jiderhamn]

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  is set to it).

What is the most appropriate way to make the response UTF-8, 
alternatively undeclared encoding, preferrably for JSF pages only?

-- 

   


___
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

[Mattias Jiderhamn]

- 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 

> 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 Jiderhamn
> >>> 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?

-- 

   


___
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

[Mattias Jiderhamn]

- 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 
>
> > - 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 
> >
> > 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?

-- 

   


___
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

[Mattias Jiderhamn]

- 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 

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

Is it possible that this code is from a forward? I just closed a bug
where a forwarded form would try to double-read the content.

Otherwise, this looks new.

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.


Might be worth noting: If you press Stop in the browser, the server side 
execution coninues normally. Otherwise it times out after 120 seconds.


Example (posted in Mantis as well):
JSP:


<%-- 76 fails, 75 is ok --%>

  ${i}: 






Servlet:
@MultipartConfig(fileSizeThreshold = 1024 * 1024, maxRequestSize = 100 * 
1024 * 1024)

public class MultipartServlet extends HttpServlet {
  @Override
  protected void service(HttpServletRequest request, 
HttpServletResponse res) throws ServletException, IOException {

System.out.println("Content length: " + request.getContentLength());
final long start = System.currentTimeMillis();
try {
  System.out.println("Getting parts ...");
  final Collection parts = request.getParts();
  System.out.println("No of parts: " + parts.size());
}
finally {
  System.out.println("Done trying to parse; took " + 
(System.currentTimeMillis() - start) + " ms");

}
  }
}



___
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

[Mattias Jiderhamn]

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)
 ...

-- 

   


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Out of PermGen space

[Mattias Jiderhamn]

> 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 Jiderhamn
> >>
> >> 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.



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Out of PermGen space

[Mattias Jiderhamn]

> - Original Message -
> Subject: Re: [Resin-interest] Out of PermGen space
> Date: Fri, 27 Apr 2012 11:23:41 +0200
> From: Mattias Jiderhamn 
>
> 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.



>
> 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 "
> 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.
>
> 
>
>
-- 

___
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)

[Mattias Jiderhamn]

- 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 

...


> > 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.
--



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Out of PermGen space

[Mattias Jiderhamn]

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

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 " 
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.



- Original Message -
Subject: Re: [Resin-interest] Out of PermGen space
Date: Wed, 25 Apr 2012 15:04:53 -0700
From: Rick Mann 

Thanks, Mattias, that's cool!

-- 
Rick

On Apr 24, 2012, at 22:17 , Mattias Jiderhamn wrote:

 > 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!
 >
 > 
 >
 > 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 
 >
 > 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
 >
 >
 > --
 >
 > 
 >
 > ___
 > resin-interest mailing list
 > resin-interest@caucho.com
 > http://maillist.caucho.com/mailman/listinfo/resin-interest


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

-- 

   



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] Out of PermGen space

[Mattias Jiderhamn]

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!



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 

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


--

  

___
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)

[Mattias Jiderhamn]

- Original Message -
Subject: Re: [Resin-interest] Override EL implementation (help us stay 
with Resin)

Date: Wed, 18 Apr 2012 11:48:34 -0700
From: Scott Ferguson 


On 04/17/2012 12:40 PM, Mattias Jiderhamn wrote:
>
> - Original Message -
> Subject: Re: [Resin-interest] Override EL implementation (help us stay
> with Resin)
> Date: Mon, 16 Apr 2012 13:12:15 -0700
> From: Scott Ferguson 
> > 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?
>>
>> Correct. Fixing those bugs are generally pretty simple, because 
they're

>> fairly small in functionality.
>
> Well, I feel like a n00b after having realized the most severe
> problems we're actually caused by the fact that a team member (who is
> running JBoss locally) had set com.sun.faces.expressionFactory
> parameter to com.sun.el.ExpressionFactoryImpl. So there was a mixture
> of two implementations. Sorry for blaming Resin! *blush*
>
> After changing the setting to com.caucho.el.ExpressionFactoryImpl (or
> rather a proxy using com.caucho.el.ExpressionFactoryImpl if present),
> the problems turning are much less severe.
>
> 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.


--

  

___
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)

[Mattias Jiderhamn]

- Original Message -
Subject: Re: [Resin-interest] Override EL implementation (help us stay 
with Resin)

Date: Mon, 16 Apr 2012 13:12:15 -0700
From: Scott Ferguson 
> 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?

Correct. Fixing those bugs are generally pretty simple, because they're
fairly small in functionality. 


Well, I feel like a n00b after having realized the most severe problems 
we're actually caused by the fact that a team member (who is running 
JBoss locally) had set com.sun.faces.expressionFactory parameter to 
com.sun.el.ExpressionFactoryImpl. So there was a mixture of two 
implementations. Sorry for blaming Resin! *blush*


After changing the setting to com.caucho.el.ExpressionFactoryImpl (or 
rather a proxy using com.caucho.el.ExpressionFactoryImpl if present), 
the problems turning are much less severe.


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)


I do want to ask, why Resin is using a custom EL implementation rather 
than the Sun implementation? Performance? Licensing?
In case there is good reason to stick with custom implementation, and 
the above two bugs are fixed, I guess 
http://bugs.caucho.com/view.php?id=5011 can be closed.


--

  

___
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)

[Mattias Jiderhamn]

- 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 


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?






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 the 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
> javax.el.
> 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] Override EL implementation (help us stay with Resin)

[Mattias Jiderhamn]

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  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 
javax.el.
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

Re: [Resin-interest] JMS queue in database

[Mattias Jiderhamn]

Seems that the syntax is



however it is not implemented?



- Original Message -
Subject: [Resin-interest] JSM queue in database
Date: Mon, 12 Mar 2012 20:52:33 +0100
From: Mattias Jiderhamn 

How can I use a DataSource (or simply a JDBC accessible SQL database) as
the storage for the Resin JMS Queue implementation?

-- 




___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] JSM queue in database

[Mattias Jiderhamn]

How can I use a DataSource (or simply a JDBC accessible SQL database) as 
the storage for the Resin JMS Queue implementation?

-- 

   



___
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()

[Mattias Jiderhamn]

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.

-- 

   



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Change classloader precedence / priority / order

[Mattias Jiderhamn]

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

javax.el
(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?



- Original Message -
Subject: [Resin-interest] Change classloader precedence / priority / order
Date: Thu, 12 Jan 2012 15:40:49 +0100
From: Mattias Jiderhamn 

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...?

-- 





___
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

[Resin-interest] Change classloader precedence / priority / order

[Mattias Jiderhamn]

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...?

-- 

   



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Starting Services at Resin Startup

[Mattias Jiderhamn]

 > 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:





-- 

   



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] Local deploy after remote deploy

[Mattias Jiderhamn]

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?

-- 

   



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Resin 4 Configuration Sanity Check

[Mattias Jiderhamn]

To answer one part of your question:

> Additionally the application is started as root and for the app tier we
> use  and  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.





___
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

[Mattias Jiderhamn]

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?



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
>   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?
>>
>> 
>>
>> 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


-- 

   



___
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

[Mattias Jiderhamn]

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?



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...?

[Mattias Jiderhamn]

We're still seeing this issue at random under 4.0.18 :-(

http://bugs.caucho.com/view.php?id=4290



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
>>
>> 
>>
>>> 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

Re: [Resin-interest] Resin no longer deploys my war

[Mattias Jiderhamn]

Just do double check, you are running both the watchdog process and the 
actual Resin instance as root?

Anything on the finest logging level?



- Original Message -
Subject: Re: [Resin-interest] Resin no longer deploys my war
Date: Tue, 24 May 2011 02:26:44 -0700
From: Jeff Schnitzer 

It does sound like that, but I'm running Resin as root.

Jeff

On Tue, May 24, 2011 at 1:56 AM, Mattias Jiderhamn
 wrote:
 > Sounds like a file permission issue, but you've checked that, haven't
 > you...?
 >
 > 
 >
 > - Original Message -
 > Subject: [Resin-interest] Resin no longer deploys my war
 > Date: Tue, 24 May 2011 01:52:04 -0700
 > From: Jeff Schnitzer 
 >
 > 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


-- 

   



___
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

[Mattias Jiderhamn]

Sounds like a file permission issue, but you've checked that, haven't 
you...?



- Original Message -
Subject: [Resin-interest] Resin no longer deploys my war
Date: Tue, 24 May 2011 01:52:04 -0700
From: Jeff Schnitzer 

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] Multiple instances of the same webapp after redeploy in 4.0.16 (strange!!!)

[Mattias Jiderhamn]

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 (>>> ... />) were having concurrency issues and logging the same event 
>>>> twice within the same second.
>>>> This made me add some extra logging in a  
>>>> 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?

-- 

   



___
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!!!)

[Mattias Jiderhamn]

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 (> />) were having concurrency issues and logging the same event twice 
>> within the same second.
>> This made me add some extra logging in a  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...?)

-- 

   



___
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!!!)

[Mattias Jiderhamn]

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 () were having concurrency issues and logging the same event twice 
within the same second.
This made me add some extra logging in a  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???

-- 

   



___
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

[Mattias Jiderhamn]

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:


...
java





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
>> com.caucho.hess

[Resin-interest] Remote deploy still broken in 4.0.16

[Mattias Jiderhamn]

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

results in "resin-deploy doesn't support the "resin-home" attribute"

Sigh

-- 

   



___
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

[Mattias Jiderhamn]

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?

-- 

   



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] What is http://admin.resin ?

[Mattias Jiderhamn]

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?

-- 

   



___
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

[Mattias Jiderhamn]

Have you tried without versioning="true"?
--


- 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 

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 "" defined under my "" tag. I also
have the tag ""
defined under my "" 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 ""
from the resin.xml file, then ROOT.war expansion occurs.

Do I need to add an attribute to the  tag to get the war file to expand?

Also, what is the difference between the attribute "root-directory" and
"document-directory" in the  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 ""

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

[Mattias Jiderhamn]

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?




___
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

[Mattias Jiderhamn]

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)

-- 

   



___
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

[Mattias Jiderhamn]

Never got an answer so I posted a bug at 
http://bugs.caucho.com/view.php?id=4301

   


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

[Mattias Jiderhamn]

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

Re: [Resin-interest] Writer and OutputStream mixup in 4.0.10...?

[Mattias Jiderhamn]

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...?



> 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...?

[Mattias Jiderhamn]

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)
 ...

-- 

   



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Remote deployment

[Mattias Jiderhamn]

   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???




Scott Ferguson skrev:
> Mattias Jiderhamn wrote:
>
>> After adding a commitmessage, which according to the Wiki is optional,
>> I'm told I need to add a  tag.
>> When reading http://www.caucho.com/resin/admin/deploy.xtp carefully, the
>> text says  but the example shows
>> 
>> 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 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 atag 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
>>>> ), 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

Re: [Resin-interest] resin.exe server root directory in 4.0.10

[Mattias Jiderhamn]

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

-- 

   



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Custom startup recommendation

[Mattias Jiderhamn]

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...?



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 
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.



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
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...?

--







___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Custom startup recommendation

[Mattias Jiderhamn]

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.




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 
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...?

--





___
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

[Mattias Jiderhamn]

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?

-- 

   



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] Custom startup recommendation

[Mattias Jiderhamn]

(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...?

-- 

   



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Quercus Question

[Mattias Jiderhamn]

PHP include() resembles the JSP include directive
<%...@include file="foo.jsp" %>
which includes the referenced file assuming it contains source code that 
should also be parsed/compiled together with the current script.
See http://www.php.net/manual/en/function.include.php

What you want is the PHP equivalent of  which sends a 
request to the file and includes the response into the response of the 
current script (see 
http://java.sun.com/products/jsp/tags/11/syntaxref1112.html)
I don't know whether PHP supports such a feature out of the box, nor if 
Quercus has implemented it.



Aaron Freeman wrote (2010-08-12 18:19):
> The silence is deafening, so I guess I was completely wrong-headed in
> thinking you could call a .jsp as in include from a .php?
>
> Bummer, I was hoping that was part of the benefit of having php-based
> apps running under full blown Resin, instead of Quercus in stand alone mode.
>
> Thanks,
>
> Aaron
>
>
> On 8/12/2010 1:36 AM, Aaron Freeman wrote:
>
>> I was thinking it's possible to do something like this in a php file:
>>
>> >if((include '../www/_header.jsp') == 'OK') {
>>echo 'OK';
>>}
>> ?>
>>
>> Where the www folder has a path-mapping entry in the resin.xml.
>>
>> It includes the file, but the file isn't processed by the JSP engine, so
>> I literally see strings like "${param.var}" in the output of the call to
>> test.php.  How do I include a .jsp in from a .php but get the JSP engine
>> to process it before it returns?  I know I could do something like:
>>
>> include( 'http:///www/_header.jsp')
>>
>> but then cookies are lost as the client is the php engine, not the browser.
>>
>> Is it possible to reuse the JSP code from within the PHP environment?
>> Is there a link someone could shoot me that explains this?
>>
>> Thanks,
>>
>> Aaron
>>
>>  



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] cxf / soap with 4.0.8

[Mattias Jiderhamn]

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?



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 :
>> 
>>   
>> 
>> 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] pb with cxf / soap

[Mattias Jiderhamn]

I recently created a proof-of-concept service with CXF under Resin 4. 
Needed 12 jars/9,5 MB. Less than yours, but still a lot more than Axis 
1.4. I'm hoping there was something I had misunderstood...

For production we're sticking with Axis 1.4. Where we cannot use 
Hessian, that is ;-)



Riccardo Cohen wrote (2010-07-20 20:21):
> I still think that 29Mb/66jars is too much when you need only soap.
> Axis 2 is also very heavy, axis 1.4 is 2Mb only :) ... bad choice
> probably because too old.
>
>
>
> Daniel López wrote:
>
>> Hi there,
>>
>> Not sure if it helps, but I have an application that exposes a SOAP
>> interface using CXF 2.1.9 and I just tested it to work under Resin 3.1.5
>> and it fails under Resin 4.0.7 with a weird error.
>>
>> It's just a proof-of-concept application that I have, so I can't tell
>> how well the combination really works, but at least I know those
>> versions can work together.
>>
>> S!
>> D.
>>
>>
>> El 20/07/2010 8:29, Riccardo Cohen escribió:
>>  
>>> Thanks a lot Scott for your answer. This is the result:
>>>
>>>
 That looks like an error in the XML parser. You might try changing
 the javax.xml.stream.XMLInputFactory property to
 "com.sun.xml.internal.stream.XMLInputFactoryImpl".
  
>>> When I add
>>>
>>> >> javax.xml.stream.XMLInputFactory="com.sun.xml.internal.stream.XMLInputFactoryImpl"/>
>>>
>>>   in the conf of the webapp, the client seems to like it, and launches
>>> the request, but now the server has an err500 :
>>>
>>> javax.xml.stream.FactoryConfigurationError at
>>> javax.xml.stream.FactoryLoader.newClass(FactoryLoader.java:138) at
>>> javax.xml.stream.FactoryLoader.newInstance(FactoryLoader.java:76) at
>>> javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:157)
>>>
>>>
>>>
>> at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:143)
>>  
>>> at
>>> org.apache.cxf.staxutils.StaxUtils.createXMLInputFactory(StaxUtils.java:167)
>>>
>>>
>>>
>>>
 Also, you should avoid 3.2.x. Those are very old 4.0.x beta
 releases.
  
>>> I know but when I tried version 4.0.8 it claimed that it needs java
>>> 1.6 which is not available on my macosx leopard intel 32bits :) (I've
>>> just bought snow leopard and may move to 4 soon)
>>>
>>>
>>> Is there any other "very simple" way to do soap client/server with
>>> Resin ? (my customer needs soap, if not I would have used
>>> hessian...)
>>>
>>>
>>> Thanks
>>>
>>



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Remote deployment

[Mattias Jiderhamn]

After adding a commitmessage, which according to the Wiki is optional, 
I'm told I need to add a  tag.
When reading http://www.caucho.com/resin/admin/deploy.xtp carefully, the 
text says  but the example shows 

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 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 a   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
>> ), 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

Re: [Resin-interest] Remote deployment

[Mattias Jiderhamn]

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 a  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
> ), 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

[Mattias Jiderhamn]

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  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 
), 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

Re: [Resin-interest] Accessing resin-admin

[Mattias Jiderhamn]

Thanks, that worked.

I tried adding  (or ) also to add some 
IP filtering ( vs ) 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   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"?



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 the  configuration from the default.
> It looks like this:
>
>
>  
>
>
> 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...?
>>
>> -- 
>>
>> 
>>  



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] Accessing resin-admin

[Mattias Jiderhamn]

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...?

-- 

   



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] IllegalStateException at session load

[Mattias Jiderhamn]

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

[Mattias Jiderhamn]

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.



-- Scott
  

 

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?

 

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
  


 

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 :
  
  


We are seeing a lot of "Connection reset" with Hessian since the upgrade
of our production environment to 4.0.2 (both client and server). Would
this be related to the problems already reported against 4.0.2 and thus
fixed in the snapshot?

Caused by: com.caucho.hessian.io.HessianFieldException: 
se.exder.marketplace.api.MarketplaceAddressDTO.addressName: Connection reset
   at 
com.caucho.hessian.io.JavaDeserializer.logDeserializeError(JavaDeserializer.java:726)
   at 
com.caucho.hessian.io.JavaDeserializer$StringFieldDeserializer.deserialize(JavaDeserializer.java:639)
   at 
com.caucho.hessian.io.JavaDeserializer.readObject(JavaDeserializer.java:286)
   at 
com.caucho.hessian.io.JavaDeserializer.readObject(JavaDeserializer.java:178)
   at 
com.caucho.hessian.io.Hessian2Input.readObjectInstance(Hessian2Input.java:2110)
   at 
com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:2030)
   at 
com.caucho.hessian.io.CollectionDeserializer.readLengthList(CollectionDeserializer.java:93)
   at 
com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:1689)
   at com.caucho.hessian.io.Hessian2Input.readReply(Hessian2Input.java:351)
   at com.caucho.hessian.client.HessianProxy.invoke(HessianProxy.java:241)
   ... 39 more
Caused by: java.net.SocketException: Connection reset
   at java.net.SocketInputStream.read(SocketInputStream.java:168)
   at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
   at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
   at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
   at 
sun.net.www.http.ChunkedInputStream.readAheadBlocking(ChunkedInputStream.java:525)
   at 
sun.net.www.http.ChunkedInputStream.readAhead(ChunkedInputStream.java:582)
   at sun.net.www.http.ChunkedInputStream.read(ChunkedInputStream.java:669)
   at java.io.FilterInputStream.read(FilterInputStream.java:116)
   at 
sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2391)
   at 
com.caucho.hessian.io.Hessian2Input.readBuffer(Hessian2Input.java:2704)
   at com.caucho.hessian.io.Hessian2Input.read(Hessian2Input.java:2676)
   at 
com.caucho.hessian.io.Hessian2Input.parseUTF8Char(Hessian2Input.java:2501)
   at com.caucho.hessian.io.Hessian2Input.parseChar(Hessian2Input.java:2492)
   at 
com.caucho.hessian.io.Hessian2Input.readString(Hessian2Input.java:1328)
   at 
com.caucho.hessian.io.JavaDeserializer$StringFieldDeserializer.deserialize(JavaDeserializer.java:635)
   ... 47 more

--

 


  



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
  
  

--

  


__

Re: [Resin-interest] Lots of Connection reset

[Mattias Jiderhamn]

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 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?

 

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
  

 

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 :
  
  

We are seeing a lot of "Connection reset" with Hessian since the upgrade
of our production environment to 4.0.2 (both client and server). Would
this be related to the problems already reported against 4.0.2 and thus
fixed in the snapshot?

Caused by: com.caucho.hessian.io.HessianFieldException: 
se.exder.marketplace.api.MarketplaceAddressDTO.addressName: Connection reset
   at 
com.caucho.hessian.io.JavaDeserializer.logDeserializeError(JavaDeserializer.java:726)
   at 
com.caucho.hessian.io.JavaDeserializer$StringFieldDeserializer.deserialize(JavaDeserializer.java:639)
   at 
com.caucho.hessian.io.JavaDeserializer.readObject(JavaDeserializer.java:286)
   at 
com.caucho.hessian.io.JavaDeserializer.readObject(JavaDeserializer.java:178)
   at 
com.caucho.hessian.io.Hessian2Input.readObjectInstance(Hessian2Input.java:2110)
   at 
com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:2030)
   at 
com.caucho.hessian.io.CollectionDeserializer.readLengthList(CollectionDeserializer.java:93)
   at 
com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:1689)
   at com.caucho.hessian.io.Hessian2Input.readReply(Hessian2Input.java:351)
   at com.caucho.hessian.client.HessianProxy.invoke(HessianProxy.java:241)
   ... 39 more
Caused by: java.net.SocketException: Connection reset
   at java.net.SocketInputStream.read(SocketInputStream.java:168)
   at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
   at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
   at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
   at 
sun.net.www.http.ChunkedInputStream.readAheadBlocking(ChunkedInputStream.java:525)
   at 
sun.net.www.http.ChunkedInputStream.readAhead(ChunkedInputStream.java:582)
   at sun.net.www.http.ChunkedInputStream.read(ChunkedInputStream.java:669)
   at java.io.FilterInputStream.read(FilterInputStream.java:116)
   at 
sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2391)
   at 
com.caucho.hessian.io.Hessian2Input.readBuffer(Hessian2Input.java:2704)
   at com.caucho.hessian.io.Hessian2Input.read(Hessian2Input.java:2676)
   at 
com.caucho.hessian.io.Hessian2Input.parseUTF8Char(Hessian2Input.java:2501)
   at com.caucho.hessian.io.Hessian2Input.parseChar(Hessian2Input.java:2492)
   at 
com.caucho.hessian.io.Hessian2Input.readString(Hessian2Input.java:1328)
   at 
com.caucho.hessian.io.JavaDeserializer$StringFieldDeserializer.deserialize(JavaDeserializer.java:635)
   ... 47 more

--

 






___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
  



--

 

___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Lots of Connection reset

[Mattias Jiderhamn]

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?



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
  

 

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 :
  
  

We are seeing a lot of "Connection reset" with Hessian since the upgrade
of our production environment to 4.0.2 (both client and server). Would
this be related to the problems already reported against 4.0.2 and thus
fixed in the snapshot?

Caused by: com.caucho.hessian.io.HessianFieldException: 
se.exder.marketplace.api.MarketplaceAddressDTO.addressName: Connection reset
   at 
com.caucho.hessian.io.JavaDeserializer.logDeserializeError(JavaDeserializer.java:726)
   at 
com.caucho.hessian.io.JavaDeserializer$StringFieldDeserializer.deserialize(JavaDeserializer.java:639)
   at 
com.caucho.hessian.io.JavaDeserializer.readObject(JavaDeserializer.java:286)
   at 
com.caucho.hessian.io.JavaDeserializer.readObject(JavaDeserializer.java:178)
   at 
com.caucho.hessian.io.Hessian2Input.readObjectInstance(Hessian2Input.java:2110)
   at 
com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:2030)
   at 
com.caucho.hessian.io.CollectionDeserializer.readLengthList(CollectionDeserializer.java:93)
   at 
com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:1689)
   at com.caucho.hessian.io.Hessian2Input.readReply(Hessian2Input.java:351)
   at com.caucho.hessian.client.HessianProxy.invoke(HessianProxy.java:241)
   ... 39 more
Caused by: java.net.SocketException: Connection reset
   at java.net.SocketInputStream.read(SocketInputStream.java:168)
   at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
   at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
   at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
   at 
sun.net.www.http.ChunkedInputStream.readAheadBlocking(ChunkedInputStream.java:525)
   at 
sun.net.www.http.ChunkedInputStream.readAhead(ChunkedInputStream.java:582)
   at sun.net.www.http.ChunkedInputStream.read(ChunkedInputStream.java:669)
   at java.io.FilterInputStream.read(FilterInputStream.java:116)
   at 
sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2391)
   at 
com.caucho.hessian.io.Hessian2Input.readBuffer(Hessian2Input.java:2704)
   at com.caucho.hessian.io.Hessian2Input.read(Hessian2Input.java:2676)
   at 
com.caucho.hessian.io.Hessian2Input.parseUTF8Char(Hessian2Input.java:2501)
   at com.caucho.hessian.io.Hessian2Input.parseChar(Hessian2Input.java:2492)
   at 
com.caucho.hessian.io.Hessian2Input.readString(Hessian2Input.java:1328)
   at 
com.caucho.hessian.io.JavaDeserializer$StringFieldDeserializer.deserialize(JavaDeserializer.java:635)
   ... 47 more

--

 




___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Resin License Question

[Mattias Jiderhamn]

One theory is that it is the last date you may purchase a renewal, 
before you have to buy a new license?

 

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] Lots of Connection reset

[Mattias Jiderhamn]

Nope - standalone Resin.



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 :
  

We are seeing a lot of "Connection reset" with Hessian since the upgrade
of our production environment to 4.0.2 (both client and server). Would
this be related to the problems already reported against 4.0.2 and thus
fixed in the snapshot?

Caused by: com.caucho.hessian.io.HessianFieldException: 
se.exder.marketplace.api.MarketplaceAddressDTO.addressName: Connection reset
   at 
com.caucho.hessian.io.JavaDeserializer.logDeserializeError(JavaDeserializer.java:726)
   at 
com.caucho.hessian.io.JavaDeserializer$StringFieldDeserializer.deserialize(JavaDeserializer.java:639)
   at 
com.caucho.hessian.io.JavaDeserializer.readObject(JavaDeserializer.java:286)
   at 
com.caucho.hessian.io.JavaDeserializer.readObject(JavaDeserializer.java:178)
   at 
com.caucho.hessian.io.Hessian2Input.readObjectInstance(Hessian2Input.java:2110)
   at 
com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:2030)
   at 
com.caucho.hessian.io.CollectionDeserializer.readLengthList(CollectionDeserializer.java:93)
   at 
com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:1689)
   at com.caucho.hessian.io.Hessian2Input.readReply(Hessian2Input.java:351)
   at com.caucho.hessian.client.HessianProxy.invoke(HessianProxy.java:241)
   ... 39 more
Caused by: java.net.SocketException: Connection reset
   at java.net.SocketInputStream.read(SocketInputStream.java:168)
   at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
   at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
   at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
   at 
sun.net.www.http.ChunkedInputStream.readAheadBlocking(ChunkedInputStream.java:525)
   at 
sun.net.www.http.ChunkedInputStream.readAhead(ChunkedInputStream.java:582)
   at sun.net.www.http.ChunkedInputStream.read(ChunkedInputStream.java:669)
   at java.io.FilterInputStream.read(FilterInputStream.java:116)
   at 
sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2391)
   at 
com.caucho.hessian.io.Hessian2Input.readBuffer(Hessian2Input.java:2704)
   at com.caucho.hessian.io.Hessian2Input.read(Hessian2Input.java:2676)
   at 
com.caucho.hessian.io.Hessian2Input.parseUTF8Char(Hessian2Input.java:2501)
   at com.caucho.hessian.io.Hessian2Input.parseChar(Hessian2Input.java:2492)
   at 
com.caucho.hessian.io.Hessian2Input.readString(Hessian2Input.java:1328)
   at 
com.caucho.hessian.io.JavaDeserializer$StringFieldDeserializer.deserialize(JavaDeserializer.java:635)
   ... 47 more

--

 



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest





___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

  



--

 

___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] Lots of Connection reset

[Mattias Jiderhamn]

We are seeing a lot of "Connection reset" with Hessian since the upgrade 
of our production environment to 4.0.2 (both client and server). Would 
this be related to the problems already reported against 4.0.2 and thus 
fixed in the snapshot?

Caused by: com.caucho.hessian.io.HessianFieldException: 
se.exder.marketplace.api.MarketplaceAddressDTO.addressName: Connection reset
at 
com.caucho.hessian.io.JavaDeserializer.logDeserializeError(JavaDeserializer.java:726)
at 
com.caucho.hessian.io.JavaDeserializer$StringFieldDeserializer.deserialize(JavaDeserializer.java:639)
at 
com.caucho.hessian.io.JavaDeserializer.readObject(JavaDeserializer.java:286)
at 
com.caucho.hessian.io.JavaDeserializer.readObject(JavaDeserializer.java:178)
at 
com.caucho.hessian.io.Hessian2Input.readObjectInstance(Hessian2Input.java:2110)
at 
com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:2030)
at 
com.caucho.hessian.io.CollectionDeserializer.readLengthList(CollectionDeserializer.java:93)
at 
com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:1689)
at com.caucho.hessian.io.Hessian2Input.readReply(Hessian2Input.java:351)
at com.caucho.hessian.client.HessianProxy.invoke(HessianProxy.java:241)
... 39 more
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:168)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
at 
sun.net.www.http.ChunkedInputStream.readAheadBlocking(ChunkedInputStream.java:525)
at 
sun.net.www.http.ChunkedInputStream.readAhead(ChunkedInputStream.java:582)
at sun.net.www.http.ChunkedInputStream.read(ChunkedInputStream.java:669)
at java.io.FilterInputStream.read(FilterInputStream.java:116)
at 
sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2391)
at 
com.caucho.hessian.io.Hessian2Input.readBuffer(Hessian2Input.java:2704)
at com.caucho.hessian.io.Hessian2Input.read(Hessian2Input.java:2676)
at 
com.caucho.hessian.io.Hessian2Input.parseUTF8Char(Hessian2Input.java:2501)
at 
com.caucho.hessian.io.Hessian2Input.parseChar(Hessian2Input.java:2492)
at 
com.caucho.hessian.io.Hessian2Input.readString(Hessian2Input.java:1328)
at 
com.caucho.hessian.io.JavaDeserializer$StringFieldDeserializer.deserialize(JavaDeserializer.java:635)
... 47 more

-- 

  



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Potential class loader leaks

[Mattias Jiderhamn]

Scott, can you tell me whether you've been able to reproduce this scenario?



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?


--

  


___
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]

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.




--

 

___
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]

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?


--

 

___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] Potential class loader leaks

[Mattias Jiderhamn]

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?

-- 

  



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] Note about max-uri-length

[Mattias Jiderhamn]

Now that the Resin Change Log is up and running again I notice this item
> resin: max-uri-length configuration tag introduced to set limit on 
> URIs served by Resin. Default is 1024.
I think it should be noted that this applies to the path component of 
the URI, not the entire URI (as defined in RFC 3986) including query string.

-- 

  



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] 4.0.2 schedule

[Mattias Jiderhamn]

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:


 
  ...
   java



 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)?


 

Wesley Wu wrote (2009-10-13 23:07):
Yes, I turned on  (simply copied from my 
previous 4.0.0 conf file).


When I turned it off (commented them out)
  
@SessionScope worked fine.

Thanks.

-Wesley

2009/10/14 Scott Ferguson 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  enabled?  The sample
resin.xml does enable it, but you might want to change that if
you don't want persistent store.





Thanks Scott. Magnificent work!


thanks!

-- Scott


-Wesley






___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
  



--

 

___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Hibernate lazy loading with Quercus

[Mattias Jiderhamn]

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".





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

[Mattias Jiderhamn]

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] 4.0.2 schedule

[Mattias Jiderhamn]

This reminds me; what is the syntax for enabling Java serialization for
persistent store (as of http://bugs.caucho.com/view.php?id=3648)?

 

Wesley Wu wrote (2009-10-13 23:07):
> Yes, I turned on  (simply copied from my
> previous 4.0.0 conf file).
>
> When I turned it off (commented them out)
>   
> @SessionScope worked fine.
>
> Thanks.
>
> -Wesley
>
> 2009/10/14 Scott Ferguson 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  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

Re: [Resin-interest] NoSuchMethodError

[Mattias Jiderhamn]

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.

 

- 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"

[Mattias Jiderhamn]

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)

-- 

  



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest