Re: [Resin-interest] header append

[Scott Ferguson]

On Sep 19, 2008, at 7:27 AM, Sean Moore wrote:

>
> I was struck by the same attack as mentioned below using Resin 3.0.26
>
> http://maillist.caucho.com/pipermail/resin-interest/2008-September/002941.html
>
> I was not as smart as Jens to figure it out but everything ran great
> with just Resin so I removed Apache.  I feel better knowing what had
> happened but I think I will be stick with just Resin.
>
> Now I need to add back some of the items I had Apache doing.
>
> In Apache I had a the below line -
>
> Header append P3P 'CP="DSP ALL CUR OUR PUBi BUS NAV COM STA INT PHY  
> DEM UNI ONL"'
>
> I have searched but have not found a configuration for this?

Right now, you'd need to write a simple filter for this case.  I've  
added a bug report at http://bugs.caucho.com/view.php?id=2953 so we  
can add a predefined filter.

-- Scott

>
>
> Thanks,
> HomeGauge.com
>
>
> ___
> 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] configuring webdav

[Scott Ferguson]

On Sep 23, 2008, at 7:23 AM, Gary Lawrence Murphy wrote:

>
> I am attempting to enable webdav for a test and I'm wondering if there
> might be a step missing from the how-to page at
> http://www.caucho.com/resin-3.0/servlet/webdav.xtp

I've filed a bug report for this at http://bugs.caucho.com/view.php?id=2966

It's been awhile since we've worked on the webdav servlet, so I'm not  
exactlu sure what the issue is.

-- Scott

>
>
> For this test I am using the open non-secure settings (just to KISS).
> I have copied the given servlet config section into conf/resin.xml
>
> 
>  webdav
>  com.caucho.servlets.webdav.WebDavServlet class>
>  
>write
>WEB-INF/webdav
>false
>*
>  
> 
>
> 
>
> and I see
>
> ==> /opt/resin/logs/msg.log <==
> [09:44:39.308] webdav: init
>
> but when I use a browser to access localhost:8080/webdav I get
> a 404 Not-Found error.
>
> on the chance it needed the root pre-created, I created the
> webapps/WEB-INF/webdav directory, but I still get that error.
>
> what did I miss?
>
>
> -- 
> Gary Lawrence Murphy   
> =
> Alice laughed: "There's no use trying, one can't believe impossible  
> things."
> "I daresay you haven't had much practice," said the Queen.
>
>
> ___
> 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] Question about SessionImpl Logging

[Scott Ferguson]

On Sep 24, 2008, at 5:59 PM, Eric Kreiser wrote:

Can anyone explain what this log message is trying to tell me?  What  
triggers it?  What should I do about it?


[18 
: 
27 
: 
08.120 
]SessionImpl 
[abc0hfqSDgdsj_2WqEwYre3iHzZMfZbhNvCZQDk2EV9KGsC_EhF0McW2rasVM4rD8- 
tAVy0Kdup71uwvB1Keuf-iTx0UWUKA_aEI,] LRU while in use (use- 
count=1).  Consider increasing session-count.


It's a timing issue.  The sessions are held in a LRU cache.  When too  
many sessions are being used, Resin drops the least used session.  If  
that dropping happens at the same time as a session is being used  
(like a very long request), you'll get that warning message.


Typically, that would indicate that LRU is too small.

-- Scott





--

Eric S. Kreiser
Senior Software Architect

Mzinga
5095 Ritter Road • Mechanicsburg, PA  17055
---
Call my office: 717.458.9804
Fax me: 717.790.0401
Email me: [EMAIL PROTECTED]
Learn more: http://mzinga.com/v/ekreiser/
Toll Free: 800.869.5763

___
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] Velocity rendering dies

[Scott Ferguson]

On Sep 25, 2008, at 10:12 PM, tweihs wrote:

>
> Folks,
>
> I've apparently found a way to kill the Velocity parsing in resin  
> 3.1.3 and
> 3.1.4 (pro).  We use velocity style syntax extensively throughout  
> the our
> site and this hurdle is baffling me.  I can confirm via a simple
> "velocityEnabled.jsp" that if I comment out most of our app's  
> web.xml and
> leave in the  tag, I can print  
> variables out
> with velocity syntax.  If I uncomment the remaining tags in web.xml  
> (I'll
> refer to this as "web.xml.dev"), velocity dies.

Can you check this on 3.2.0?  We did disable velocity on some of the  
earlier 3.1 releases (due to internal refactoring of JSP parsing.)

-- Scott

>
>
> I downloaded our web.xml (I'll refer to this as "web.xml.prod" )  
> file from
> production and velocity works again.  Thus, there is something being  
> loaded
> (a resource, jms queue, resin db, one of our classes) via the web.xml.dev
> that neuters velocity.  I'm trying to comment blocks out to see what
> resource is the offender, but due to the size of our web.xml file,  
> this will
> take a bit more toggling to get to the source.  I'll continue doing  
> that to
> isolate, but curious if there is anything that could end up  
> disabling the
> velocity rendering.  The *parsing* works - that is, the pages get  
> compiled.
> It's just that blocks like ${foo} don't get rendered.  Things that  
> come to
> mind:
>
> * something with logging?  I noticed some errors about Log4J not  
> being able
> to write to a directory due to perms, and curious if logging somehow  
> dies,
> does velocity rendering die?
> * jar file issues?  I've noticed including or excluding some jars,  
> like
> struts (and jakarta commons logging and log4j), can also neuter the
> rendering.  This would seem less likely to be the culprit in this  
> case,
> because downloading web.xml.prod and running with that re-enables  
> velocity.
>
> Thanks in advance,
>
> -tyson
> -- 
> View this message in context: 
> http://www.nabble.com/Velocity-rendering-dies-tp19682616p19682616.html
> Sent from the Resin mailing list archive at Nabble.com.
>
>
>
> ___
> 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] configuring webdav

[Scott Ferguson]

On Sep 25, 2008, at 1:19 PM, Knut Forkalsrud wrote:

> On Sep 23, 2008, at 7:23 AM, Gary Lawrence Murphy wrote:
>
> > 
> ...
> > but when I use a browser to access localhost:8080/webdav I get
> > a 404 Not-Found error.
> ...
> > what did I miss?
>
>
> It could be as simple as adding a trailing slash in your URL, after  
> all there is an explicit slash in the servlet mapping.
>
> -Knut
>
> PS: It would be nice if Resin's WebDAV servlet implemented the LOCK  
> operation such that MacOSX would mount a WebDAV server as a read/ 
> write file system.

Right.  That's the main open issue with Resin's WebDAV.

-- 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] java.lang.IllegalStateException: block at ffffffffc0000000 is invalid for file

[Scott Ferguson]

On Oct 1, 2008, at 11:46 PM, Tuan Tran wrote:

> Hi all,
>
> After some hours of running Resin i get this exception,
>
> [nnection.java:389)
> [01:29:02.987]  at
> com.caucho.util.ThreadPool.runTasks(ThreadPool.java:507)
> [01:29:02.987]  at com.caucho.util.ThreadPool.run(ThreadPool.java:433)
> [01:29:02.987]  at java.lang.Thread.run(Thread.java:595)
>
> This exception keeps going, after a while i get a nasty java heap  
> space
> out of memory. We are running Resin version 3.0.19. Is there a way to
> fix this?

You either need to upgrade to a 3.1.x version or switch to the jdbc  
store for sessions.  3.1.x fixed a large number of issues with our  
session backing store.

-- Scott

>
>
> Best regards,
>
> Tuan.
>
>
>
> ___
> 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] Leak with 3.0.23 load balancing

[Scott Ferguson]

On Oct 2, 2008, at 2:30 PM, Tom Hintz wrote:

> Thread count climbed steadily from a beginning of 70 to 300+ to  
> finally
> 500+ when heap was exhausted.

That's interesting.  It would explain the memory error.  If it's  
possible, a thread dump would really help.

Also, the 1M setting would help.   
Its main purpose is to prevent the JVM from continually spinning when  
memory is almost exhausted.  In that situation, a forced restart is  
better.

One issue, though, is that 3.0 is frozen, so other than configuration  
tweaks, any Resin code changes would be in 3.1 or 3.2.

-- Scott

>
>
> Tom
>
>
> ___
> 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] Minimum memory for resin?

[Scott Ferguson]

On Oct 2, 2008, at 1:01 PM, Heimo Laukkanen wrote:

> Hi,
>
> I was just looking for very cheap vps-servers for a private project
> and thought about what are reasonable minimum memory requirements for
> Resin?
>
> http://www.vanager.com/virtualrootserver/
>
> For example is it reasonable to think to run Resin with just 64 or  
> 128 megs?

You might look at Resin 3.2.1 with the -Dcaucho.smallmem option, which  
shrinks the normal buffer sizes for small memory environments.  With  
that setting (and minimal thread-max), 64m should be doable.

-- Scott


>
>
> -huima
>
>
> ___
> 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] Trying to use cxf scheme for remote-client fails

[Scott Ferguson]

On Oct 2, 2008, at 10:01 AM, Sashidhar Guduri wrote:

I got no replies on this question I sent a few days ago. http://wiki.caucho.com/CXF 
 claims one can configure a remote client with cxf. This does NOT  
work in resin 3.1.7. Anybody got this to work?


In 3.1, the classes are in ext-webapp-lib as resin-support.jar.  The  
support for third-party frameworks is outside of the standard resin.jar.


-- Scott



Thanks
Sashi

On Fri, Sep 26, 2008 at 2:16 PM, Sashidhar Guduri <[EMAIL PROTECTED]>  
wrote:
I am trying to create a remote-client with cxf and having trouble  
doing so. Here is the error I am getting:


com.caucho.config.types.BeanConfig.setUri(): 'cxf' is an unknown  
scheme for driver 'com.caucho.remote.client.ProtocolProxyFactory'.   
The available schemes are '[burlap, hessian]'


Resin documentation says it supports cxf. Is there something special  
I need to do to make cxf scheme available to resin?


Thanks
Sashi
--
Sashidhar Guduri, App Analyst Lead
UM Medical School Information Services

___
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] Obtaining a PGConnection object

[Scott Ferguson]

On Oct 1, 2008, at 8:47 PM, Claire McLister wrote:

> Hi,
>
>  We have an application running on Tomcat and are evaluating
> migration to Resin.
>
>  One of the current sticking points is the use of Postgresql Large
> Objects. In the Tomcat configuration, we could use the
> 'allowAccesstoUnderlyingConnection' property to access the
> PGConnection object and use the large object API from there.

You can either use Resin's getConnection() method or the unwrap method,

Connection conn = _database.getConnection();

PGConnection pgConn = conn.unwrap(PGConnection.class);

or

PGConnection pgConn = (PGConnection) ((com.caucho.sql.UserConnection)  
conn).getConnection();

-- Scott

> It seems Resin supports the retrieval of the Connection object from
> the Datasource, but trying to cast it into a PGConnection gives an
> exception.


>
>
>  Can someone please tell us how we can use Large Object API from
> within the Resin container.
>
>  Thanks for any pointers.
>
> Claire
>
>
>
> ___
> 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 3.0 thread leak

[Scott Ferguson]

On Oct 2, 2008, at 5:32 PM, Tom Hintz wrote:

> Out of curiosity, is it safe to set the thread stack size to 1k on the
> load balance resin?

That's almost certainly too low.  256k is probably the minimum you  
could get away with.  That parameter is virtual memory, so it's only  
actually takes up memory if it's used (on 32-bit systems, though, the  
virtual allocation itself is important.)

-- Scott

>
>
> T
>>>
>
>
> ___
> 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] Leak with 3.0.23 load balancing

[Scott Ferguson]

On Oct 3, 2008, at 7:03 AM, Tom Hintz wrote:

> 477 of those threads had this stack:
>
> 0xff2c5870  _read + 0x8
> 0xe91db008  sock_read + 0x24
> 0xe91d8edc  BIO_read + 0xcc
> 0xeaa49154  ssl3_read_n + 0x154
> 0xeaa492d0  ssl3_get_record + 0xe0
> 0xeaa49e78  ssl3_read_bytes + 0x1fc
> 0xeaa48dcc  ssl3_read_internal + 0x44
> 0xeacb22a4  ssl_read + 0xa8
> 0xeb1e25d8  Java_com_caucho_vfs_JniStream_readNative + 0x54

Hmm.  Looks like the socket timeout isn't happening for some reason.   
I've filed a bug as http://bugs.caucho.com/view.php?id=2988

-- Scott

>
>
> Tom
>
> -Original Message-
> Subject: RE: Leak with 3.0.23 load balancing
>
> Thread count climbed steadily from a beginning of 70 to 300+ to  
> finally
> 500+ when heap was exhausted.
>
> Tom
>
>
> ___
> 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 3.1.6 startup options, no -pid ?

[Scott Ferguson]

On Oct 6, 2008, at 12:49 PM, Rachel McConnell wrote:

> I'm upgrading from resin 3.1.1 to 3.1.6 which is, I believe, the
> current stable version.  I tried my existing startup script and got
> this error:
>
> [EMAIL PROTECTED] local]# /etc/init.d/resin start
> unknown argument '-pid'
>
> usage: java -jar resin.jar [-options] [status | start | stop | restart
> | kill | shutdown]
>
> where options include:
>   -conf   : select a configuration file
>   -log-directory   : select a logging directory
>   -resin-home  : select a resin home directory
>   -root-directory  : select a root directory
>   -server   : select a  to run
>   -watchdog-port  : override the watchdog-port
>   -verbose  : print verbose starting information
>
> The relevant bit of the startup script is:
>
> su $USER -c "$HTTPD start -verbose -J-server -J-Xms1024m -J-Xmx1024m \
> -Djava.awt.headless=true -pid $PID -jvm-log $JVMLOG \
> -stdout $STDOUT -stderr $STDERR $*
>
> where the $VARIABLES have reasonable values.
>
> I checked the resin docs and the wiki but could not find any
> information on the -pid option.  I'd like to retain it as the stop
> script uses it as a backup shutdown method.  Can anyone point me to
> documentation on this?

The -pid doesn't exist in 3.1.x because of the switch to the watchdog  
mechanism.  The watchdog keeps track of the pids internally.

-- Scott

>
>
> Thanks,
> Rachel
>
>
> ___
> 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 global classpath with webapp classpath

[Scott Ferguson]

On Oct 8, 2008, at 11:33 AM, Jason Deffenbaugh wrote:

>  successfully loaded the classpath in the reverse order.

You really don't want to use .  It breaks the whole Java  
classloader architecture.

-- Scott

>
> Thanks!
>
> -Jason
>
> On Wed, 2008-10-08 at 19:44 +0200, BUSCH Steffen wrote:
>> I think you're looking for the 
>> http://caucho.com/resin/doc/env-tags.xtp#servlet-hack
>> which should not be used in general! I would prefer any other  
>> solution, such as duplicating your 'common' but older oracle driver  
>> jar into the WEB-INF/lib of the other web-apps ...
>>
>>
>> -Ursprüngliche Nachricht-
>> Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
>> ] Im Auftrag von Jason Deffenbaugh
>> Gesendet: Mittwoch, 8. Oktober 2008 19:20
>> An: resin-interest@caucho.com
>> Betreff: [Resin-interest] override global classpath with webapp  
>> classpath
>>
>> We're configuring resin to connect to a db using an oracle db driver.
>> The driver jar is in ${server.root}/lib.  The problem is that for  
>> one webapp I need to change the version of the oracle driver so I  
>> put the new driver jar in WEB-INF/lib in the webapp.  Resin appears  
>> to be ignoring the local version of the driver class in favor of  
>> the global one.
>>
>> Is there a way to configure resin to load the webapp local  
>> classpath first instead of the global one?
>>
>> Thanks,
>>
>> -Jason
>>
>>
>>
>> ___
>> 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] 'tlibversion' is an unknown property of'com.caucho.jsp.cfg.TldTaglib'

[Scott Ferguson]

On Oct 10, 2008, at 11:12 AM, Miguel Vargas wrote:


I just saw found a similar bug fixed in 3.1.7, 
http://bugs.caucho.com/bug_view_advanced_page.php?bug_id=2672

Is this my bug?


Yes, that should be the same issue.  There was a change in how we were  
handling capitalization for Resin's IoC that messed up some .tld files.


-- Scott



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
] On Behalf Of Miguel Vargas

Sent: Friday, October 10, 2008 11:02 AM
To: resin-interest@caucho.com
Subject: [Resin-interest] 'tlibversion' is an unknown property  
of'com.caucho.jsp.cfg.TldTaglib'


We recently updgraded from Resin 3.0.23 to 3.1.6.  We use Struts  
1.2.8.  We are currently getting the following exception,


"Unhandled exception 'jar:file:/usr/local/web0/webapps/cons/WEB-INF/ 
lib/struts-1.2.8.jar!/META-INF/tlds/struts-logic.tld:10:  
'tlibversion' is an unknown property of  
'com.caucho.jsp.cfg.TldTaglib'.


Here’s the top of struts-logic.tld:
Library 1.1//EN" "http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd 
">


1.2
1.1
logic

I know the JSP 1.2 DTD changed the tag to  instead of  
.  Does Resin 3.1.6 not compatible with JSP 1.1?


Another possibility I’ve considered is the case-sensitivity of the  
getters.  The getter in com.caucho.jsp.cfg.TldTaglib is  
getTlibVersion(), should it be getTlibversion() instead?  When we  
upgraded to 3.1.6 we had to change a bunch of our JSP to match the  
case of the property getters.


This electronic message contains information from Multifamily  
Technology Solutions, Inc. (MyNewPlace.com) and is confidential or  
privileged. The information is intended to be for the use of the  
individual or entity named above. If you are not the intended  
recipient, be aware that any disclosure, copying, distribution or  
use of the contents of this message is prohibited. If you have  
received this electronic message in error, please notify us  
immediately by telephone at (415) 348-2000 or electronic mail.


This electronic message contains information from Multifamily  
Technology Solutions, Inc. (MyNewPlace.com) and is confidential or  
privileged. The information is intended to be for the use of the  
individual or entity named above. If you are not the intended  
recipient, be aware that any disclosure, copying, distribution or  
use of the contents of this message is prohibited. If you have  
received this electronic message in error, please notify us  
immediately by telephone at (415) 348-2000 or electronic mail.  
___

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 0002988]: OpenSSL timeout

[Scott Ferguson]

On Oct 14, 2008, at 9:56 PM, Matt Pangaro wrote:

> Since it's not marked on the bug in Mantis, and I can't remember, was
> this issue found in the 3.0.x tree? If so, does it affect all  
> versions?

It affects all versions.  I've just made changes to all the trees.

-- Scott

>
>
> Thanks,
> Matt
>
> [EMAIL PROTECTED] wrote:
>> The following issue has been CLOSED
>> = 
>> =
>> http://bugs.caucho.com/view.php?id=2988
>> = 
>> =
>> Reported By:ferg
>> Assigned To:ferg
>> = 
>> =
>> Project:Resin
>> Issue ID:   2988
>> Category:
>> Reproducibility:always
>> Severity:   minor
>> Priority:   normal
>> Status: closed
>> Resolution: fixed
>> Fixed in Version:   3.2.1
>> = 
>> =
>> Date Submitted: 10-03-2008 09:34 PDT
>> Last Modified:  10-13-2008 10:31 PDT
>> = 
>> =
>> Summary:OpenSSL timeout
>> Description:
>> (rep by Tom Hintz)
>
>
>
> ___
> 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] Amber & SessionListeners

[Scott Ferguson]

On Oct 15, 2008, at 3:49 AM, Jan Kriesten wrote:

>
> Hi,
>
> is it possible to register SessionListeners with Amber to e.g. embed  
> Compass
> (http://www.compass-project.org/) with it?
>
> I haven't found any API for Amber.

I'm not sure what would be required.  You can use @In or  
@PersistenceContext in a SessionListener to get an EntityManager or  
EntityManagerFactory.

-- Scott

>
>
> Best regards, --- Jan.
>
>
> ___
> 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] j2ee class not available in 3.2.0

[Scott Ferguson]

On Oct 15, 2008, at 8:23 AM, Copeland, Artie wrote:

Why are some of the j2ee standard classes not available in 3.2.0  
that were available in 3.1.6?  As an example j2ee-management-10.jar  
all the classes in the javax.management.* packages are no longer  
available in the javaee-1.6.jar.  Are there any plans to put them  
back in?


JavaEE is splitting out the web profile from the enterprise profile  
for version 1.6, so the classes we'll be distributing would only be  
the web profile classes (plus any individual specifications we  
implement.)  Since javax.management is not part of the web profile  
(for the current draft specification, we've removed them from the  
distribution.)


-- Scott



iovation
111 SW Fifth Avenue
Suite 3200
Portland, OR 97204
www.iovation.com

The information contained in this email message may be privileged,  
confidential and protected from disclosure. If you are not the  
intended recipient, any dissemination, distribution or copying is  
strictly prohibited. If you think that you have received this email  
message in error, please notify the sender by reply email and delete  
the message and any attachments.

___
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] Amber, EntityManagerFactory & JNDI-Lookup

[Scott Ferguson]

On Oct 15, 2008, at 10:13 AM, Jan Kriesten wrote:

>
> Hi,
>
> I'm currently a bit puzzled since I don't get to work what yesterday  
> has already.
>
> As I understand it should be possible to lookup an  
> EntityManagerFactory via JNDI as
>
> java:comp/env/persistence/PersistenceUnit/xxx

The official JavaEE JNDI system is really weird.  (I believe it's  
getting changed for JavaEE 6, but that spec is still in early draft.)

Technically, the persistence.xml scanning does not automatically  
populate JNDI with the EntityManager.  It populates an app-server  
dependent space (in Resin it's WebBeans) that's available for  
injection using @PersistenceUnit and @PersistenceContext.

If you have a @PersistenceUnit or @PersistenceContext (or  or  in your web.xml), those declarations  
populate the JNDI space with their JNDI name.  So you're technically  
missing a JNDI linking step.

Personally, I'd stick with the injection annotations when possible and  
avoid JNDI, since JNDI is really a previous-technology solution.

-- Scott

>
>
> - but I just can't get that to work.
>
> My persistence.xml has
>
>  
>de.footprint.domreg.persistence.entities.Rezept
>de.footprint.domreg.persistence.entities.Zutat
>
>  
>
> in it. resin-web.xml contains:
>
>  
>jdbc/DomainRegistryServiceDS
>  
>
> The data-source is defined as well, so everything should be fine.
>
> But starting the application gives me:
>
> [18:56:46.431] Compiling
> de/footprint/domreg/persistence/entities/Rezept__ResinExt.java
> [18:56:46.431] Compiling
> de/footprint/domreg/persistence/entities/Zutat__ResinExt.java
> [18:56:47.819] Note:
> /usr/local/www/services/domreg/html/WEB-INF/work/pre-enhance/de/ 
> footprint/domreg/persistence/entities/Rezept__R
> esinExt.java uses unchecked or unsafe operations.
> [18:56:47.819] Note: Recompile with -Xlint:unchecked for details.
> [18:56:47.860] Amber enhancing class  
> de.footprint.domreg.persistence.entities.Rezept
> [18:56:47.922] Compiling
> de/footprint/domreg/persistence/entities/Rezept__ResinExt.java
> [18:56:48.567] Note:
> /usr/local/www/services/domreg/html/WEB-INF/work/pre-enhance/de/ 
> footprint/domreg/persistence/entities/Rezept__R
> esinExt.java uses unchecked or unsafe operations.
> [18:56:48.567] Note: Recompile with -Xlint:unchecked for details.
> [18:56:48.697] Amber enhancing class  
> de.footprint.domreg.persistence.entities.Zutat
> [18:56:48.730] Compiling
> de/footprint/domreg/persistence/entities/Zutat__ResinExt.java
> 18:56:50.438 INFO  [reg.web.application.DomainRegistryApplication] -  
> Application
> init...
> 18:56:50.542 INFO  [application.DomainRegistryApplication$$anon$1] -  
> Configuring
> application bindings...
> javax.naming.NameNotFoundException:
> java:comp/env/persistence/PersistenceUnit/DomainRegistryService
> Manual EMF
>
> Which means that looking up the PersistenceUnit doesn't work. I can  
> manually
> create the EntityManagerFactory with
>
> Persistence.createEntityManagerFactory( "DomainRegistryService" )
>
> though. Queries are running with the manual setup (only lazy fetches  
> aren't
> resolved this way!).
>
> I'm running resin 3.1.7 pro.
>
> Can someone give me a hint what I'm doing wrong?! Also - when I  
> change the
> persistence-provider to eclipselink, will Amber put then the created
> EntityManagerFactory also into the JNDI context?
>
> Thanks in advance!
>
> Best regards, --- Jan.
>
>
>
>
> ___
> 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/Quercus with PHP/Wordpress

[Scott Ferguson]

On Oct 16, 2008, at 10:15 AM, Jason Deffenbaugh wrote:

> I ran into a problem in Resin Pro 3.1.2 where the forward tag in
>
> 
>
> has a bug and doesn't work.  I believe this was fixed in 3.1.6.

For Quercus, it's a good idea to keep up with recent versions of  
Resin.  Each release includes a large number of Quercus bug fixes.   
The number of details and corner cases in PHP is amazingly high.

-- Scott


>
>
> -Jason
>
> On Thu, 2008-10-16 at 13:05 -0400, Dan Spilka wrote:
>> Hello all,
>>
>> If there is anyone with experience in configuring resin/quercus to  
>> run
>> Wordpress, would you mind contacting me? I'm specifically working  
>> with
>> WordPress MU and previously had it running successfully with Apache.
>>
>> I've setup a virtual host and can get the initial index page to load,
>> but all links from that page produce 404s. I'm guessing there is a  
>> url
>> rewriting issue perhaps? I've been trying to follow this page
>> (http://wiki.caucho.com/Quercus:_Wordpress_Mu) and various other  
>> pages
>> online.
>>
>> At the moment, I'm using Wordpress MU 1.2.1 and Resin Pro 3.1.2. I'm
>> going to try to upgrade to Resin Pro 3.2 as the url rewriting section
>> from the wiki url above doesn't seem to be working.
>>
>> Thanks,
>> -Dan
>>
>>
>> ___
>> 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] Looking for build-common.xml

[Scott Ferguson]

On Oct 17, 2008, at 2:48 PM, Smith, Russ wrote:

Basically have downloaded resin-3.2.0-src.zip and loaded it into  
Eclipse for build.


Have build.xml from zip but can't find subject xml file in this src  
distribution nor in previous distribution.


Pretty extensive search of site and archives failed to reveal  
availability of subject file.




Thanks.  We split build.xml into two pieces, but didn't add the build- 
common.xml to the distribution.  It'll be changed in 3.2.1.


-- Scott


Download location would be much appreciated.


Email Confidentiality Notice: The information contained in this  
transmission is confidential, proprietary or privileged and may be  
subject to protection under the law, including the Health Insurance  
Portability and Accountability Act (HIPAA). The message is intended  
for the sole use of the individual or entity to whom it is  
addressed. If you are not the intended recipient, you are notified  
that any use, distribution or copying of the message is strictly  
prohibited and may subject you to criminal or civil penalties. If  
you received this transmission in error, please contact the sender  
immediately by replying to this email and delete the material from  
any computer. ___

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


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

[Resin-interest] Resin 3.2.1 release notes

[Scott Ferguson]

More complete notes are at http://caucho.com/resin/changes/resin-3.2.1.xtp 
  and the changelog is at http://caucho.com/resin/changes/changes.xtp.

Resin 3.2.1 is the development branch and is subject to large changes  
for each revision, including a fairly high probability of introduced  
bugs.   The Resin 3.2.x branch is the working branch for the upcoming  
JavaEE 6 specifications.  Since those specifications are still in the  
early draft stage, even the APIs may change from revision to  
revision.  Most deployments needing more stability will want to use  
the Resin 3.1.x branch.

Resin 3.2.1 had three major changes: Quercus fixed a large number of  
accumulated bugs, the Hessian 2.0 draft and implementation had a major  
bytecode revision, and OSGi has been introduced as a mechanism for  
managing jars, libraries, and services.

1) Security - two potential security issues fixed in 3.2.1:
   *) a potential denial-of-service issue with mod_caucho and virtual  
hosts (main symptom is a very large /tmp/localhost_6800 file)
   *) a potential XSS issue with Resin's 404 involving UTF-7.

   We're also working on a 3.0 release for early next week including  
those fixes.

2) Quercus.
   *) We've added Moodle to our focus applications (Mediawiki,  
Wordpress and Drupal).  Moodle is an academic courseware framework  
that has become very popular.
   *) Many, many bug fixes.

3) Hessian 2.0
   *) We're revising the Hessian 2.0 draft so we can finally submit it  
to the IETF.  The changes in the bytecode allocation are not  
compatible for earlier versions of the Hessian 2.0 draft, so you will  
need to update both clients and servers for Hessian 2.0.

4) OSGi support
   *) We're treating OSGi as a versioning manager for Resin's class  
loaders and jars, and as a service manager.  Each web-app has its own  
OSGi manager serving jars and services.  We'll be writing more details  
on how this works in the next few weeks.





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

Re: [Resin-interest] inode block/fragment mixup???

[Scott Ferguson]

On Oct 22, 2008, at 12:06 PM, Mattias Jiderhamn wrote:

> We have a strange problem with Resin that looks like a bug but might  
> be
> some configuration issue.
>
> We hit the bug while storing more than the usual amount of data in a
> session (during a process that takes quite a lot of time).
> If we narrow things down so we store the same kind of data, although  
> not
> as much (and not using so much time), the error does not come about.
> The symptoms are that the slow request seems to finish correcly and  
> the
> data is returned to the browser, however on the next request the  
> session
> does no longer exist. Other sessions does not seem to be affected.  
> There
> are errors in the log file which makes me believe the session is lost
> during serializing/deserializing.
>
> With the same input data, the error is always reproducible.

Do you know how large the session is?  Also, does "finer" show  
anything interesting?

There may be a limit at 64M of session data, but I doubt you're  
hitting that.  It's possible there's an off-by-one issue at one of the  
boundaries (since the data is split into fragments).  Does adding 1 to  
the session length still produce the same error?

-- Scott

>
>
> Further below is some detailed information.
>
> My questions are:
> - Is there a limit to the amount of data Resin can keep in a  
> session? Is
> there a setting we should just increase?
> - Or is this a bug? Is there any workaround for now?
>
> Resin version: 3.1.6 Pro
>
> Session config:
>
>  
>  4096
>  30
>
>
>
> Related errors or flavors of the same error:
>
> [18:41:24.000] java.lang.IllegalStateException: block/fragment mixup
> [18:41:24.000]  at  
> com.caucho.db.store.Inode.writeBlockAddr(Inode.java:1078)
> [18:41:24.000]  at com.caucho.db.store.Inode.appendBlock(Inode.java: 
> 492)
> [18:41:24.000]  at com.caucho.db.store.Inode.append(Inode.java:388)
> [18:41:24.000]  at
> com 
> .caucho.db.store.BlobOutputStream.flushBlock(BlobOutputStream.java: 
> 188)
> [18:41:24.000]  at
> com.caucho.db.store.BlobOutputStream.write(BlobOutputStream.java:117)
> [18:41:24.000]  at
> com.caucho.db.table.BlobColumn.setStream(BlobColumn.java:179)
> [18:41:24.000]  at  
> com.caucho.db.table.BlobColumn.set(BlobColumn.java:267)
> [18:41:24.000]  at
> com.caucho.db.sql.UpdateQuery.execute(UpdateQuery.java:110)
> [18:41:24.000]  at
> com 
> .caucho 
> .db.jdbc.PreparedStatementImpl.execute(PreparedStatementImpl.java:345)
> [18:41:24.000]  at
> com 
> .caucho 
> .db 
> .jdbc.PreparedStatementImpl.executeUpdate(PreparedStatementImpl.java: 
> 313)
> [18:41:24.000]  at
> com 
> .caucho.server.cluster.FileBacking.storeSelfUpdate(FileBacking.java: 
> 524)
> [18:41:24.000]  at
> com.caucho.server.cluster.FileBacking.storeSelf(FileBacking.java:474)
> [18:41:24.000]  at
> com.caucho.server.cluster.FileStore.store(FileStore.java:169)
> [18:41:24.000]  at
> com.caucho.server.cluster.ClusterObject.store(ClusterObject.java:414)
> [18:41:24.000]  at
> com.caucho.server.session.SessionImpl.save(SessionImpl.java:960)
> [18:41:24.000]  at
> com 
> .caucho.server.session.SessionImpl.saveAfterRequest(SessionImpl.java: 
> 946)
> [18:41:24.000]  at
> com.caucho.server.session.SessionImpl.finish(SessionImpl.java:908)
> [18:41:24.000]  at
> com 
> .caucho 
> .server 
> .connection.AbstractHttpRequest.finish(AbstractHttpRequest.java:2506)
> [18:41:24.000]  at
> com.caucho.server.http.HttpRequest.finish(HttpRequest.java:1466)
> [18:41:24.000]  at
> com 
> .caucho 
> .server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:212)
> [18:41:24.000]  at
> com 
> .caucho 
> .server.dispatch.ServletInvocation.service(ServletInvocation.java:266)
> [18:41:24.000]  at
> com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:269)
> [18:41:24.000]  at
> com.caucho.server.port.TcpConnection.run(TcpConnection.java:603)
> [18:41:24.000]  at
> com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:721)
> [18:41:24.000]  at com.caucho.util.ThreadPool 
> $Item.run(ThreadPool.java:643)
> [18:41:24.000]  at java.lang.Thread.run(Thread.java:595)
>
> [18:47:31.281] java.lang.IllegalStateException: Table[srun_:2]: inode
> block 42 has 0 fragment
> [18:47:31.281]  at com.caucho.db.store.Inode.stateError(Inode.java: 
> 1164)
> [18:47:31.281]  at com.caucho.db.store.Inode.remove(Inode.java:836)
> [18:47:31.281]  at
> com.caucho.db.store.Transaction.writeData(Transaction.java:568)
> [18:47:31.281]  at
> com.caucho.db.sql.QueryContext.unlock(QueryContext.java:537)
> [18:47:31.281]  at
> com.caucho.db.sql.RowIterateExpr.nextBlock(RowIterateExpr.java:86)
> [18:47:31.281]  at com.caucho.db.sql.Query.nextBlock(Query.java:721)
> [18:47:31.281]  at com.caucho.db.sql.Query.nextTuple(Query.java:698)
> [18:47:31.281]  at
> com.caucho.db.sql.DeleteQuery.execute(DeleteQuery.java:81)
> [18:47:31.281]  at
> com 
> .caucho 
> .db.jdbc.PreparedStatementImpl.execute(PreparedStatementImpl.java:345)
> [18:47:31.281]  at
> com

Re: [Resin-interest] Quercus and Spring proxy beans

[Scott Ferguson]

On Oct 24, 2008, at 9:17 AM, Heimo Laukkanen wrote:

> Hi all,
>
> I just noticed that Quercus does not seem to work with Spring's proxy
> objects that get created for example with annotation based
> configurations for security or transactions.
>
> @Transactional
> @Secured({"ROLE_ADMIN", "ACL_TEXT_READ"})
> public String getText() {
>
> }
>
> And in php page:
>
> $bean = spring_bean("userDemoService");
> $foo = $bean->getText();
>
> Creates error message:
>
> resource([EMAIL PROTECTED])
> /home/huima/programming/appservers/resin/resin-3.1.7/webapps/webapp/ 
> phptest.php:8:
> Fatal Error: '$Proxy15::getText' is an unknown method
>
> Any ideas on how to circumvent this?

Do you know if the proxy object is introspectable, specifically if you  
can use getClass().getMethod() to find the method?

It's possible Quercus needs to change the introspection (e.g. by  
scanning interfaces differently), but I'm not sure what exactly Spring  
is doing for those beans.

-- Scott
>
>
> I already thought about creating a dummy service that would get that
> the real service injected into it, but I'm not yet so familiar with
> the AOP mechanisms that I would what class these proxy objects are and
> how to inject them into my own object. I will study that little during
> the weekend, but would be interested to know if anyone else has any
> ideas.
>
> -huima
>
>
> ___
> 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] Update on 3.0.27

[Scott Ferguson]

On Oct 24, 2008, at 11:40 AM, Matt Pangaro wrote:

> Hi,
> I was just wondering if we could get a status update on 3.0.27, since
> there are a number of fixes in it, plus the newly discovered issue  
> with
> SSL JNI.

The plan is to work through the 3.1.x and 3.0.x regressions for next  
week and release when they're clean.

I can put up a new snapshot before that.

-- Scott

>
>
> Thanks,
>
> Matt
>
>
> ___
> 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] inode block/fragment mixup???

[Scott Ferguson]

On Oct 27, 2008, at 10:49 PM, Mattias Jiderhamn wrote:

I have now filed a report here: http://bugs.caucho.com/view.php? 
id=3025


Thanks.  I'd already filed a bug, but this has more detail.

-- Scott




 /Mattias

Mattias Jiderhamn wrote (2008-10-24 20:30):


Scott Ferguson wrote (2008-10-23 18:39):


On Oct 22, 2008, at 12:06 PM, Mattias Jiderhamn wrote:


We have a strange problem with Resin that looks like a bug but  
might

be
some configuration issue.

We hit the bug while storing more than the usual amount of data  
in a

session (during a process that takes quite a lot of time).
If we narrow things down so we store the same kind of data,  
although

not
as much (and not using so much time), the error does not come  
about.

The symptoms are that the slow request seems to finish correcly and
the
data is returned to the browser, however on the next request the
session
does no longer exist. Other sessions does not seem to be affected.
There
are errors in the log file which makes me believe the session is  
lost

during serializing/deserializing.

With the same input data, the error is always reproducible.


Do you know how large the session is?

>From what I can see about 7 MB.


  Also, does "finer" show anything interesting?


See below if there is anything you consider interesting.


There may be a limit at 64M of session data, but I doubt you're
hitting that.  It's possible there's an off-by-one issue at one of  
the
boundaries (since the data is split into fragments).  Does adding  
1 to

the session length still produce the same error?

A quick test with session.setAttribute("foo", "bar") actually  
seemed to do the trick!
Is there anything specific you would like me to try with regards to  
this?




Here is the finer log:
...
[18:00:06.234] Transaction[01:908024ea] committing
[18:00:06.234] commit-local: com.caucho.sql.ManagedConnectionImpl 
[EMAIL PROTECTED]

[18:00:06.328] idle PoolItem[jdbc/exder,7,ManagedConnectionImpl]
[18:00:07.593] Table[srun_:2] allocating block 270 fragment
[18:00:07.609] Table[srun_:2] allocating block 271 fragment
[18:00:07.609] Table[srun_:2] allocating block 272 fragment
(and so on...)
[18:00:08.312] Table[srun_:2] allocating block 333 fragment
[18:00:08.312] Table[srun_:2] allocating block 334 fragment
[18:00:08.343] java.lang.IllegalStateException: block/fragment mixup
[18:00:08.343]  at  
com.caucho.db.store.Inode.writeBlockAddr(Inode.java:1078)
[18:00:08.343]  at com.caucho.db.store.Inode.appendBlock(Inode.java: 
492)

[18:00:08.343]  at com.caucho.db.store.Inode.append(Inode.java:388)
[18:00:08.343]  at  
com 
.caucho.db.store.BlobOutputStream.flushBlock(BlobOutputStream.java: 
188)
[18:00:08.343]  at  
com.caucho.db.store.BlobOutputStream.write(BlobOutputStream.java:117)
[18:00:08.343]  at  
com.caucho.db.table.BlobColumn.setStream(BlobColumn.java:179)
[18:00:08.343]  at  
com.caucho.db.table.BlobColumn.set(BlobColumn.java:267)
[18:00:08.343]  at  
com.caucho.db.sql.UpdateQuery.execute(UpdateQuery.java:110)
[18:00:08.343]  at  
com 
.caucho 
.db.jdbc.PreparedStatementImpl.execute(PreparedStatementImpl.java: 
345)
[18:00:08.343]  at  
com 
.caucho 
.db 
.jdbc 
.PreparedStatementImpl.executeUpdate(PreparedStatementImpl.java:313)
[18:00:08.343]  at  
com 
.caucho.server.cluster.FileBacking.storeSelfUpdate(FileBacking.java: 
524)
[18:00:08.343]  at  
com.caucho.server.cluster.FileBacking.storeSelf(FileBacking.java:474)
[18:00:08.343]  at  
com.caucho.server.cluster.FileStore.store(FileStore.java:169)
[18:00:08.343]  at  
com.caucho.server.cluster.ClusterObject.store(ClusterObject.java:414)
[18:00:08.343]  at  
com.caucho.server.session.SessionImpl.save(SessionImpl.java:960)
[18:00:08.343]  at  
com 
.caucho 
.server.session.SessionImpl.saveAfterRequest(SessionImpl.java:946)
[18:00:08.343]  at  
com.caucho.server.session.SessionImpl.finish(SessionImpl.java:908)
[18:00:08.343]  at  
com 
.caucho 
.server 
.connection.AbstractHttpRequest.finish(AbstractHttpRequest.java:2506)
[18:00:08.343]  at  
com.caucho.server.http.HttpRequest.finish(HttpRequest.java:1466)
[18:00:08.343]  at  
com 
.caucho 
.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:212)
[18:00:08.343]  at  
com 
.caucho 
.server.dispatch.ServletInvocation.service(ServletInvocation.java: 
266)
[18:00:08.343]  at  
com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java: 
269)
[18:00:08.343]  at  
com.caucho.server.port.TcpConnection.run(TcpConnection.java:603)
[18:00:08.343]  at com.caucho.util.ThreadPool 
$Item.runTasks(ThreadPool.java:721)
[18:00:08.343]  at com.caucho.util.ThreadPool 
$Item.run(ThreadPool.java:643)

[18:00:08.343]  at java.lang.Thread.run(Thread.java:595)
[18:00:08.421] Http[15] no-keepalive
[18:00:08.421] Tcp[,15] closing connection  
TcpConnection[id=http--80-15,socket=JniSocketImpl 
$15452578[90827352,fd=4488],

port=Port[null:80]], total=13
(... six more...)
[18:01:06.890] Tcp[,6] com.caucho.vfs.Clie

Re: [Resin-interest] Memory leak - in Resin?

[Scott Ferguson]

On Oct 30, 2008, at 6:39 AM, Mattias Jiderhamn wrote:

> Although embarrassed to admit it, we have had long standing problems
> with PermGen memory leaks. We have gotten used to restarting the  
> server
> every time we redeploy, to avoid OutOfMemoryError. Since we would like
> to make use of - or at least evaluate - some of the new Resin features
> like WAR versioning, I thought I’d give fixing this another shot.

I've added this as http://bugs.caucho.com/view.php?id=3031

That ThreadLocal needs to be cleared in a finally block when the  
request completes.  I'll need to check on that.

-- Scott

>
>
> I have already been through (and fixed a few of) the usual suspects;
> JDBC drivers, log factories, ThreadLocals, explicit ClassLoader
> references etc. There has also been at least one bug within Resin
> causing leaks (bug 951 in Mantis).
>
> A while back I tried tracking this down using jhat, but since I have
> limited experience with this, time did not allow me to get to the  
> bottom
> of it. Today I found some more time, and also a tip on how to use
> YourKit to track this down
> (http://ampedandwired.com/2008/05/05/finding-permgen-memory-leaks-with-yourkit/
> for those interested). This lead me to something interesting, which I
> don’t quite understand.
>
> If I interpret the YourKit memory snapshot correctly, here is what is
> happening (from a Resin 3.1.6 perspective):
>
> In com.caucho.server.dispatch.ServletInvocation there is a static
> ThreadLocal holding references to the current (original) request  
> (while
> dispatching?). This means that as long as the executing (and
> dispatching) thread remains in Resins thread pool, but is not used for
> another dispatch, a handle to the original
> com.caucho.server.http.HttpRequest is held. In the request, there is a
> handle to a com.caucho.server.dispatch.Invocation, which in turn has a
> handle to - the application classloader! (And there is your PermGen  
> leak)
>
> Isn’t the fact that the ThreadLocal is never cleared an obvious memory
> leak? Or why haven’t this been fixed even though Scott seems to have
> noticed this (see
> http://bugs.caucho.com/bug_view_advanced_page.php?bug_id=2883)?
> If the leak actually is in Resin, why isn’t anybody else seeing  
> this???
> Are we doing something unusual? (The only thing I could think of was
> ServletRequest implementations inside the application being  
> dispatched,
> however I can't find any such implementations in use)
>
> /Mattias Jiderhamn
>
>
> ___
> 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] Update on 3.0.27

[Scott Ferguson]

On Oct 30, 2008, at 10:13 PM, Matt Pangaro wrote:

> Thanks for the update. A snapshot to vet the changes would be great.

http://caucho.com/download now has the most up-to-date 3.0 snapshot.

-- Scott

>
>
> Thanks,
> Matt
>
> Scott Ferguson wrote:
>> On Oct 24, 2008, at 11:40 AM, Matt Pangaro wrote:
>>
>>> Hi,
>>> I was just wondering if we could get a status update on 3.0.27,  
>>> since
>>> there are a number of fixes in it, plus the newly discovered issue
>>> with
>>> SSL JNI.
>>
>> The plan is to work through the 3.1.x and 3.0.x regressions for next
>> week and release when they're clean.
>>
>> I can put up a new snapshot before that.
>>
>> -- Scott
>
>
>
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest



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

Re: [Resin-interest] Quercus + Web Services / Zend

[Scott Ferguson]

On Nov 2, 2008, at 10:39 AM, Daniel Lopez wrote:

> Hi again,
>
> I think I found something related to the issue, as Quercus seems to
> have some problems with PHP static members.

I've files this at: http://bugs.caucho.com/view.php?id=3038

-- Scott

>
> I created the following test:
> ***
>  class Test
> {
>   protected static $_instance = null;
>   protected $_variable = null;
>   /**
>  * Singleton instance
>  */
> public static function getInstance()
> {
> $reflection = new ReflectionClass('Test');
> foreach ($reflection->getProperties() as $property) {
> $name = $property->getName();
>   echo "Member: ".$name.""
> }
>   if (null === self::$_instance) {
> self::$_instance = new self();
> }
>
> return self::$_instance;
> }
> }
>   $testInstance = Test::getInstance();
> ?>
> ***
> If I execute the test under regular PHP, the result is:
> ---
> Member: _instance
> Member: _variable
> ---
> If I execute it under Quercus, I just get
> ---
> Member: _variable
> ---
> The strange thing is that accessing the $_instance static memeber in
> this little test works, but a very similar code is inside
> Zend_Controller_Front class in the Zend framework and there it
> complains that $_instance has not been declared, even though you can
> see the declaration a couple of lines above.
>
> So, even though is seems it is not the full issue, it seems to be
> strongly related. In any case, one would say that reflection in
> Quercus is broken, right?
>
> Tested using Resin 3.1.7a and resin 3.2.1. Trying to use Zend in 3.2.1
> I don't get the error I was showing above, but a blank page and no
> error message anywhere.
>
> S!
> D.
>
> 
>
>
>
>
>
> ___
> 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] Issue with Resin setup in IIS

[Scott Ferguson]

On Nov 1, 2008, at 10:21 PM, Stavros Stavrakis wrote:


Hi All,

I have a Windows 2003 server running an the 2.1.14 version of resin.  
We have multiple sites setup in resin at the moment.
I’ve been attempting to upgrade to version 3.0 of Resin and had  
troubles surfing to my site I have.


The main thing to check with IIS or Apache is the /caucho-status page,  
e.g. http://192.168.1.10/caucho-status.


That page will show you the isapi_srun.dll version, the Resin instance  
used as a config server (to pass configuration from Resin to  
isapi_srun), and show the URL mapping and cluster configuration.


So, you should look at that page first to understand why IIS isn't  
contacting Resin.


-- Scott



Basically, I am able to access my site via http://localhost:8080/application 
 but when I try to get to it via the external IP address
http://888.888.888.88/application it does not find it for some  
reason. I am guessing it’s resin.conf file tag that needs to be  
modified.
I include below the host section (which I thought would need  
modifying in order to get the site running via the IP).


Reading off the documentation, it states to set the IIS directory  
for the webapp root below.. Not sure what else I need to be wary of.


Any help would be much appreciated.



  
  
D:/inetpub/ 
wwwroot/



  






   

   



Regards,

Stavros Stavrakis



ASTA Solutions Pty Ltd
Address: Suite 9, 2 Park Drive, Bundoora, VIC 3083
Tel:   +61 3 9479 3779
Fax:  +61 3 9277 7130
Mob: +61 409 055 403
Web: http://www.astasolutions.com.au

___
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] Memory leak - in Resin?

[Scott Ferguson]

On Nov 4, 2008, at 1:24 PM, Mattias Jiderhamn wrote:

I noticed this bug was marked as resolved, so I tried reloading our  
webapp running on Resin compiled from SVN. Same problem.


Familiarizing myself a bit further with YourKit and comparing with  
the sources, I believe both  
com.caucho.jca.UserTransactionProxy._threadTransaction and  
com.caucho.transaction.TransactionManagerImpl._threadTransaction  
should be cleared properly.
Although I have not yet found the path to the HttpRequest. I could  
send you my YourKit snapshot if that helps in tracking this down.


Did you build from resin/branches/3.1 or the trunk?  The trunk changes  
aren't checked in yet.


The fix is only for the SecurityContext clearing.  The comet changes  
had messed up the automatic clearing of that ThreadLocal.


-- Scott




 /Mattias

Scott Ferguson wrote (2008-10-30 16:11):


On Oct 30, 2008, at 6:39 AM, Mattias Jiderhamn wrote:



Although embarrassed to admit it, we have had long standing problems
with PermGen memory leaks. We have gotten used to restarting the
server
every time we redeploy, to avoid OutOfMemoryError. Since we would  
like
to make use of - or at least evaluate - some of the new Resin  
features

like WAR versioning, I thought I’d give fixing this another shot.


I've added this as http://bugs.caucho.com/view.php?id=3031

That ThreadLocal needs to be cleared in a finally block when the
request completes.  I'll need to check on that.

-- Scott




In com.caucho.server.dispatch.ServletInvocation there is a static
ThreadLocal holding references to the current (original) request
(while
dispatching?). This means that as long as the executing (and
dispatching) thread remains in Resins thread pool, but is not used  
for

another dispatch, a handle to the original
com.caucho.server.http.HttpRequest is held. In the request, there  
is a
handle to a com.caucho.server.dispatch.Invocation, which in turn  
has a

handle to - the application classloader! (And there is your PermGen
leak)

Isn’t the fact that the ThreadLocal is never cleared an obvious  
memory

leak? Or why haven’t this been fixed even though Scott seems to have
noticed this (see
http://bugs.caucho.com/bug_view_advanced_page.php?bug_id=2883)?
If the leak actually is in Resin, why isn’t anybody else seeing
this???
Are we doing something unusual? (The only thing I could think of was
ServletRequest implementations inside the application being
dispatched,
however I can't find any such implementations in use)

/Mattias Jiderhamn


___
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] Memory leak - in Resin?

[Scott Ferguson]

On Nov 4, 2008, at 2:10 PM, Mattias Jiderhamn wrote:


Scott wrote:

Did you build from resin/branches/3.1 or the trunk?

3.1 branch.

Now I'm browsing around the  
com.caucho.server.port.TcpConnection._request which is never  
explicitly release, but I realize it's getting a bit too late on  
this side of the Atlantic ocean so I better continue tomorrow unless  
you find the source of the problem until then.


That field is never released.  The TcpConnection, Request and Response  
triple are reused together.


-- Scott




 /Mattias


Mattias Jiderhamn wrote (2008-11-04 22:24):


I noticed this bug was marked as resolved, so I tried reloading our  
webapp running on Resin compiled from SVN. Same problem.


Familiarizing myself a bit further with YourKit and comparing with  
the sources, I believe both  
com.caucho.jca.UserTransactionProxy._threadTransaction and  
com.caucho.transaction.TransactionManagerImpl._threadTransaction  
should be cleared properly.
Although I have not yet found the path to the HttpRequest. I could  
send you my YourKit snapshot if that helps in tracking this down.


 /Mattias

Scott Ferguson wrote (2008-10-30 16:11):


On Oct 30, 2008, at 6:39 AM, Mattias Jiderhamn wrote:


Although embarrassed to admit it, we have had long standing  
problems

with PermGen memory leaks. We have gotten used to restarting the
server
every time we redeploy, to avoid OutOfMemoryError. Since we would  
like
to make use of - or at least evaluate - some of the new Resin  
features

like WAR versioning, I thought I’d give fixing this another shot.


I've added this as http://bugs.caucho.com/view.php?id=3031

That ThreadLocal needs to be cleared in a finally block when the
request completes.  I'll need to check on that.

-- 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] Displaytag problem

[Scott Ferguson]

On Nov 10, 2008, at 3:48 PM, Mike McNally wrote:

I'm trying to get a pretty simple Stripes-based web application  
running in a fresh install of Resin 3.1.6.  The application works  
*except* for a page that attempts to use the "displaytag" tag  
library (which I've not used before).


It seems that Resin is unable/unwilling to recognize any of the  
setters in the displaytag tag implementation classes, in all cases  
failing with:


attribute 'id' in tag 'display:table' has no corresponding set  
method in


tag class 'org.displaytag.tags.TableTag'
It doesn't matter what attribute I use or what sort of value I pass  
to it from the .jsp page. Resin 3.0.x and 3.1.6 all do pretty much  
the same thing. Looking at the displaytag sources and the Resin  
source, I can't see where it's getting hung up. There are in fact  
public setter methods in the displaytag code, and they seem OK to me.


I'm pretty sure I've seen implications from random forum questions  
that there are people using displaytag with Resin, so I suspect  
there's something I'm just not doing right.


Scanning the TableTag API, it doesn't look like there is a setId  
method in TableTag (there is a setHtmlId).  So I wouldn't expect Resin  
to allow that to work.


Do you know what the *.tld looks like for that Tag?

-- Scott




Again, Resin 3.1.6, Displaytag 1.1.1, JDK 6, Linux.

Thanks for any hints or sympathy :)

--
Turtle, turtle, on the ground,
Pink and shiny, turn around.
___
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] Displaytag problem

[Scott Ferguson]

On Nov 10, 2008, at 4:16 PM, Mike McNally wrote:

> The .tld looks pretty ordinary (to me), though its  tag  
> is 1.2 and not 2.0.  I don't know what evil that might cause but I  
> can sure find out.

Well, the issue is the "id" attribute to getHtmlId (?) mapping.  I  
can't remember any part of the JSP spec that does that mapping (which  
is why the .tld was important), but it's possible there's something  
I've missed.

-- Scott

>
>
>
> -- 
> Turtle, turtle, on the ground,
> Pink and shiny, turn around.
> ___
> 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] Displaytag problem

[Scott Ferguson]

On Nov 11, 2008, at 10:15 AM, Mike McNally wrote:




Well, the issue is the "id" attribute to getHtmlId (?) mapping.  I
can't remember any part of the JSP spec that does that mapping (which
is why the .tld was important), but it's possible there's something
I've missed.

OK, well again, it's not just that attribute that doesn't work --  
*none* of the tag attributes can be set. That example was just one  
iteration of trying various things. In point of fact it's the "name"  
attribute that I really want to use.


Can you send the error message for the name attribute?  It should be  
different from the id message since setName does exist.


-- Scott






--
Turtle, turtle, on the ground,
Pink and shiny, turn around.
___
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] Displaytag problem

[Scott Ferguson]

On Nov 11, 2008, at 12:45 PM, Mike McNally wrote:

> Well I got the app more-or-less working in Tomcat, and I decided to  
> try Resin again. It's perfectly happy now.
>
> The only thing I can think of is that while banging on it in Tomcat  
> I had some issues with Stripes needing a few .jar files from the  
> Apache Commons collection.  I have no idea how or why that'd affect  
> the Resin JSP processor, but there you go.

Ah.  I've added a bug report.  It's possible that the missing .jar  
files are messing up Resin's introspection and instead of reporting  
the error as a linking problem, it's getting reported as a missing  
method.  In other words, Resin's error report might be very  
misleading.  I'll need to see if I can duplicate the problem.

-- Scott
>
>
> I appreciate the effort put into my goose chase nevertheless. I'm so  
> happy that I don't have to deal with Tomcat now :)
>
>
> -- 
> Turtle, turtle, on the ground,
> Pink and shiny, turn around.
> ___
> 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: tags in resin.xml

[Scott Ferguson]

On Nov 12, 2008, at 7:46 AM, Elliot Lee wrote:

> Hi,
>
> I'm in the middle of reworking our Resin configuration so we can have
> a consistent configuration across both development and production. I'm
> trying to use the  and  tags to conditionally
> use a particular configuration based on whether it's a devel or
> production box. The problem I'm running into is that the watchdog
> seems to know nothing about the resin: tags in the config file.
>
> For example, if I have in conf/resin.xml a few lines that say:
>
> 
> 
> 
>
> ...and then I start resin by running "bin/resin.sh , I get an error
> message saying:
>   server-id 'myserver' has no matching  definition.
> However, if I remove the open and close tags for resin:if, it works
> fine. This is why I believe that the watchdog is not really parsing
> the whole config file and processing the resin:* tags...

That should be fixed in the latest version (although it might just be  
the snapshots.)

-- Scott

>
>
> Any suggestions?
>
> Best,
> -- Elliot
>
>
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest



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

[Resin-interest] Resin 3.1.8 pre-release snapshot

[Scott Ferguson]

I've put up a snapshot that should be the final release for 3.1.8, but  
I'll be leaving it up until Monday before the actual release to give a  
bit of extra stress test time and let people find anything critical  
that we missed.

-- Scott 



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

Re: [Resin-interest] Can I use Resin as a HTTP load balancer?

[Scott Ferguson]

On Nov 12, 2008, at 6:58 PM, Zeke wrote:


Hi, All:
  Can anyone kindly tell me if I can use Resin as a HTTP load  
balancer? I have a cluster which contains several machines having  
JBoss or similar application server running on them. Can I use Resin  
to dispatch HTTP request? That is if I sent a HTTP request to Resin,  
can it forward the request to one of the application server in the  
cluster? If so, can it support "sticky" HTTP session and fail-over?


Well, you can use the proxy in rewrite-dispatch, but it's not as  
capable as Resin's native load balancer.  It is would be possible for  
us to enhance it to have the same capabilities, although it would  
require a bit of a refactor.


-- Scott




Thanks!
Zeke



[广告] 金秋最关注楼盘-房不胜房 
___

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] session persistence - JDBC vs cluster.

[Scott Ferguson]

On Nov 14, 2008, at 12:02 AM, YoKay wrote:

>
> I have a question:
>
> Is cluster-store/tcp-store only available in resin 3.x pro version ?

Correct.

> I think for 2.1.7 it was allowed in non pro version.

I believe that was true.  2.1 split the pro/non-pro by APIs, while 3.x  
splits by clustering/performance/reliability, but includes all the  
APIs in the non-pro.

-- Scott

>
>
> It would be very nice if some one can clarify.
>
> Thanks.
>
>
> Scott Ferguson wrote:
>>
>>
>> On Mar 17, 2008, at 10:15 AM, Chad Cannell wrote:
>>
>>> What is the difference between tcp-store and cluster-store?
>>
>> They're the same.  cluster-store is the newer name.  tcp-store is  
>> just
>> for backward compatibility.
>>
>> If you turn on "finer" logging, you should see the size of the  
>> session
>> getting stored.
>>
>> -- Scott
>>
>>>
>>>
>>> c
>>>
>>> On Fri, 2008-03-14 at 15:18 -0400, Chad Cannell wrote:
>>>> We currently have a Resin cluster of 25 nodes, configured to use  
>>>> JDBC
>>>> persistence. We typically have around 140,000 active sessions.
>>>>
>>>> I am considering moving to cluster store persistence. We have been
>>>> running on a single MySQL database. I have started to look into
>>>> clustring it and thoght maybe cluster store would be better.
>>>>
>>>> Our app doesn't use the session for anything other than login state
>>>> and
>>>> the cluster simply provides SSO and LB.
>>>>
>>>> How would I go about determining what memory consumption our  
>>>> sessions
>>>> would add to each node's JVM? Is there any documentation that would
>>>> show
>>>> how much memory 1 session would take in it's basic form? I could  
>>>> then
>>>> extrapilate that out to our load.
>>>>
>>>> Any perf gain/loss by going to cluster store?
>>>>
>>>> My goal is better HA of session data and no performance  
>>>> degradation.
>>>>
>>>> -3
>>>>
>>>>
>>>> ___
>>>> 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
>>
>>
>
> -- 
> View this message in context: 
> http://www.nabble.com/session-persistence---JDBC-vs-cluster.-tp16058626p20496225.html
> Sent from the Resin mailing list archive at Nabble.com.
>
>
>
> ___
> 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 3.1.7a & TeamCity

[Scott Ferguson]

On Nov 15, 2008, at 6:49 AM, Jan Kriesten wrote:

>
> Hi,
>
> has anyone successfully installed TeamCity with resin?

I've added this as a bug report.  It sounds like Resin's ${server}  
variable is conflicting with one of TeamCity's variables, which  
shouldn't happen because Resin's internal variable lookup should have  
a lower priority.  I'll need to check on that behavior.  It's possible  
the priorities are incorrect.

-- Scott

>
>
> I get errors like the following during setting up my admin account:
>
> Error message: javax.el.PropertyNotFoundException:  
> 'fullServerVersion' is an
> unknown bean property of 'com.caucho.server.cluster.Cluster$ServerVar'
>
> and
>
> Error message: javax.el.PropertyNotFoundException: 'queue' is an  
> unknown bean
> property of 'com.caucho.server.cluster.Cluster$ServerVar'
>
> The first one is referenced in file 'WEB-INF/tags/version.tag' as
>
> ${server.fullServerVersion}
>
> Can it be that resin tries to evaluate this on a false bean?
>
> Best regards, --- Jan.
>
>
>
> ___
> 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]

[Scott Ferguson]

On Nov 19, 2008, at 10:17 AM, Jan Kriesten wrote:

>
> Hi,
>
> I just came along another problem with resin (3.2.1 this time):
>
> Error message: java.lang.InstantiationException: jsp:useBean needs  
> 'bean' or 'class'
> Show stacktrace
>
> That shouldn't happen I suppose, right?!
>
> The syntax ref at Sun says:
>
> ---8<---
> type="package.class"
>
> If the Bean already exists in the scope, gives the Bean a data type  
> other than
> the class from which it was instantiated. If you use type without  
> class or
> beanName, no Bean is instantiated. The package and class name are  
> case sensitive.
> ---8<---
>
> So, why is resin complaining at this?

Does the bean exist?  If the bean isn't in the scope, then you do need  
the bean or class, because the type attribute is only allowed for pre- 
existing beans.

-- Scott
>
>
>
> Best regards, --- Jan.
>
>
> ___
> 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]

[Scott Ferguson]

On Nov 19, 2008, at 11:13 AM, Jan Kriesten wrote:

>
> Hi Scott,
>
>> Does the bean exist?  If the bean isn't in the scope, then you do  
>> need
>> the bean or class, because the type attribute is only allowed for  
>> pre-
>> existing beans.
>
> yes, it is. It's TeamCity again - after I changed all references from
> ${server.*} to ${tcServer} so that it would run at all.
>
> After that resin 3.1.8 complained about
>
> Caused by: java.lang.ClassNotFoundException:
> _jsp._WEB_22dINF._tags._linkScript__tag [java.io.IOException: class  
> file length
> mismatch]

You should be able to delete the WEB-INF/work to work around that.   
Resin should be deleting broken .class files for JSP, but I'm not sure  
if that auto-delete functionality was added for .tag as well.

-- Scott

>
>
> which isn't fixed in the 3.1.x branch, so I took my chances and  
> tried 3.2.1 -
> with no luck due to the useBean-type problem.
>
> Best regards, --- Jan.
>
>
>



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

Re: [Resin-interest] Memory leak - in Resin?

[Scott Ferguson]

On Nov 24, 2008, at 11:08 PM, Mattias Jiderhamn wrote:

I'm still battling this PermGen leak and frankly I'm really starting  
to doubt that I know what I'm doing anymore. I'd be very happy if  
anyone would care to explain that to me...


Since my last post Scott and I have discussed potential class loader  
leaks and some of them have been fixed in the 3.1.8 release. It  
seems there is (at least) one leak that didn't get fixed in 3.1.8. I  
have made a quick and dirty patch to avoid that leak. If anyone  
would care to try, the patch (which includes a few other things  
probably fixed in 3.1.8 already) can be found here:

http://jiderhamn.se/resin-leak.patch

However, even with that patch, it seems there is still some kind of  
PermGen leak that eventually leads to OutOfMemoryError. I have  
created a small application with the sole purpose of detecting these  
leaks. If anyone would care to try, it can be found here (sources  
included): http://jiderhamn.se/leak.war
You will need to add some JARs to the WEB-INF/lib directory;  
preferrably a couple of large ones like spring.jar and hibernate.jar  
(don't use Resin JARs though).
Then just drop the WAR in a clean installation of Resin 3.1.8  
(preferrably patched with the patch above).

Hit http://...:nn/leak (once is enough)
Force a redeploy by either deleting the webapps/leak dir or  
touch:ing leak.war

Hit http://...:nn/leak again
Repeat the last two steps for as long as you'd like

What you should see - or at least what I see on one Linux machine  
and one Windows machine - is the (ClassLoadingMXBean)  
loadedClassCount and the (MemoryPoolMXBean) Used Perm Gen steadily  
increasing (while the unloadedClassCount remains pretty stable) for  
every redeploy, which indicates a classloader leak. But I just can't  
find that leak.


Thanks.

Right now, our code base is a bit stuck due to the WebBeans/OSGi  
upgrade (for Resin 4.0.0, was 3.2.2).  Once that's cleaned up and I  
can put up a snapshot I can take a look.


-- Scott



Now, here are the things really bugging me:
1. If I keep redeploying over and over, I will eventually get closer  
and closer to the Perm Gen Max (in some instances, I have seen the  
following behaivour instead turn up when Used reaches Init if Init  
is large enough). Then suddenly the unloadedClassCount is increased,  
but not with all the unused classes - only about the amount of one  
redeployment. Redeploy again, and it will increase another step.  
Meanwhile, the loadedClassCount remains pretty stable, since we are  
loading as many new classes as are unloaded. It's as if there was a  
FIFO queue/LRU cache of classloaders, so that the oldest one is  
garbage collected once there is not enough space for a new one.  
However, after a while there is (assumably) not enough space to  
create the new classloader before the old one is garbage collected,  
and I get OutOfMemoryError somewhere in the middle. Sometimes I am  
actually able to recover from this error by waiting for the GC to do  
it's job and then just try again.


2. Now I attached YourKit, looking for dangling classloaders as of  
the inital post. I found none. In fact, the Classes without  
Instances inspection only shows the classes in the added JARs from  
the last redeployment, so when tracing back to GC root, it goes via  
the current EnvironmentClassLoader which is correct. There are also  
no excessive instances of EnvironmentClassLoader. Hmm... Now wait a  
minute. Look at the total number of java.lang.Class objects. It does  
not match with the totalLoadedClassCount. In fact, the total number  
of classes found by YourKit is about the same as the  
totalLoadedClassCount on the very first hit of the application,  
before any redeployments. So from YourKits point of view, there is  
no classloader leak! But why then isn't the PermGen space reclaimed.  
This led me to wonder if there was some kind of JVM bug. (As a side  
note, I have yet to try with some other profiler)


3. So, I modified the test application (see commented out code in  
MyServlet.java) to load the classes of the JARs in a regular  
java.net.URLClassLoader which is then immediately thrown away. No  
leak. loadedClassCount is immediately decreased (and  
unloadedClassCount increased), as is the Used Perm Gen. That is, it  
behave the way we want the redeployment to behave.
Ok, lets take one step down in the classloader hierachy and load all  
the classes via a disposable com.caucho.loader.DynamicClassLoader.  
No leak.
So, what if I load them with a  
com.caucho.loader.EnvironmentClassLoader which is then destroy()ed  
and left for garbage collection. The leak is back!  
EnvironmentClassLoader has now applied to become prime suspect. In  
order to track things down I subclassed EnvironmentClassLoader  
inside my application and planned to make changes there. Well ...  
before any changes, the leak is nowhere to be found.


What is going on here?
Anything that might help my sanity would

Re: [Resin-interest] Problems installing TeamCity 4.0 on Resin Professional 3.1.8

[Scott Ferguson]

On Dec 4, 2008, at 12:19 AM, Tero Ripattila wrote:

> Hello, I tried to install TeamCity 4.0 by simply placing the .war  
> file in
> an appropriate directory and then configuring it in resin.conf. When  
> I try
> to access /teamCity, I get this exception:

I've filed a bug on this http://bugs.caucho.com/view.php?id=3115

That's an odd bug, though, since I'm not sure how Resin would affect  
Spring in that way.

-- Scott

>
>
> javax.servlet.ServletException:
> org.springframework.beans.factory.UnsatisfiedDependencyException:
> Error creating bean with name 'defaultMessageProcessorFactory' defined
> in URL
> [jar:file:/D:/Teamcity/webapp/WEB-INF/lib/server.jar!/META-INF/ 
> buildServerSpring.xml]:
> Unsatisfied dependency expressed through constructor argument with  
> index
> 0 of type [jetbrains.buildServer.serverSide.BuildServerEx]: Ambiguous
> constructor
> argument types - did you specify the correct bean references as  
> constructor
> arguments?
>at
> com 
> .caucho 
> .server 
> .dispatch.ServletConfigImpl.createServlet(ServletConfigImpl.java:768)
>at
> com.caucho.server.dispatch.ServletManager.init(ServletManager.java: 
> 159)
>at com.caucho.server.webapp.WebApp.start(WebApp.java:1874)
>at
> com 
> .caucho 
> .server.deploy.DeployController.startImpl(DeployController.java:667)
>at
> com 
> .caucho 
> .server.deploy.DeployController.restartImpl(DeployController.java:630)
>at
> com 
> .caucho 
> .server 
> .deploy 
> .StartAutoRedeployAutoStrategy 
> .alarm(StartAutoRedeployAutoStrategy.java:177)
>at
> com 
> .caucho 
> .server.deploy.DeployController.handleAlarm(DeployController.java:789)
>at com.caucho.util.Alarm.handleAlarm(Alarm.java:375)
>at com.caucho.util.Alarm.run(Alarm.java:345)
>at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:730)
>at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:649)
>at java.lang.Thread.run(Thread.java:619)
>
> This is how I’ve got it configured:
>
> 
>  
>  archive-path="D:/Teamcity/install/teamCity.war"/> 
>
> I’ve followed instructions here,
> http://www.jetbrains.net/confluence/display/TCD4/Installing+and+Configuring+the+TeamCity+Server#InstallingandConfiguringtheTeamCityServer-InstallingandConfiguringtheTeamCityserver
>  
> ,
> and got my data directory, %TEAMCITY_DATA_PATH%, pointing to
> D:\Teamcity\data.
>
> Any ideas what’s broken?
> JetBrains confirmed that TeamCity works fine with TomCat, Glassfish  
> (well,
> they can be both considered as TomCat in this case) and Jetty.
>
> Thanks,
>
> Tero
>
>
>
>
>
> ___
> 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] Cluster sessions don't expire

[Scott Ferguson]

On Dec 4, 2008, at 2:43 AM, Richard Grantham wrote:

> My woes with clustered sessions and Resin never seem to end!
>
> We switched from database-backed sessions to clustered sessions due to
> issue whereby sessions did not invalidate immediately, which lead to
> people logging out and finding themselves still logged in. Now we find
> that sessions do not expire after the configured period of inactivity.
> I'm using Resin-Pro 3.1.7a in a three-node cluster.
>
> Is this a known issue or am I able to configure my way out of it?

Does the logout code call session.invalidate()?  Or are you relying on  
the timeout?  invalidate() is the correct, reliable way of closing the  
session, while the timeout is heuristic.

-- Scott

>
>
> rgds,
>
> Richard
>
>
>
> Richard Grantham
> Development
>
> ---
> [EMAIL PROTECTED]
> Limehouse Software Ltd
>
> DDI: (020) 7566 3336
> Main: (020) 7566 3320
> Fax: (020) 7566 3321
>
> Limehouse Software Ltd
> Bridewell Gate
> 9 Bridewell Place
> London
> EC4V 6AW
>
> Manchester Office:
> 3rd Floor, The Triangle, Exchange Square, Manchester M4 3TR
> Tel: (0161) 240 2440, Fax: (0161) 240 2441, ISDN: 08700 119 400
>
> Check out Limehouse Software's innovative solutions
> www.limehousesoftware.co.uk - Transforming the way you publish and  
> consult on information
>
> The information contained in this e-mail or in any attachments is  
> confidential and is intended solely for the named addressee only.  
> Access to this e-mail by anyone else is unauthorised. If you are not  
> the intended recipient, please notify Limehouse Software Ltd  
> immediately by returning this e-mail to sender or calling 020 7566  
> 3320 and do not read, use or disseminate the information. Opinions  
> expressed in this e-mail are those of the sender and not necessarily  
> the company. Although an active anti-virus policy is operated, the  
> company accepts no liability for any damage caused by any virus  
> transmitted by this e-mail, including any attachments.
>
>
> ___
> 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] Cluster sessions don't expire

[Scott Ferguson]

On Dec 4, 2008, at 9:31 AM, Richard Grantham wrote:

> Yes, the logout code calls session.invalidate() and it works fine. I
> have some application logic in SessionListener.sessionDestroyed(...)
> which does some housekeeping after someone presses logout or their
> session times out, so it's important it's called. I'm finding that the
> session does not time out in the configured time (60 seconds) when,  
> for
> instance, you close the browser, so SessionListener.sessionDestroyed()
> is not called.

I assume the application is some kind of ajax connection so a 60  
second timeout makes sense?

We might need to do some work to add that kind of precision.  Because  
the session timeout was designed when 30 minute timeouts were the  
norm, not short values, the session reaping is fairly slow.

I've added a report at http://bugs.caucho.com/view.php?id=3116

-- Scott

>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ferguson
> Sent: 04 December 2008 16:27
> To: General Discussion for the Resin application server
> Subject: Re: [Resin-interest] Cluster sessions don't expire
>
>
> On Dec 4, 2008, at 2:43 AM, Richard Grantham wrote:
>
>> My woes with clustered sessions and Resin never seem to end!
>>
>> We switched from database-backed sessions to clustered sessions due  
>> to
>
>> issue whereby sessions did not invalidate immediately, which lead to
>> people logging out and finding themselves still logged in. Now we  
>> find
>
>> that sessions do not expire after the configured period of  
>> inactivity.
>> I'm using Resin-Pro 3.1.7a in a three-node cluster.
>>
>> Is this a known issue or am I able to configure my way out of it?
>
> Does the logout code call session.invalidate()?  Or are you relying on
> the timeout?  invalidate() is the correct, reliable way of closing the
> session, while the timeout is heuristic.
>
> -- Scott
>
>>
>>
>> rgds,
>>
>> Richard
>>
>>
>>
>> Richard Grantham
>> Development
>>
>> ---
>> [EMAIL PROTECTED]
>> Limehouse Software Ltd
>>
>> DDI: (020) 7566 3336
>> Main: (020) 7566 3320
>> Fax: (020) 7566 3321
>>
>> Limehouse Software Ltd
>> Bridewell Gate
>> 9 Bridewell Place
>> London
>> EC4V 6AW
>>
>> Manchester Office:
>> 3rd Floor, The Triangle, Exchange Square, Manchester M4 3TR
>> Tel: (0161) 240 2440, Fax: (0161) 240 2441, ISDN: 08700 119 400
>>
>> Check out Limehouse Software's innovative solutions
>> www.limehousesoftware.co.uk - Transforming the way you publish and
>> consult on information
>>
>> The information contained in this e-mail or in any attachments is
>> confidential and is intended solely for the named addressee only.
>> Access to this e-mail by anyone else is unauthorised. If you are not
>> the intended recipient, please notify Limehouse Software Ltd
>> immediately by returning this e-mail to sender or calling 020 7566
>> 3320 and do not read, use or disseminate the information. Opinions
>> expressed in this e-mail are those of the sender and not necessarily
>> the company. Although an active anti-virus policy is operated, the
>> company accepts no liability for any damage caused by any virus
>> transmitted by this e-mail, including any attachments.
>>
>>
>> ___
>> 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] Cluster sessions don't expire

[Scott Ferguson]

On Dec 5, 2008, at 1:29 AM, Richard Grantham wrote:

> Well, usually it's 60 minutes. The 60 second timeout is set when  
> someone
> closes the browser without logging out (JavaScript catches the event  
> and
> calls a JSP which sets the new session timeout with
> session.setMaxInactiveInterval(60)). This is so that if someone loses
> their connection to the internet they will be able to continue working
> without issue when it comes back (assuming it's back in under an  
> hour).
> The timeout is being set by the JSP but is not acted upon.
>
> Perhaps I should explain the use case. Our application maintains a  
> list
> who is logged into the system. It also allows people to lock things  
> for
> editing. So that people can't lock things and go off on holiday
> preventing others from working we unlock anything they have locked and
> clear them out of the logged in list when a session is invalidated.
> Right now people are just closing the browser and going home and their
> colleagues are unable to continue the work the next day. I'd agree  
> that
> half the issue is education ("please press logout") but it's also
> something we need to be pro-active about.

Thanks.  I've filed a bug report at http://bugs.caucho.com/view.php?id=3122 
.

Your symptoms are a definite bug, since the maximum slack should be  
about 15 minutes for session expiry (because of the implementation  
limitations I'd mentioned).  Nothing at all like a day.

-- Scott

>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ferguson
> Sent: 04 December 2008 17:47
> To: General Discussion for the Resin application server
> Subject: Re: [Resin-interest] Cluster sessions don't expire
>
>
> On Dec 4, 2008, at 9:31 AM, Richard Grantham wrote:
>
>> Yes, the logout code calls session.invalidate() and it works fine. I
>> have some application logic in SessionListener.sessionDestroyed(...)
>> which does some housekeeping after someone presses logout or their
>> session times out, so it's important it's called. I'm finding that  
>> the
>
>> session does not time out in the configured time (60 seconds) when,
>> for instance, you close the browser, so
>> SessionListener.sessionDestroyed()
>> is not called.
>
> I assume the application is some kind of ajax connection so a 60  
> second
> timeout makes sense?
>
> We might need to do some work to add that kind of precision.  Because
> the session timeout was designed when 30 minute timeouts were the  
> norm,
> not short values, the session reaping is fairly slow.
>
> I've added a report at http://bugs.caucho.com/view.php?id=3116
>
> -- Scott
>
>>
>>
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of Scott  
>> Ferguson
>> Sent: 04 December 2008 16:27
>> To: General Discussion for the Resin application server
>> Subject: Re: [Resin-interest] Cluster sessions don't expire
>>
>>
>> On Dec 4, 2008, at 2:43 AM, Richard Grantham wrote:
>>
>>> My woes with clustered sessions and Resin never seem to end!
>>>
>>> We switched from database-backed sessions to clustered sessions due
>>> to
>>
>>> issue whereby sessions did not invalidate immediately, which lead to
>>> people logging out and finding themselves still logged in. Now we
>>> find
>>
>>> that sessions do not expire after the configured period of
>>> inactivity.
>>> I'm using Resin-Pro 3.1.7a in a three-node cluster.
>>>
>>> Is this a known issue or am I able to configure my way out of it?
>>
>> Does the logout code call session.invalidate()?  Or are you relying  
>> on
>
>> the timeout?  invalidate() is the correct, reliable way of closing  
>> the
>
>> session, while the timeout is heuristic.
>>
>> -- Scott
>>
>>>
>>>
>>> rgds,
>>>
>>> Richard
>>>
>>>
>>>
>>> Richard Grantham
>>> Development
>>>
>>> ---
>>> [EMAIL PROTECTED]
>>> Limehouse Software Ltd
>>>
>>> DDI: (020) 7566 3336
>>> Main: (020) 7566 3320
>>> Fax: (020) 7566 3321
>>>
>>> Limehouse Software Ltd
>>> Bridewell Gate
>>> 9 Bridewell Place
>>> London
>>> EC4V 6AW
>>>
>>> Manchester Office:
>>> 3rd Floor, The Triangle, Exchange Square, Manchester M4 3TR
>>> Tel: (0161) 240 24

Re: [Resin-interest] Using php views in Spring framework - can one benefit from resin Pro compilation features?

[Scott Ferguson]

On Dec 4, 2008, at 7:07 PM, Heimo Laukkanen wrote:

> Hi all,
>
> I'm using Quercus views in out project as Spring Framework MVC views
> with in similar way as is done in Resin's quercus servlet.

Very cool.
>
>
> I was just wondering whether we could benefit from or use Caucho Pro's
> capabilities to compile php code into javacode in our project somehow
> - even when we are not using QuercusServlet?
>
> Is there a source-code available for QuercusServlet in the pro-version
> that could be used as a base, if we would like to use the pro version
> of the appserver and quercus?

If you're calling the classes directly, you can instantiate a  
com.caucho.quercus.ProQuercus instead of a  
com.caucho.quercus.Quercus.  I haven't tried that directly, but that  
should be the only difference.

At some point, we should add that capability to javax.script, although  
Quercus does need a work directory, and for embedded servers or other  
app-servers we'll probably need to add some kind of config option.

-- Scott

>
>
> -huima
>
>
> ___
> 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] when will v 3.2 will be stable

[Scott Ferguson]

On Dec 7, 2008, at 3:23 PM, Riccardo Cohen wrote:

> Hello
> I'm currently using v3.2.0 and it is relatively stable, except for
> certain non-critical points.
> I'd like to know if there is planned date for a "stable" 3.2 ?

May/June 2009 :-(

We're tied to the release of the JavaEE 6 specifications, which won't  
be final until JavaOne 2009.  And the  draft specs are changing  
radically.   For example, WebBeans configuration has been totally  
reworked (it's very nice.)  And the Servlet support for comet is  
totally different from the early draft.

So we already know there will be large changes in the APIs and  
configuration files in the next few release.  (Based on those changes  
and a bunch of our own, we're renaming 3.2 to 4.0, so people will be  
less surprised by the scope of the changes.)

The 4.0 (3.2) releases will be fully tested, but we just can't call it  
"stable" while the APIs and configuration files are changing so much.

-- Scott

>
>
> Thanks
>
> -- 
> Riccardo Cohen
> Architecte du Logiciel
> http://www.architectedulogiciel.fr
> +33 (0)6.09.83.64.49
>
>
>
> ___
> 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] thread dump from StatService

[Scott Ferguson]

On Dec 10, 2008, at 2:19 PM, Vinny wrote:

> Running Resin 3.1.6 on centos linux 5,  2.0ghz proc , 2G ram.
> I have a box that is running a bunch of virtual hosts configured in  
> resin and also connects to Apache 2.2.3 via mod_caucho.
>
> I am getting these in the logs and I'm wondering how I can read this  
> in order to figure out why my cpu load is being pegged so high

Can you do a 'ps' or 'top' to make sure that Resin is the overloading  
process?  Since that thread dump doesn't show any active threads, if  
the Resin JVM has a high CPU, then something odd is happening.

With the exception of the "CMS" thread, those are all idle Resin  
threads.  So the load due to Resin should be zero based on that thread  
dump.

-- Scott

>
> Thanks in advance:
>
> ==> /usr/local/resin/log/jvm-default.log <==
> [21:36:00.000] StatService[] cpu-load=11.57
> [21:36:00.001] StatService[] dumping threads due to cpu load=11.57
> [21:36:00.003] Thread Dump:
> [21:36:00.003]
> [21:36:00.003] "Signal Dispatcher" id=5 RUNNABLE
> [21:36:00.003]
> [21:36:00.003] "Surrogate Locker Thread (CMS)" id=4 RUNNABLE
> [21:36:00.003]
> [21:36:00.003] "resin-pro-statistics" id=27 RUNNABLE
> [21:36:00.003]   at sun.management.ThreadImpl.getThreadInfo0  
> (ThreadImpl.java) (native)
> [21:36:00.003]   at sun.management.ThreadImpl.getThreadInfo  
> (ThreadImpl.java:147)
> [21:36:00.003]   at  
> com.caucho.server.admin.ThreadDump.threadDumpImpl (ThreadDump.java:46)
> [21:36:00.003]   at com.caucho.server.admin.ThreadDump.dumpThreads  
> (ThreadDump.java:38)
> [21:36:00.003]   at com.caucho.server.admin.StatService.run  
> (StatService.java:135)
> [21:36:00.003]   at java.lang.Thread.run (Thread.java:619)
> [21:36:00.003]
> [21:36:00.003] "RMI TCP Accept-0" id=10 RUNNABLE (in native)
> [21:36:00.003]   at java.net.PlainSocketImpl.socketAccept  
> (PlainSocketImpl.java) (native)
> [21:36:00.003]   at java.net.PlainSocketImpl.accept  
> (PlainSocketImpl.java:384)
> [21:36:00.003]   at java.net.ServerSocket.implAccept  
> (ServerSocket.java:453)
> [21:36:00.003]   at java.net.ServerSocket.accept (ServerSocket.java: 
> 421)
> [21:36:00.003]   at sun.rmi.transport.tcp.TCPTransport 
> $AcceptLoop.executeAcceptLoop (TCPTransport.java:369)
> [21:36:00.003]   at sun.rmi.transport.tcp.TCPTransport 
> $AcceptLoop.run (TCPTransport.java:341)
> [21:36:00.003]   at java.lang.Thread.run (Thread.java:619)
> [21:36:00.003]
> [21:36:00.003] "hmux-127.0.0.1:6802-105" id=1859 RUNNABLE (in native)
> [21:36:00.003]   at com.caucho.vfs.JniSocketImpl.readNative  
> (JniSocketImpl.java) (native)
> [21:36:00.003]   at com.caucho.vfs.JniSocketImpl.read  
> (JniSocketImpl.java:279)
> [21:36:00.003]   at com.caucho.vfs.JniStream.readTimeout  
> (JniStream.java:87)
> [21:36:00.003]   at com.caucho.vfs.ReadStream.fillWithTimeout  
> (ReadStream.java:982)
> [21:36:00.003]   at  
> com.caucho.server.port.TcpConnection.waitForKeepalive  
> (TcpConnection.java:208)
> [21:36:00.003]   at com.caucho.server.port.TcpConnection.run  
> (TcpConnection.java:691)
> [21:36:00.003]   at com.caucho.util.ThreadPool$Item.runTasks  
> (ThreadPool.java:721)
> [21:36:00.003]   at com.caucho.util.ThreadPool$Item.run  
> (ThreadPool.java:643)
> [21:36:00.003]   at java.lang.Thread.run (Thread.java:619)
> [21:36:00.003]
> [21:36:00.003] "hmux-127.0.0.1:6802-107" id=1881 RUNNABLE (in native)
> [21:36:00.003]   at com.caucho.vfs.JniServerSocketImpl.nativeAccept  
> (JniServerSocketImpl.java) (native)
> [21:36:00.003]   at com.caucho.vfs.JniServerSocketImpl.accept  
> (JniServerSocketImpl.java:199)
> [21:36:00.003]   at com.caucho.server.port.Port.accept (Port.java: 
> 1176)
> [21:36:00.003]   at com.caucho.server.port.TcpConnection.run  
> (TcpConnection.java:655)
> [21:36:00.003]   at com.caucho.util.ThreadPool$Item.runTasks  
> (ThreadPool.java:721)
> [21:36:00.003]   at com.caucho.util.ThreadPool$Item.run  
> (ThreadPool.java:643)
> [21:36:00.003]   at java.lang.Thread.run (Thread.java:619)
> [21:36:00.003]
> [21:36:00.003] "hmux-127.0.0.1:6802-108" id=1871 RUNNABLE (in native)
> [21:36:00.003]   at com.caucho.vfs.JniServerSocketImpl.nativeAccept  
> (JniServerSocketImpl.java) (native)
> [21:36:00.003]   at com.caucho.vfs.JniServerSocketImpl.accept  
> (JniServerSocketImpl.java:199)
> [21:36:00.003]   at com.caucho.server.port.Port.accept (Port.java: 
> 1176)
> [21:36:00.003]   at com.caucho.server.port.TcpConnection.run  
> (TcpConnection.java:655)
> [21:36:00.003]   at com.caucho.util.ThreadPool$Item.runTasks  
> (ThreadPool.java:721)
> [21:36:00.003]   at com.caucho.util.ThreadPool$Item.run  
> (ThreadPool.java:643)
> [21:36:00.003]   at java.lang.Thread.run (Thread.java:619)
> [21:36:00.003]
> [21:36:00.003] "hmux-127.0.0.1:6802-57" id=1897 RUNNABLE (in native)
> [21:36:00.003]   at com.caucho.vfs.JniServerSocketImpl.nativeAccept  
> (JniServerSocketImpl.java) (native)
> [21:36:00.003]   at com.caucho.vfs.JniServerSocketImpl.accept  
> (JniServerSocketImpl.java:199)
> [21:36:00.003]   

Re: [Resin-interest] srun vs server ?

[Scott Ferguson]

On Dec 11, 2008, at 7:42 AM, Vinny wrote:


Hello All,
Still working on my Apache/Resin issues and looking through the docs  
I found :


http://caucho.com/resin-3.1/doc/install-apache.xtp#Configuring%20resin.conf

In the wild I have seen both this:
 
  



and this:

 


which one is correct when using mod_caucho but not using a cluster?


They're equivalent.  The first one is the old, Resin 3.0 syntax for  
backward compatibility.


In Resin 3.1, every server belongs to a cluster because we want one  
unified deployment model, not a bunch of different cases.  If you have  
a single server, it belongs to a cluster with one server.  In previous  
versions, clustering was a feature, but now it's part of the  
architecture.


-- Scott



Tnanks





The future is here. It's just not widely distributed yet.
-William Gibson
___
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] Class loader issue finding resources in WEB-INF/lib .jar files

[Scott Ferguson]

On Dec 11, 2008, at 5:20 AM, Mike McNally wrote:

> Under Resin 3.1.6, I'm trying to get a Stripes-based project working.
> Stripes supports an auto-discovery mechanism whereby it searches the
> classpath for components that extend its functionality. I'm finding
> that when the mechanism tries to use the Resin
> "EnvironmentClassLoader" (which it plucks off the thread) to find
> resources, it cannot locate anything that's in a WEB-INF/lib jar file.
> It can find resources in the WEB-INF/classes directory however.

I've filed it at http://bugs.caucho.com/view.php?id=3150

Do you know what the exact string for the getResources argument is?   
There have been problems in the past related to things like "/foo" vs  
"foo".

-- Scott
>
>
> Is this some sort of configuration issue, in that I need to tell Resin
> to allow those jar files to be searched?
>
> (What's happening specifically is that the call to getResources() is
> returning an empty Enumeration.)
>
> -- 
> Turtle, turtle, on the ground,
> Pink and shiny, turn around.
>
>
> ___
> 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] Deployment question - mix of webserver- and war-style deployment

[Scott Ferguson]

On Dec 18, 2008, at 9:01 AM, Hari Selvarajan wrote:

> Following this message, I realized that a stray unzip had left the  
> empty
> equivalents of directory-a, directory-b and directory-c in webapps/.
> Resin was just doing what it was supposed to. Everything works as it
> should now.

Cool.  The best kind of issue :)

-- Scott

>
>
> - Hari
>
>  Original Message 
> Subject: Deployment question - mix of webserver- and war-style  
> deployment
> Date: Thu, 18 Dec 2008 15:45:44 +0530
> From: Hari Selvarajan 
> To: resin-interest@caucho.com
>
> Greetings,
>
> I'm trying to determine how to configure Resin 3.0 to do a mix of
> webserver-style and war-style deployment. This is the situation:
>
> We have some web applications, say a, b and c, which are all deployed
> war-style:
>
> webapps/a.war
> webapps/b.war
> webapps/c.war
>
> These web applications are a mixture of JSP pages, servlets and struts
> actions. There are no problems with these.
>
> We also have a set of JSP pages, organized by directory, under the  
> ROOT
> webapp:
>
> webapps/ROOT/1.jsp
> webapps/ROOT/directory-a/2.jsp
> webapps/ROOT/directory-a/3.jsp
> webapps/ROOT/directory-b/4.jsp
> webapps/ROOT/directory-c/5.jsp
>
> We expect these JSP pages to be accessible with the following URLs:
>
> http://somesite/directory-a/2.jsp
> http://somesite/directory-b/4.jsp
>
> etc.
>
> The JSP pages are organized by directory to improve the readability of
> the URL and to help with search engine categorization and rankings.
>
> However, I'm finding that, with the default configuration, resin
> complains that it can't find any of the files under
> webapps/ROOT/directory-a or directory-b or directory-c and returns a  
> 404
> status code for these pages. The JSP pages directly under ROOT (like
> 1.jsp) are served OK.
>
> After turning on finer logging, I found that this is because resin
> thinks that directory-a, directory-b and directory-c are web  
> application
> contexts, and should be served from the web applications directory-a,
> directory-b and directory-c. This is, of course, not the way that the
> web application has been laid out.
>
> Is there any way around this? The site structure has been created by  
> an
> Information Architect and I see sense in its organization, but I would
> like to preserve the directories under ROOT/ and not have to create a
> web application for every category. I've tried various configuration
> options and haven't been able to find a solution.
>
> Thanks for any pointers,
>
> Hari
>
>
>
> ___
> 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] manytoone only one field

[Scott Ferguson]

On Dec 18, 2008, at 1:18 AM, Riccardo Cohen wrote:

> Hello
> In the sample ManyToOne :
> http://caucho.com/resin/examples/amber-many2one/index.xtp I can see  
> how
> to get the corresponding bean in the other table, thanks to its  
> house id.
>
> Now as I transmit the object through hessian, I would like to retreive
> only the one field name (for instance the house name) and not the  
> whole
> object.
>
> Is it possible ?

You could try making the @Many2One field transient (which would stop  
Hessian from sending it.)

And then you could add a new field just for the house name and write  
the setHouse(House) to store the house name.  When Amber fills the  
house from the database, it will call setHouse, and you can store any  
field you like in a serializable field.

-- Scott

>
> Thanks
>
> -- 
> Riccardo Cohen
> Architecte du Logiciel
> http://www.architectedulogiciel.fr
> +33 (0)6.09.83.64.49
>
>
>
> ___
> 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] 304 Not Modified, Content-Length, and entity headers

[Scott Ferguson]

On Dec 19, 2008, at 2:55 AM, Илья Казначеев wrote:

> Hello *!
>
> For some reason, Resin 3.1, when responding with 304 due to
> sendError(SC_NOT_MODIFIED), is going to reply with the header
> Content-Length = zero:
>
> And, in fact, it broke our mod_accel, which responded to client with  
> 200 OK,
> Content-Length: 0, following with full body JFIF, and was  
> very surprised when
> client dropped connection.
>
> I understand that using mod_accel == DINOSAUR! in 2008, but still,  
> why does resin
> do that? There's a special section in resin/src/com/caucho/server/ 
> http/HttpResponse.java
> line 365:
>else if (statusCode == SC_NOT_MODIFIED || statusCode ==  
> SC_NO_CONTENT) {
>  hasContentLength = true;
>  os.write(_contentLengthBytes, 0, _contentLengthBytes.length);
>  os.print(0);
>
>  if (debug)
>log.fine(_request.dbgId() + "Content-Length: 0");
>}
> After I've commented that, front-end ceased malfunction and we  
> didn't see the problem.
>
> Still, is there a reason the above code is included? Maybe there's a  
> useful client which
> fails to work properly when it see 304 without content-length? Or  
> it's just a rudiment and
> can be removed?

I've removed that in the 4.0 tree.  It was added as part of a bug  
report for some clients that needed the content-length: 0.

-- Scott

>
>
> Thanks for suggestions!
>
>
>
> ___
> 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] re sin 3.1.8 comet keepalive problem

[Scott Ferguson]

On Dec 19, 2008, at 5:18 PM, bvu wrote:

>
> Hi,
>
> We upgraded from resin 3.1.6 to 3.1.8. We have an application that  
> use resin
> comet to push message to flash client. We implement a servlet that  
> extends
> resin GenericCometServlet. Both the service and resume methods in the
> servlet return true. Evertime a resume method is called, a message  
> is pushed
> to the output stream, CometController is closed and the method  
> return true
> so that the connection can be keep alive. We tested on the resin  
> 3.1.6 and
> the keepalive was working. When we did the same test on resin 3.1.8,  
> the
> keepalive is no longer work. We use Charles to capture the request and
> response from client and server. We saw the "Connection closed" in the
> response request header which mean that the keepalive is not enabled.
>
> Is there any way to enable keepalive for comet on resin 3.1.8?

No, but it does exist in 3.2.1.  The logic to make both comet and  
keepalives work isn't possible in the 3.1.x tree.

-- Scott

>
>
> Thanks,
>
> -- 
> View this message in context: 
> http://www.nabble.com/resin-3.1.8-comet-keepalive-problem-tp21100841p21100841.html
> Sent from the Resin mailing list archive at Nabble.com.
>
>
>
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest



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

Re: [Resin-interest] A config question about IIS ISAPI plugin

[Scott Ferguson]

On Dec 26, 2008, at 11:29 PM, wesley wrote:


Hi there,

I'm using IIS as the frontend contacting resin by isapi_srun.dll.
I've trouble to find the document about how to configure the params  
below:

   connect-timeout
   live-time
   dead-time
which /caucho-status servlet showed me.

The running value I saw in my webapp:
connect-timeout: 2
live-time: 10
dead-time: 20


These should be the following in the resin.xml
  
  
  
  

The isapi_srun.dll should pick up the values automatically from the  
backend.  I can't remember, though, if there have been fixes in the  
3.2 tree.  I think 3.1 is current on those issues.


-- Scott



The connect-timeout was too low to make IIS sometimes think the  
backend resin

could not be contacted as returns HTTP 5xx to client.

How could I configure these params in httpd.conf or anywhere?

BTW:
I know exactly how to configure timeout/pool/keepalive params for  
apache plugin.

I'm using Resin 3.1.7a.

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


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

[Resin-interest] Resin 4.0 snapshot

[Scott Ferguson]

I've just made an early Resin 4.0 snapshot available.  Resin 4.0 will  
take over from the 3.2 branch.

It will take a little longer than usual for the next 4.0.0 release for  
two main reasons.  First, there are significant, core changes to the  
configuration and also to the clustering (including distributed  
sessions.)  Second, based on feedback, we want to add any planned  
configuration changes in the 4.0.0 release, rather than updating  
different modules in 4.0.1, 4.0.2, etc.

The 4.0.x tree is tied to the JavaEE 6 specifications, so we won't  
have a final production version until after those specs are completed.

1. Configuration

The main configuration change in 4.0 is the new draft of the Web Beans  
specification, which changed the XML configuration dramatically, and  
allows for a more modular configuration style.  We've started  
migrating appropriate modules to the new style.  The planned modules  
will be: security, rewrite, cluster, remote, and JMS.

For example, the current snapshot includes the security changes.  (The  
old style will still exist for backward compatibility.)  To  
configuration an authenticator, you could write the following:

http://caucho.com/ns/resin";>
xmlns:security="urn:java:com.caucho.security">

   
 
   

   

   
 
   



(Note, the exact syntax is subject to the Web Bean specification,  
which is still in draft.)

2. Clustering

With 4.0, we will enable the addition/removal of dynamic servers to  
help manage load.  The visible changes should be minor, however, the  
internal changes are very large (and a major cause for 4.0.0 taking  
time.)

Specifically, the distributed sessions need a changed underlying model  
to properly handle the situation of server creation and removal.  The  
current session backup model assumes the set of servers is fixed.  The  
clustering changes also affect the load balancing, but in a less  
complicated fashion.

The new snapshot includes the session refactoring, but the load  
testing has been minimal.  In other words, the snapshot is suited for  
experimentation only, not for any kind of production.

-- Scott





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

Re: [Resin-interest] Railo/Resin/IIS6

[Scott Ferguson]

On Dec 29, 2008, at 3:41 PM, jqdur...@gmail.com wrote:

> I just typed a lengthy email but gmail ate it. I'll try to cut to  
> the point. :)
>
> I've just installed/configured Railo 3.0, Resin 3.1 and IIS6 to work  
> together but ran into a snag on an odd-ball scenario. Our users are  
> accustomed to typing "intranet" into their browser, pressing   
> and viewing the default document. IIS6 allowed us to use "intranet"  
> as a valid host name in the header, and therefore routed  
> accordingly. It seems that Resin doesn't allow us to do the same  
> thing?
>
>
> It's my understanding that I need to declare sites that route based  
> upon a host name in my resin.conf XML file. This is what I added...
>
> 
> intranet
> 
> 
>
> This results in a 404 error from IIS when attempting to access a  
> dynamic template (.CFM in this case). However, if I change the host  
> id to "intranet.foo", I'm able to retrieve .CFM templates (I'm  
> altering my HOSTS file so I'm hitting the same machine). It seems  
> that Resin requires an extension on the host? Is there a work-around  
> for this?

Resin itself doesn't care, it just treats the Host header as a  
string.  Can you check both /caucho-status and enable logging  
level="fine" on Resin?

The /caucho-status should show the host strings that isapi_srun is  
matching against.  The level="fine" logging will show the HTTP headers  
that Resin receives, and should help track down why it's not being  
matched.

-- Scott

>
>
> TIA
> Jason___
> 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 and Seam

[Scott Ferguson]

On Jan 2, 2009, at 4:54 PM, Daniel Hinojosa wrote:

> Never have used Resin. Can Seam 2.1.x applications run in Resin?  If  
> so, any docs?  I tried copying a seam .ear file in the webapps dir  
> to see what happens and I received no message.
> Any help or direction is appreciated.

The difficulty is really EJB 3.0 vs EJB-lite (EJB 3.1), because Seam  
uses EJB in all its examples.  (And EJB 3.0 doesn't define things like  
standard JNDI locations, which makes examples trickier.)

Our direction for Resin 4.0 is for EJB-lite, since we're focusing on  
the web profile.  (The rest of EJB has backward compatibility and  
CORBA.)So currently, we're stuck in between two specs.

-- Scott 



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

Re: [Resin-interest] implicit stack memory size?

[Scott Ferguson]

On Jan 8, 2009, at 5:23 PM, Rob Lockstone wrote:

> On Jan 8, 2009, at 13:52, Jay Ballinger wrote:
>
>> Hi everyone,
>>
>> We're running Resin 3.0.18 Pro on a Windows 32-bit system and we're
>> looking to understand/tune our memory settings a bit.
>>
>> According to http://www.caucho.com/resin-3.0/performance/jvm-tuning.xtp
>> the stack size is set to 2048k unless set otherwise. Is this true?
>> In using JConsole we can't see where any explicit -Xss setting is
>> passed and we can't readily determine what the current stack size is
>> set to.

Try -verbose when starting.  Since the -Xss is a command line option,  
it should be reported.  Also, JConsole should be able to see the  
command line options on one of the system beans.

> I think Caucho tends to err on the side of caution in this regard, and
> is also (understandably) more *nix-central than Windows. So take that
> 2048K as being "appropriate for most situations" with a grain of salt
> because situations can vary wildly.

Basically.  There's no way for us to know if your application needs  
more stack or more threads.  So I assumed 1G heap, leaving 1G for  
other stuff, and then figured the default should support 1000 threads,  
giving 1m as a default, which should be enough stack unless you have  
massively recursive applications, and enough threads for most apps.   
You know your own requirements best, of course.

I believe Linux is the most finicky about the stack allocation, so it  
was the OS we needed to solve (and it was the OS which exposed the  
issue first.)

I'm really looking forward for the 64-bit transition to complete so we  
can use as much VM as possible.

-- Scott


>
>
>> So, here's a short list of questions. And thanks for your help.
>>
>> - If JConsole doesn't show -Xss, is it really there for resin?
>
> Whether it's explicitly set or not, there IS a stack size, which would
> end up being the default stack size of the operating system if the JVM
> itself doesn't set it (I do not think it does, but could be wrong and
> don't feel like looking it up now).
>
>> - How was "2048k is an appropriate value for most situations."
>> determined?
>
> See above.
>
>> - Can resin/jvm/jconsole report the current stack memory setting?
>
> I don't know if there's a way to query a running JVM for this
> information. It's best if you explicitly set the stack size using the
> JVM option -Xss (but see below).
>
>> (general sun jvm on windows questions)
>> - What is the default stack memory size?
>
> That's too general of a question. It depends on the OS, and (perhaps)
> the version of the OS.
>
>> - When a thread is created, does it grab all of the stack memory, or
>> can the stack memory start small and grow to the default or -Xss  
>> size?
>
> Again, might depend on the operating system. Contrary to what Knut
> said, and to the best of my knowledge and in the testing that I did
> (it's been a while), all of the memory for the stack is pre-allocated
> (at least from the perspective of the JVM itself). But it's easy
> enough to write a program to check this.
>
> Thread stacks, at least on Windows, are more complicated than just a
> single memory allocation (down at the Windows API level) because
> you've got both reserved and committed memory allocations, and one
> always has to be >= the other (I forget which), and there's a 64K
> granularity in sizing, and you're dealing with physical and virtual
> memory, and this is all set in the linker and therefore configurable,
> but can also be set programmatically on a per-thread basis. In other
> words, it's quite involved. See this page as an example of how complex
> this kind of memory management is when you go into how the underlying
> OS is actually managing all of this 
> > .
>
> Remember, thread allocation/destruction as well as context switching
> and just about everything else is managed by the operating system, not
> Java (unless you're running "green" threads, which I don't think is
> even around anymore?). This is why the memory used by the thread's
> stack is not part of the Java heap. On a 32-bit machine, the maximum
> addressable space for an individual java program is 2G. So, for
> example, if you run java with these parameters on a 32-bit machine:
>
> java -server -Xms1500M -Xmx1500M -Xss1M
>
> then you'll leave enough room to run ~548 threads (2048M - 1500M =
> 548M / 1M stack = 548 threads). Of course, that assumes that none of
> the 548M of non-java-heap memory is being used for anything else,
> which is a false assumption, perhaps hugely false  depending on what
> your java program is doing, e.g. graphics operations or the like.
>
> Something I discovered while optimizing our Resin on Windows
> environments is that the version of Windows and Java we use (64-bit
> Windows 2003 Server with Java 1.5) will allow a minimum stack size of
> 128K, and if you try to specify a stack size of 256K or 512K, Windows
> (or maybe the JVM

Re: [Resin-interest] Memory leak - in Resin?

[Scott Ferguson]

On Jan 9, 2009, at 12:22 AM, Mattias Jiderhamn wrote:

> Scott Ferguson wrote (2008-11-26 16:53):
>>
>> Thanks.
>>
>> Right now, our code base is a bit stuck due to the WebBeans/OSGi
>> upgrade (for Resin 4.0.0, was 3.2.2).  Once that's cleaned up and I
>> can put up a snapshot I can take a look.
>
> Scott Ferguson wrote (2008-12-29 20:41):
>> I've just made an early Resin 4.0 snapshot available.
>
> Does this mean we can assume you will be able to look more closely at
> the memory leaks in 3.1 sometime soon...?

I was hoping you could verify the 4.0 memory fixes before looking at  
3.1  Because several of those changes were more involved than I'm  
comfortable with for 3.1, I'd prefer to make sure they work in 4.0  
first.

-- Scott

>
>
> /Mattias
>
>
>
>>
>> -- Scott
>>>
>>>
>>> Now, here are the things really bugging me:
>>> 1. If I keep redeploying over and over, I will eventually get closer
>>> and closer to the Perm Gen Max (in some instances, I have seen the
>>> following behaivour instead turn up when Used reaches Init if Init  
>>> is
>>> large enough). Then suddenly the unloadedClassCount is increased,  
>>> but
>>> not with all the unused classes - only about the amount of one
>>> redeployment. Redeploy again, and it will increase another step.
>>> Meanwhile, the loadedClassCount remains pretty stable, since we are
>>> loading as many new classes as are unloaded. It's as if there was a
>>> FIFO queue/LRU cache of classloaders, so that the oldest one is
>>> garbage collected once there is not enough space for a new one.
>>> However, after a while there is (assumably) not enough space to
>>> create the new classloader before the old one is garbage collected,
>>> and I get OutOfMemoryError somewhere in the middle. Sometimes I am
>>> actually able to recover from this error by waiting for the GC to do
>>> it's job and then just try again.
>>>
>>> 2. Now I attached YourKit, looking for dangling classloaders as of
>>> the inital post. I found none. In fact, the Classes without  
>>> Instances
>>> inspection only shows the classes in the added JARs from the last
>>> redeployment, so when tracing back to GC root, it goes via the
>>> current EnvironmentClassLoader which is correct. There are also no
>>> excessive instances of EnvironmentClassLoader. Hmm... Now wait a
>>> minute. Look at the total number of java.lang.Class objects. It does
>>> not match with the totalLoadedClassCount. In fact, the total number
>>> of classes found by YourKit is about the same as the
>>> totalLoadedClassCount on the very first hit of the application,
>>> before any redeployments. So from YourKits point of view, there is  
>>> no
>>> classloader leak! But why then isn't the PermGen space reclaimed.
>>> This led me to wonder if there was some kind of JVM bug. (As a side
>>> note, I have yet to try with some other profiler)
>>>
>>> 3. So, I modified the test application (see commented out code in
>>> MyServlet.java) to load the classes of the JARs in a regular
>>> java.net.URLClassLoader which is then immediately thrown away. No
>>> leak. loadedClassCount is immediately decreased (and
>>> unloadedClassCount increased), as is the Used Perm Gen. That is, it
>>> behave the way we want the redeployment to behave.
>>> Ok, lets take one step down in the classloader hierachy and load all
>>> the classes via a disposable com.caucho.loader.DynamicClassLoader.  
>>> No
>>> leak.
>>> So, what if I load them with a
>>> com.caucho.loader.EnvironmentClassLoader which is then destroy()ed
>>> and left for garbage collection. The leak is back!
>>> EnvironmentClassLoader has now applied to become prime suspect. In
>>> order to track things down I subclassed EnvironmentClassLoader  
>>> inside
>>> my application and planned to make changes there. Well ... before  
>>> any
>>> changes, the leak is nowhere to be found.
>>>
>>> What is going on here?
>>> Anything that might help my sanity would be appreciated.
>>>
>>> /Mattias Jiderhamn
>>>
>>>
>>> Mattias Jiderhamn wrote (2008-11-05 06:43):
>>>> In support of this latest theory is the fact that YourKit shows two
>>>> GC roots for the HttpRequest. Apart from the
>>>> com.caucho.server.port.TcpConnection._request reference, the  
>>&

Re: [Resin-interest] /caucho-status showing wrong version number

[Scott Ferguson]

On Jan 12, 2009, at 9:59 AM, Vinny wrote:

> When I look at the bottom of the page for our /caucho-status, it  
> says 3.1.6 when
> we are running 3.1.8. This is connected to apache via mod_caucho but  
> ps shows
> only resin 3.1.8 is running. Could it be a cacheing issue?

The version from /caucho-status comes from modules/src/c/common/ 
version.h (on unix), and is compiled in for Windows.

So, it looks like you're using the 3.1.6 mod_caucho.  (It's  
conceivable that we didn't update the version string, but it is an  
automatic process on unix.)

-- Scott

>
> Thanks,
> Vincent
>
>
>
>
> The future is here. It's just not widely distributed yet.
> -William Gibson
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest



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

[Resin-interest] Resin 4.0 clustering notes

[Scott Ferguson]

I've added some notes about our clustering direction for Resin 4.0 at 
http://blog.caucho.com/?p=120

The main capabilities that we want for 4.0 clustering are:

   1. dynamic servers (for load matching, and power savings)
   2. simplify the administration model

The main complexity of the current distributed session is that every  
server acts as a primary and a backup for some data.  So it's  
difficult or impossible for an administrator to know exactly what  
happens when a server goes down due to maintenance or a crash.

The new "triad" hub and spoke model simplifies that administration  
question.  All replication occurs on the triad hub servers.  So it's  
always safe to take down servers 4-64 at any time.  The 3 hub servers  
(servers 1-3) are critical, but administrators can take more care with  
them because it's only 3 servers, and they're known as being more  
important.

Those two requirements sound relatively simple, but imply a good deal  
of underlying infrastructure work. For example, distributed sessions  
since we no longer have the concept of an "owning" server, which means  
I need to add a temporary leasing concept that gives the same  
performance gains.

For users, the changes should be mostly invisible.  The first 3  
servers in a cluster automatically form the triad, and all the  
replication and session caching happens under the covers using the  
current API.  Single and dual servers work just like today.  In other  
words, we're not adding a minimum requirement of 3 servers.

-- Scott
  


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

Re: [Resin-interest] Quercus w/ Virtual Hosts

[Scott Ferguson]

On Jan 12, 2009, at 2:15 PM, Tim O'Donnell wrote:


Hi all,

I'm trying to get Quercus working on Resin 3.2.1 (open source) under  
virtual hosts. I can create PHP pages under the default host as  
defined in resin.xml, and they're interpreted and run just fine.  
However, if I create a new host, e.g.:



  


PHP is not interpreted for that host. Instead, resin returns the php  
code as plain text. I'm at a bit of a loss as to why. I'm probably  
missing something absurdly simple, but it's just escaping me at the  
moment. Can anyone clue me in?


Have you  deleted the  for the app-default.xml?  The app- 
default.xml contains the servlet definitions for Quercus.  (Inside  
 blocks.)


-- Scott



Thanks,

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


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

Re: [Resin-interest] a good ratio?

[Scott Ferguson]

On Jan 12, 2009, at 10:49 AM, Vinny wrote:

> httpd-2.2.3-11.el5_2.centos.4
> resin 3.1.8
>
> What should be a good ratio between external apache connections and  
> mod_caucho connections.
> Here is a sample  are seeing this like this from netstat:
>
> [netstat -tan |grep \:80 | grep EST |wc -l ;  netstat -tan |grep \: 
> 6802 | grep EST |wc -l
>
> (80:) 26
> (6802:)110
>
> Do the connection between apache httpd and resin count against  
> apache 's MaxClients config ?
> or resin's maximums in the server.xml?

"ratio" isn't the right way of thinking about it.  The detailed answer  
gets into how Apache spawns its processes and reuses them for  
following requests.

Basically, as long as the 6802 count is reasonably low (100-200ish) or  
a bit more for a heavy site, then you're fine.  The trouble starts  
when you have 1 TIME_WAIT connections or so.

-- Scott

>
>
> The future is here. It's just not widely distributed yet.
> -William Gibson
> ___
> 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 embedded issues

[Scott Ferguson]

On Jan 13, 2009, at 2:14 AM, Jan Kriesten wrote:

>
> Hi,
>
>> On a related note, the caucho maven repository seems to be lacking  
>> some
>> files, resin.jar 3.2.1 declares some files as dependencies that are  
>> not
>> there:
>
> sadly, that's true for most versions > 3.1.6 :-(
>
> I already reported that here on 2008/10/20 - but never got any  
> feedback on this.

bugs.caucho.com is really the best place to report these things.

At the moment, we're all tied up with the 4.0 logjam, so the bug  
squashing is slow.  That's important for 3.2.1 since 4.0.0 is the  
following release.  In other words, it makes more sense to make a 4.0  
snapshot usable and then fix bugs against it, rather than fixing bugs  
on an unusable snapshot.  But right now, it's a bit frustrating.

-- Scott

>
>
> Best regards, --- Jan.
>
>
>
>
> ___
> 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] Fwd: Issue getting JNI up and running

[Scott Ferguson]

On Jan 14, 2009, at 9:35 AM, jkowall wrote:



Sorry I had some issues getting on the mailinglist.

You can see the SO is compiled, but for some reason it cannot be  
loaded.  Any advice?


Can you add -verbose to the start?  That will show the LD_LIBRARY_PATH  
which should help track this down.


There might be information about that.  Also, make sure the Java 32 vs  
64 matches the compilation.


-- Scott




I am on Resin Pro.

[r...@x bin]# ./resin.sh start
Resin/3.2.1 can't start -server '' for watchdog at 127.0.0.1:6600.
com.caucho.config.ConfigException:  requires compiled  
JNI.  Check the $RESIN_HOME/libexec or $RESIN_HOME/libexec64  
directory for libresin_os.so.


[r...@x bin]# ls -la ../libexec/
total 180
drwxr-xr-x  2 root root   4096 Jan  2 19:38 .
drwxr-xr-x 20 root root   4096 Jan  6 19:48 ..
-rwxr-xr-x  1 root root 170308 Jan  3 00:11 libresin_os.so

--

-jk



--

-jk
___
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] Fwd: Issue getting JNI up and running

[Scott Ferguson]

On Jan 14, 2009, at 10:58 AM, Emil Ong wrote:

> On Wed, Jan 14, 2009 at 12:35:04PM -0500, jkowall wrote:
>>
>> Sorry I had some issues getting on the mailinglist.
>>
>> You can see the SO is compiled, but for some reason it cannot be  
>> loaded.  Any
>> advice?
>>
>> I am on Resin Pro.
>>
>> [r...@x bin]# ./resin.sh start
>> Resin/3.2.1 can't start -server '' for watchdog at 127.0.0.1:6600.
>> com.caucho.config.ConfigException:  requires compiled  
>> JNI.  Check
>> the $RESIN_HOME/libexec or $RESIN_HOME/libexec64 directory for  
>> libresin_os.so.
>>
>> [r...@x bin]# ls -la ../libexec/
>> total 180
>> drwxr-xr-x  2 root root   4096 Jan  2 19:38 .
>> drwxr-xr-x 20 root root   4096 Jan  6 19:48 ..
>> -rwxr-xr-x  1 root root 170308 Jan  3 00:11 libresin_os.so
>
> Hi,
>
> You're missing 2 SOs: libresin.so and libresinssl.so.  You'll need to
> recompile and/or check for compilation errors.

That's been changed in 3.2.1.  The  feature only requires  
libresin_os now.

-- Scott

>
>
> Emil
>
> 
>
> Emil Ong
> Chief Evangelist
> Caucho Technology, Inc.
> Tel. (858) 456-0300
> mailto:e...@caucho.com
> http://blog.caucho.com/
>
> Caucho: Reliable Open Source
> --> Resin: application server
> --> Quercus: PHP in Java
> --> BAM: lightweight high-speed messaging
>
>
> ___
> 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] Fwd: Issue getting JNI up and running

[Scott Ferguson]

On Jan 14, 2009, at 11:39 AM, jkowall wrote:

Thanks, here is the output from verbose.  It looks like the  
DYLD_LIBRARY_PATH is set, but not correct in LD_LIBRARY_PATH.   
Should I just change LD_LIBRARY_PATH to include the libexec64  
directory?


It looks like the ./configure process is compiling for 32 bits  
(libexec), but you're running in 64-bit mode (libexec64).


Try running ./configure --enable-64bit, and check for libexec64/ 
libresin_os.so


-- Scott




/usr/java/jdk1.6.0_11/bin/java \
  -Djava.util.logging.manager=com.caucho.log.LogManagerImpl \
  -Djava.system.class.loader=com.caucho.loader.SystemClassLoader \
  - 
Djavax 
.management.builder.initial=com.caucho.jmx.MBeanServerBuilderImpl \

  -Djava.awt.headless=true \
  -Dresin.home=/usr/resin/ \
  -d64 \
  -Xmx1024m \
  -Xss1m \
  -Xdebug \
  -Dcom.sun.management.jmxremote \
  com.caucho.server.resin.Resin \
  --root-directory \
  /usr/resin/ \
  -conf \
  /usr/resin/conf/resin.xml \
  -socketwait \
  57581 \
  -verbose
TERM: linux
DYLD_LIBRARY_PATH:
   /usr/resin/libexec64
SHLVL: 2
XFILESEARCHPATH: /usr/dt/app-defaults/%L/Dt
SSH_CLIENT: 192.168.1.51 59565 22
MAIL: /var/spool/mail/jkowall
PWD: /usr/resin/bin
HOSTNAME: gvahmfg02.gvah.mfgq.com
SSH_TTY: /dev/pts/1
LOGNAME: jkowall
CVS_RSH: ssh
G_BROKEN_FILENAMES: 1
NLSPATH: /usr/dt/lib/nls/msg/%L/%N.cat
LD_LIBRARY_PATH:
 /usr/resin/libexec64
 /usr/java/jdk1.6.0_11/jre/lib/amd64/server
 /usr/java/jdk1.6.0_11/jre/lib/amd64
 /usr/java/jdk1.6.0_11/jre/../lib/amd64
SSH_CONNECTION: 192.168.1.51 59565 10.10.50.72 22
INPUTRC: /etc/inputrc
SHELL: /bin/bash
HISTSIZE: 1000
CLASSPATH:
   /usr/resin//lib/resin.jar
   /usr/java/jdk1.6.0_11/lib/tools.jar
   /usr/resin/lib/pro.jar
   /usr/resin/lib/resin.jar
   /usr/resin/lib/jsf-12.jar
   /usr/resin/lib/webutil.jar
   /usr/resin/lib/activation.jar
   /usr/resin/lib/javamail-141.jar
   /usr/resin/lib/javaee-16.jar
   /usr/resin/lib/jaxstream-15.jar
   /usr/resin/lib/osgi-14.jar
PATH: /usr/resin/win64:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/ 
local/bin:/bin:/usr/bin:/home/jkowall/bin

USER: jkowall
HOME: /root
LESSOPEN: |/usr/bin/lesspipe.sh %s
LS_COLORS:  
no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=01;32:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.btm=01;32:*.bat=01;32:*.sh=01;32:*.csh=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tz=01;31:*.rpm=01;31:*.cpio=01;31:*.jpg=01;35:*.gif=01;35:*.bmp=01;35:*.xbm=01;35:*.xpm=01;35:*.png=01;35:*.tif=01;35:

SSH_ASKPASS: /usr/libexec/openssh/gnome-ssh-askpass
LANG: en_US.UTF-8

On Wed, Jan 14, 2009 at 2:05 PM, Scott Ferguson   
wrote:


On Jan 14, 2009, at 10:58 AM, Emil Ong wrote:

> On Wed, Jan 14, 2009 at 12:35:04PM -0500, jkowall wrote:
>>
>> Sorry I had some issues getting on the mailinglist.
>>
>> You can see the SO is compiled, but for some reason it cannot be
>> loaded.  Any
>> advice?
>>
>> I am on Resin Pro.
>>
>> [r...@x bin]# ./resin.sh start
>> Resin/3.2.1 can't start -server '' for watchdog at 127.0.0.1:6600.
>> com.caucho.config.ConfigException:  requires compiled
>> JNI.  Check
>> the $RESIN_HOME/libexec or $RESIN_HOME/libexec64 directory for
>> libresin_os.so.
>>
>> [r...@x bin]# ls -la ../libexec/
>> total 180
>> drwxr-xr-x  2 root root   4096 Jan  2 19:38 .
>> drwxr-xr-x 20 root root   4096 Jan  6 19:48 ..
>> -rwxr-xr-x  1 root root 170308 Jan  3 00:11 libresin_os.so
>
> Hi,
>
> You're missing 2 SOs: libresin.so and libresinssl.so.  You'll need  
to

> recompile and/or check for compilation errors.

That's been changed in 3.2.1.  The  feature only requires
libresin_os now.

-- Scott

>
>
> Emil
>
> 
>
> Emil Ong
> Chief Evangelist
> Caucho Technology, Inc.
> Tel. (858) 456-0300
> mailto:e...@caucho.com
> http://blog.caucho.com/
>
> Caucho: Reliable Open Source
> --> Resin: application server
> --> Quercus: PHP in Java
> --> BAM: lightweight high-speed messaging
>
>
> ___
> 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



--

-jk
___
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] Fwd: Issue getting JNI up and running

[Scott Ferguson]

On Jan 14, 2009, at 5:04 PM, jkowall wrote:

Thanks Scott, its been a while since we spoke.  I used to post here  
many years ago :)


Can you send the hs_err_pid4104.log?  I'm pretty sure we checked name> on the 64 bit systems.


-- Scott



The compile worked fine, but I got this error when I try to fire up  
resin.


[r...@gvahmfg02 bin]# ./resin.sh
#
# An unexpected error has been detected by Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x2aab0e81fba0, pid=4104, tid=1093785920
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (11.0-b16 mixed mode  
linux-amd64)

# Problematic frame:
# C  [libresin_os.so+0x7ba0]
#
# An error report file with more information is saved as:
# /usr/resin/bin/hs_err_pid4104.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
Aborted


On Wed, Jan 14, 2009 at 4:46 PM, Scott Ferguson   
wrote:


On Jan 14, 2009, at 11:39 AM, jkowall wrote:

Thanks, here is the output from verbose.  It looks like the  
DYLD_LIBRARY_PATH is set, but not correct in LD_LIBRARY_PATH.   
Should I just change LD_LIBRARY_PATH to include the libexec64  
directory?


It looks like the ./configure process is compiling for 32 bits  
(libexec), but you're running in 64-bit mode (libexec64).


Try running ./configure --enable-64bit, and check for libexec64/ 
libresin_os.so


-- Scott




/usr/java/jdk1.6.0_11/bin/java \
  -Djava.util.logging.manager=com.caucho.log.LogManagerImpl \
  -Djava.system.class.loader=com.caucho.loader.SystemClassLoader \
  - 
Djavax 
.management.builder.initial=com.caucho.jmx.MBeanServerBuilderImpl \

  -Djava.awt.headless=true \
  -Dresin.home=/usr/resin/ \
  -d64 \
  -Xmx1024m \
  -Xss1m \
  -Xdebug \
  -Dcom.sun.management.jmxremote \
  com.caucho.server.resin.Resin \
  --root-directory \
  /usr/resin/ \
  -conf \
  /usr/resin/conf/resin.xml \
  -socketwait \
  57581 \
  -verbose
TERM: linux
DYLD_LIBRARY_PATH:
   /usr/resin/libexec64
SHLVL: 2
XFILESEARCHPATH: /usr/dt/app-defaults/%L/Dt
SSH_CLIENT: 192.168.1.51 59565 22
MAIL: /var/spool/mail/jkowall
PWD: /usr/resin/bin
HOSTNAME: gvahmfg02.gvah.mfgq.com
SSH_TTY: /dev/pts/1
LOGNAME: jkowall
CVS_RSH: ssh
G_BROKEN_FILENAMES: 1
NLSPATH: /usr/dt/lib/nls/msg/%L/%N.cat
LD_LIBRARY_PATH:
 /usr/resin/libexec64
 /usr/java/jdk1.6.0_11/jre/lib/amd64/server
 /usr/java/jdk1.6.0_11/jre/lib/amd64
 /usr/java/jdk1.6.0_11/jre/../lib/amd64
SSH_CONNECTION: 192.168.1.51 59565 10.10.50.72 22
INPUTRC: /etc/inputrc
SHELL: /bin/bash
HISTSIZE: 1000
CLASSPATH:
   /usr/resin//lib/resin.jar
   /usr/java/jdk1.6.0_11/lib/tools.jar
   /usr/resin/lib/pro.jar
   /usr/resin/lib/resin.jar
   /usr/resin/lib/jsf-12.jar
   /usr/resin/lib/webutil.jar
   /usr/resin/lib/activation.jar
   /usr/resin/lib/javamail-141.jar
   /usr/resin/lib/javaee-16.jar
   /usr/resin/lib/jaxstream-15.jar
   /usr/resin/lib/osgi-14.jar
PATH: /usr/resin/win64:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/ 
local/bin:/bin:/usr/bin:/home/jkowall/bin

USER: jkowall
HOME: /root
LESSOPEN: |/usr/bin/lesspipe.sh %s
LS_COLORS:  
no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=01;32:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.btm=01;32:*.bat=01;32:*.sh=01;32:*.csh=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tz=01;31:*.rpm=01;31:*.cpio=01;31:*.jpg=01;35:*.gif=01;35:*.bmp=01;35:*.xbm=01;35:*.xpm=01;35:*.png=01;35:*.tif=01;35:

SSH_ASKPASS: /usr/libexec/openssh/gnome-ssh-askpass
LANG: en_US.UTF-8

On Wed, Jan 14, 2009 at 2:05 PM, Scott Ferguson   
wrote:


On Jan 14, 2009, at 10:58 AM, Emil Ong wrote:

> On Wed, Jan 14, 2009 at 12:35:04PM -0500, jkowall wrote:
>>
>> Sorry I had some issues getting on the mailinglist.
>>
>> You can see the SO is compiled, but for some reason it cannot be
>> loaded.  Any
>> advice?
>>
>> I am on Resin Pro.
>>
>> [r...@x bin]# ./resin.sh start
>> Resin/3.2.1 can't start -server '' for watchdog at 127.0.0.1:6600.
>> com.caucho.config.ConfigException:  requires compiled
>> JNI.  Check
>> the $RESIN_HOME/libexec or $RESIN_HOME/libexec64 directory for
>> libresin_os.so.
>>
>> [r...@x bin]# ls -la ../libexec/
>> total 180
>> drwxr-xr-x  2 root root   4096 Jan  2 19:38 .
>> drwxr-xr-x 20 root root   4096 Jan  6 19:48 ..
>> -rwxr-xr-x  1 root root 170308 Jan  3 00:11 libresin_os.so
>
> Hi,
>
> You're missing 2 SOs: libresin.so and libresinssl.so.  You'll  
need to

> recompile and/or check for compilation errors.

That's been changed in 3.2.1.  The  feature only requires
libresin_os now.

-- Scott

>
>
> Emi

Re: [Resin-interest] Hybernate & Resin 3.1.8

[Scott Ferguson]

On Jan 15, 2009, at 3:59 PM, Todd Sowers wrote:

> Hello -
>
> We are in the process of upgrading from Resin 3.0.22 to Resin 3.1.8.
> In our 3.0.22 environment Hibernate is working without issue.  With
> the upgrade to 3.1.8 we are experiencing the following issue that we
> know of.
>
> The mapping files are throwing error.  For example, in a one-to-one
> element, with in the mapping file, we have specified not-null="true".
> In 3.0.22 this works fine, in 3.1.8 this throws an error.

You may need to double check the XML, because the default XML parser  
changed from 3.0 to 3.1.  Resin 3.0 defaulted XML to its own XML  
parser.  Resin 3.1 uses the JDK's parser.

I'm not familiar with the Hibernate syntax, but it's possible that  
Resin's XML parser was either allowing some syntax or was providing  
defaults that the standard JDK parser isn't providing.

-- Scott

>
>
> Here is the error as displayed in the Resin console.
>
> [2009-01-13 16:35:14,146] ERROR XMLHelper:61
> org.hibernate.util.XMLHelper.error(..) - Error parsing XML: XML
> InputStream(14) Attribute "not-null" must be declared for element type
> "one-to-one".
> [2009-01-13 16:35:14,149] ERROR XMLHelper:61
> org.hibernate.util.XMLHelper.error(..) - Error parsing XML: XML
> InputStream(15) Attribute "lazy" with value "true" must have a value
> from the list "false proxy no-proxy ".
> [2009-01-13 16:35:14,158] ERROR XMLHelper:61
> org.hibernate.util.XMLHelper.error(..) - Error parsing XML: XML
> InputStream(28) Attribute "not-null" must be declared for element type
> "one-to-one".
>
> Any help would be greatly appreciated.  Specificly if you have any
> documentation on how to integrate Hibernate with 3.1.8 or what the
> mapping files should be written.
>
> Thanks
>
> Todd Sowers
>
>
> --
> Todd Sowers
> DList.com
> phone: 646-827-6766
> t...@dlist.com
> www.dlist.com
>
>
>
>
>
>
> ___
> 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] JMS Exceptions, 3.1.8

[Scott Ferguson]

On Jan 18, 2009, at 1:07 PM, tweihs wrote:

>
> We finally upgraded to 3.1.8! ("Hallelujah, holy s**t, where's the  
> tylenol" -
> Clark W. Griswald)
>
> The pain moving from 3.1.3, which we stuck ourselves on not knowing  
> it was a
> dev release, was intense (changed just about every tag, new super  
> classes
> for many of our objects, made the jump to configuring all our beans  
> via
> IoC), but it seems to be paying off (better production performance,  
> easier
> development using annotations, etc.).
>
> We're seeing the following exception in production now, though:

I've filed this as a bug, although I think we've already fixed it (it  
might need to be fixed back in 3.1.x)

>
>
> [21:00:07.701] {resin-21}  
> MessageConsumerImpl[FileQueue[executorQueue]]:
> message listener '_ejb.defaultexecutor.executor__...@149dd5b' failed  
> for
> message 'ObjectMessageImpl[ID:4U5naCkuy/cAEe3cHn/wAC]' with exception
> [21:00:07.701] {resin-21} java.lang.RuntimeException:
> java.lang.NullPointerException
> [21:00:07.701] {resin-21} java.lang.RuntimeException:
> java.lang.NullPointerException
> [21:00:07.701] {resin-21} at
> com.caucho.jms.connection.JmsSession.commit(JmsSession.java:1018)
> [21:00:07.701] {resin-21} at
> com.caucho.transaction.TransactionImpl.commit(TransactionImpl.java: 
> 658)
> [21:00:07.701] {resin-21} at
> com 
> .caucho 
> .transaction 
> .TransactionManagerImpl.commit(TransactionManagerImpl.java:271)
> [21:00:07.701] {resin-21} atmore
>
> We're using file queues for storage.  We're also seeing class cast
> exceptions occasionally when pulling the message objects out of the  
> queue,
> where Message.getObject() is returning a java.lang.Long (and we've  
> checked
> code to see that we're not injecting Longs).  Any ideas?

Do you know what the expected type is?  It's conceivable that a Byte  
is getting converted to a Long.

-- Scott

>
>
>
> -- 
> View this message in context: 
> http://www.nabble.com/JMS-Exceptions%2C-3.1.8-tp21532983p21532983.html
> Sent from the Resin mailing list archive at Nabble.com.
>
>
>
> ___
> 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] JMS Exceptions, 3.1.8

[Scott Ferguson]

On Jan 20, 2009, at 9:11 AM, Tyson Weihs wrote:

> The expected type is an instance of one of our serializable classes.

Hmm.  Is there any pattern when this happens?

> Fixing that back in 3.1.8/9 would be greatly appreciated.

Yep.  I'll check.

-- Scott

>
>
> On Tue, Jan 20, 2009 at 11:01 AM, Scott Ferguson   
> wrote:
>>
>> On Jan 18, 2009, at 1:07 PM, tweihs wrote:
>>
>>>
>>> We finally upgraded to 3.1.8! ("Hallelujah, holy s**t, where's the
>>> tylenol" -
>>> Clark W. Griswald)
>>>
>>> The pain moving from 3.1.3, which we stuck ourselves on not knowing
>>> it was a
>>> dev release, was intense (changed just about every tag, new super
>>> classes
>>> for many of our objects, made the jump to configuring all our beans
>>> via
>>> IoC), but it seems to be paying off (better production performance,
>>> easier
>>> development using annotations, etc.).
>>>
>>> We're seeing the following exception in production now, though:
>>
>> I've filed this as a bug, although I think we've already fixed it (it
>> might need to be fixed back in 3.1.x)
>>
>>>
>>>
>>> [21:00:07.701] {resin-21}
>>> MessageConsumerImpl[FileQueue[executorQueue]]:
>>> message listener '_ejb.defaultexecutor.executor__...@149dd5b' failed
>>> for
>>> message 'ObjectMessageImpl[ID:4U5naCkuy/cAEe3cHn/wAC]' with  
>>> exception
>>> [21:00:07.701] {resin-21} java.lang.RuntimeException:
>>> java.lang.NullPointerException
>>> [21:00:07.701] {resin-21} java.lang.RuntimeException:
>>> java.lang.NullPointerException
>>> [21:00:07.701] {resin-21} at
>>> com.caucho.jms.connection.JmsSession.commit(JmsSession.java:1018)
>>> [21:00:07.701] {resin-21} at
>>> com.caucho.transaction.TransactionImpl.commit(TransactionImpl.java:
>>> 658)
>>> [21:00:07.701] {resin-21} at
>>> com
>>> .caucho
>>> .transaction
>>> .TransactionManagerImpl.commit(TransactionManagerImpl.java:271)
>>> [21:00:07.701] {resin-21} atmore
>>>
>>> We're using file queues for storage.  We're also seeing class cast
>>> exceptions occasionally when pulling the message objects out of the
>>> queue,
>>> where Message.getObject() is returning a java.lang.Long (and we've
>>> checked
>>> code to see that we're not injecting Longs).  Any ideas?
>>
>> Do you know what the expected type is?  It's conceivable that a Byte
>> is getting converted to a Long.
>>
>> -- Scott
>>
>>>
>>>
>>>
>>> --
>>> View this message in context: 
>>> http://www.nabble.com/JMS-Exceptions%2C-3.1.8-tp21532983p21532983.html
>>> Sent from the Resin mailing list archive at Nabble.com.
>>>
>>>
>>>
>>> ___
>>> 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] Fwd: Issue getting JNI up and running

[Scott Ferguson]

On Jan 20, 2009, at 9:37 AM, jkowall wrote:


Scott, do you have any update on the bug?


The attachment didn't come through (might have been too big?)

I just checked on my ubuntu amd64 system for 3.2.1 and it started  
correctly with .  Can you disable the , start  
Resin and send the part that looks like the following:


[10:29:10.559] {main}
[10:29:10.559] {main} Linux 2.6.24-16-generic i386
[10:29:10.560] {main} Java(TM) SE Runtime Environment 1.6.0_01-b06,  
UTF-8, en
[10:29:10.560] {main} Java HotSpot(TM) Client VM 1.6.0_01-b06, 32,  
mixed mode, sharing, Sun Microsystems Inc.

[10:29:10.560] {main}
[10:29:10.560] {main} resin.home = /home/ferg/ws/test-resin/
[10:29:10.560] {main} resin.root = /home/ferg/ws/test-resin/
[10:29:10.560] {main} resin.conf = /home/ferg/ws/test-resin/conf/ 
resin.xml

[10:29:10.561] {main}
[10:29:10.561] {main} server = 127.0.0.1:6800 (app-tier:)
[10:29:10.561] {main} user.name  = ferg
[10:29:10.561] {main}

(The first three lines are the important ones.)

-- Scott




On Thu, Jan 15, 2009 at 3:44 PM, jkowall  wrote:
Please see attached file.

Thanks.


On Thu, Jan 15, 2009 at 3:36 PM, Scott Ferguson   
wrote:


On Jan 14, 2009, at 5:04 PM, jkowall wrote:

Thanks Scott, its been a while since we spoke.  I used to post here  
many years ago :)


Can you send the hs_err_pid4104.log?  I'm pretty sure we checked  
 on the 64 bit systems.


-- Scott



The compile worked fine, but I got this error when I try to fire up  
resin.


[r...@gvahmfg02 bin]# ./resin.sh
#
# An unexpected error has been detected by Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x2aab0e81fba0, pid=4104, tid=1093785920
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (11.0-b16 mixed mode  
linux-amd64)

# Problematic frame:
# C  [libresin_os.so+0x7ba0]
#
# An error report file with more information is saved as:
# /usr/resin/bin/hs_err_pid4104.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
Aborted


On Wed, Jan 14, 2009 at 4:46 PM, Scott Ferguson   
wrote:


On Jan 14, 2009, at 11:39 AM, jkowall wrote:

Thanks, here is the output from verbose.  It looks like the  
DYLD_LIBRARY_PATH is set, but not correct in LD_LIBRARY_PATH.   
Should I just change LD_LIBRARY_PATH to include the libexec64  
directory?


It looks like the ./configure process is compiling for 32 bits  
(libexec), but you're running in 64-bit mode (libexec64).


Try running ./configure --enable-64bit, and check for libexec64/ 
libresin_os.so


-- Scott




/usr/java/jdk1.6.0_11/bin/java \
  -Djava.util.logging.manager=com.caucho.log.LogManagerImpl \
  -Djava.system.class.loader=com.caucho.loader.SystemClassLoader \
  - 
Djavax 
.management.builder.initial=com.caucho.jmx.MBeanServerBuilderImpl \

  -Djava.awt.headless=true \
  -Dresin.home=/usr/resin/ \
  -d64 \
  -Xmx1024m \
  -Xss1m \
  -Xdebug \
  -Dcom.sun.management.jmxremote \
  com.caucho.server.resin.Resin \
  --root-directory \
  /usr/resin/ \
  -conf \
  /usr/resin/conf/resin.xml \
  -socketwait \
  57581 \
  -verbose
TERM: linux
DYLD_LIBRARY_PATH:
   /usr/resin/libexec64
SHLVL: 2
XFILESEARCHPATH: /usr/dt/app-defaults/%L/Dt
SSH_CLIENT: 192.168.1.51 59565 22
MAIL: /var/spool/mail/jkowall
PWD: /usr/resin/bin
HOSTNAME: gvahmfg02.gvah.mfgq.com
SSH_TTY: /dev/pts/1
LOGNAME: jkowall
CVS_RSH: ssh
G_BROKEN_FILENAMES: 1
NLSPATH: /usr/dt/lib/nls/msg/%L/%N.cat
LD_LIBRARY_PATH:
 /usr/resin/libexec64
 /usr/java/jdk1.6.0_11/jre/lib/amd64/server
 /usr/java/jdk1.6.0_11/jre/lib/amd64
 /usr/java/jdk1.6.0_11/jre/../lib/amd64
SSH_CONNECTION: 192.168.1.51 59565 10.10.50.72 22
INPUTRC: /etc/inputrc
SHELL: /bin/bash
HISTSIZE: 1000
CLASSPATH:
   /usr/resin//lib/resin.jar
   /usr/java/jdk1.6.0_11/lib/tools.jar
   /usr/resin/lib/pro.jar
   /usr/resin/lib/resin.jar
   /usr/resin/lib/jsf-12.jar
   /usr/resin/lib/webutil.jar
   /usr/resin/lib/activation.jar
   /usr/resin/lib/javamail-141.jar
   /usr/resin/lib/javaee-16.jar
   /usr/resin/lib/jaxstream-15.jar
   /usr/resin/lib/osgi-14.jar
PATH: /usr/resin/win64:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/ 
local/bin:/bin:/usr/bin:/home/jkowall/bin

USER: jkowall
HOME: /root
LESSOPEN: |/usr/bin/lesspipe.sh %s
LS_COLORS:  
no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=01;32:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.btm=01;32:*.bat=01;32:*.sh=01;32:*.csh=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tz=01;31:*.rpm=01;31:*.cpio=01;31:*.jpg=01;35:*.gif=01;35:*.bmp=01;35:*.xbm=01;35:*.xpm=01;35:*.png=01;35:*.tif=01;35:

SSH_ASKPASS: /usr/libexec/openssh/gnome-ssh-askpass
LANG: en_US.UTF-8

On Wed, Jan 14, 2009 at 2:05 PM, Scott Ferguson   
wrote:


On Jan 14, 2009, at

Re: [Resin-interest] Fwd: Issue getting JNI up and running

[Scott Ferguson]

On Jan 20, 2009, at 12:06 PM, jkowall wrote:


It was only 19k.

I commented out those two lines, and I'm still getting an abort:


Can you either cut-and-paste or send the attachment to me directly?   
thanks,


-- Scott




[r...@gvahmfg02 bin]# ./resin.sh --verbose
#
# An unexpected error has been detected by Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x2aab0e93fba0, pid=28483, tid=1095792960
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (11.0-b16 mixed mode  
linux-amd64)

# Problematic frame:
# C  [libresin_os.so+0x7ba0]
#
# An error report file with more information is saved as:
# /usr/resin/bin/hs_err_pid28483.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
Aborted


On Tue, Jan 20, 2009 at 1:21 PM, Scott Ferguson   
wrote:


On Jan 20, 2009, at 9:37 AM, jkowall wrote:


Scott, do you have any update on the bug?


The attachment didn't come through (might have been too big?)

I just checked on my ubuntu amd64 system for 3.2.1 and it started  
correctly with .  Can you disable the , start  
Resin and send the part that looks like the following:


[10:29:10.559] {main}
[10:29:10.559] {main} Linux 2.6.24-16-generic i386
[10:29:10.560] {main} Java(TM) SE Runtime Environment 1.6.0_01-b06,  
UTF-8, en
[10:29:10.560] {main} Java HotSpot(TM) Client VM 1.6.0_01-b06, 32,  
mixed mode, sharing, Sun Microsystems Inc.

[10:29:10.560] {main}
[10:29:10.560] {main} resin.home = /home/ferg/ws/test-resin/
[10:29:10.560] {main} resin.root = /home/ferg/ws/test-resin/
[10:29:10.560] {main} resin.conf = /home/ferg/ws/test-resin/conf/ 
resin.xml

[10:29:10.561] {main}
[10:29:10.561] {main} server = 127.0.0.1:6800 (app-tier:)
[10:29:10.561] {main} user.name  = ferg
[10:29:10.561] {main}

(The first three lines are the important ones.)

-- Scott




On Thu, Jan 15, 2009 at 3:44 PM, jkowall  wrote:
Please see attached file.

Thanks.


On Thu, Jan 15, 2009 at 3:36 PM, Scott Ferguson   
wrote:


On Jan 14, 2009, at 5:04 PM, jkowall wrote:

Thanks Scott, its been a while since we spoke.  I used to post  
here many years ago :)


Can you send the hs_err_pid4104.log?  I'm pretty sure we checked  
 on the 64 bit systems.


-- Scott



The compile worked fine, but I got this error when I try to fire  
up resin.


[r...@gvahmfg02 bin]# ./resin.sh
#
# An unexpected error has been detected by Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x2aab0e81fba0, pid=4104, tid=1093785920
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (11.0-b16 mixed mode  
linux-amd64)

# Problematic frame:
# C  [libresin_os.so+0x7ba0]
#
# An error report file with more information is saved as:
# /usr/resin/bin/hs_err_pid4104.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
Aborted


On Wed, Jan 14, 2009 at 4:46 PM, Scott Ferguson   
wrote:


On Jan 14, 2009, at 11:39 AM, jkowall wrote:

Thanks, here is the output from verbose.  It looks like the  
DYLD_LIBRARY_PATH is set, but not correct in LD_LIBRARY_PATH.   
Should I just change LD_LIBRARY_PATH to include the libexec64  
directory?


It looks like the ./configure process is compiling for 32 bits  
(libexec), but you're running in 64-bit mode (libexec64).


Try running ./configure --enable-64bit, and check for libexec64/ 
libresin_os.so


-- Scott




/usr/java/jdk1.6.0_11/bin/java \
  -Djava.util.logging.manager=com.caucho.log.LogManagerImpl \
  -Djava.system.class.loader=com.caucho.loader.SystemClassLoader \
  - 
Djavax 
.management.builder.initial=com.caucho.jmx.MBeanServerBuilderImpl \

  -Djava.awt.headless=true \
  -Dresin.home=/usr/resin/ \
  -d64 \
  -Xmx1024m \
  -Xss1m \
  -Xdebug \
  -Dcom.sun.management.jmxremote \
  com.caucho.server.resin.Resin \
  --root-directory \
  /usr/resin/ \
  -conf \
  /usr/resin/conf/resin.xml \
  -socketwait \
  57581 \
  -verbose
TERM: linux
DYLD_LIBRARY_PATH:
   /usr/resin/libexec64
SHLVL: 2
XFILESEARCHPATH: /usr/dt/app-defaults/%L/Dt
SSH_CLIENT: 192.168.1.51 59565 22
MAIL: /var/spool/mail/jkowall
PWD: /usr/resin/bin
HOSTNAME: gvahmfg02.gvah.mfgq.com
SSH_TTY: /dev/pts/1
LOGNAME: jkowall
CVS_RSH: ssh
G_BROKEN_FILENAMES: 1
NLSPATH: /usr/dt/lib/nls/msg/%L/%N.cat
LD_LIBRARY_PATH:
 /usr/resin/libexec64
 /usr/java/jdk1.6.0_11/jre/lib/amd64/server
 /usr/java/jdk1.6.0_11/jre/lib/amd64
 /usr/java/jdk1.6.0_11/jre/../lib/amd64
SSH_CONNECTION: 192.168.1.51 59565 10.10.50.72 22
INPUTRC: /etc/inputrc
SHELL: /bin/bash
HISTSIZE: 1000
CLASSPATH:
   /usr/resin//lib/resin.jar
   /usr/java/jdk1.6.0_11/lib/tools.jar
   /usr/resin/lib/pro.jar
   /usr/resin/lib/resin.jar
   /usr/resin/lib/jsf-12.jar
   /usr/resin/lib/webutil.jar
   /usr/resin/lib/activation.jar
   /usr/resin/lib/javamail-141.jar
   /usr/resin/lib/javaee-16.jar
   /usr/resin/

Re: [Resin-interest] Comet implementation details

[Scott Ferguson]

On Jan 20, 2009, at 11:38 AM, Caleb Richardson wrote:

> We're considering using Resin's comet implementation in an HTTP idle
> scenario (probably 30 minute wait period), where an HTTP client  
> creates
> a connection and then waits up to 30 minutes for a response.

Hmm.  I think that's true.  I've added a bug report at 
http://bugs.caucho.com/view.php?id=3294 
.

We may need to redesign the comet support for Servlet 3.0 (Resin 4.0),  
so that issue may be part of that design.

-- Scott

>
>
> I understand that one of the idle connections takes up a socket on the
> server but not a thread. However, does this mean that the server will
> never receive a close event from the client (since nothing is blocking
> on read)? If this is the case, then any background worker threads
> (spawned by me) responsible for calling CometController#wake will
> continue to work on behalf of that connection until the wait period  
> is up.
>
> Is my understanding correct?
>
> Thanks,
>
> Caleb Richardson
>
>
>
> ___
> 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] Which version?

[Scott Ferguson]

On Jan 25, 2009, at 7:01 AM, Stargazer wrote:

> The resin downloads page currently has 3.2.1 (dev), 3.1.8 (stable) and
> 4.0 (snapshot).
> I understand 3.1.8 is the stable version so what is the point of 3.2.1
> now 4.0 is present?

> Will the 3.2.x line ever get to stable before 4.0 is released?

It's obsolete. You can either think of 3.2.x as a dead end, or as an  
early beta of 4.0.

> Which would you use for best Quercus performance? If bugs are fixed in
> Quercus, and applied to the 3.2.x line, are they to be fixed in future
> 3.1.x stable releases?

For Quercus, you really need to use the latest version, because the  
number of bug fixes and new functions is so large.

-- 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] Which version?

[Scott Ferguson]

On Jan 25, 2009, at 2:10 PM, Stargazer wrote:

> Scott Ferguson wrote:
>> On Jan 25, 2009, at 7:01 AM, Stargazer wrote:
>>
>>
>>> Which would you use for best Quercus performance? If bugs are  
>>> fixed in
>>> Quercus, and applied to the 3.2.x line, are they to be fixed in  
>>> future
>>> 3.1.x stable releases?
>>>
>>
>>
> Ok so theres a dilemma here. We know 4.0 won't be stable until at  
> least
> the summer, but you don't advise anyone to use anything other than
> stable in production environments. It seems a waste to see all these
> Quercus fixes but never really be able to use them for 6 months.
> Couldn't you consider one last stable 3.2.x release, with these latest
> Quercus fixes, just for this reason?

It's not really possible either from a code-management standpoint or  
from a time standpoint.  We're not going to delay 4.0 just to put in  
Quercus fixes in an older development release (and 3.2.x was always a  
development branch; the stable branch is 3.1.x).

-- Scott

>
>> For Quercus, you really need to use the latest version, because the
>> number of bug fixes and new functions is so large.
>>
>> -- 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
>>
>> 
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - http://www.avg.com
>> Version: 8.0.176 / Virus Database: 270.10.13/1914 - Release Date:  
>> 24/01/2009 20:40
>>
>>
>
>
>
>
> ___
> 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] Webbeans is dead

[Scott Ferguson]

On Jan 28, 2009, at 12:08 AM, Stargazer wrote:

> http://blogs.sun.com/theaquarium/entry/jsr_299_webbeans_is_dead?intcmp=2223
>
> No wonder you guys have such a hard time keeping up!

WebBeans is dead.  Long live Java CanDI!  (Contexts and Dependency  
Injection)

Yeah, I spent the whole weekend refactoring our implementation to deal  
with the new packaging, and put up a Resin 4.0 snapshot yesterday.

The changes are good though.  Basic summary:

   javax.inject - core injection annotations like the @BindingType,  
@Current, etc.
   javax.inject.manager - programmatic access to Java injection
   javax.context - context/scope stuff like ApplicationScoped,  
RequestScoped, SessionScoped
   javax.event - all the event firing stuff
   javax.interceptor - Interceptors (now completely shared with EJB)
   javax.decorator - Decorators (also complete shared with EJB)
   javax.annotation - @Named, @Stereotype moved here

It's all logical, but I'm amazed they got permission to create that  
many top-level packages.

The config namespace and beans.xml location changed too (causing all  
tests to fail, plus lots of core Resin tests):

META-INF/beans.xml

   



   

The urn:java:ee can now import multiple packages (with a ee/namespace  
file).  So urn:java:ee automatically imports javax.injection,  
java.lang(!), java.util(!), javax.context, etc.

-- Scott

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



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

Re: [Resin-interest] Quercus with Joomla and Apache mod_rewrite

[Scott Ferguson]

On Feb 2, 2009, at 1:51 AM, Stargazer wrote:

> I'm trying to move an existing Joomla site to Quercus. On the current
> system I have set "search engine friendly URLs" on and this strips the
> ugly params out. I guess its handled by Apache using a module or the
> .htaccess file. In any case, when I run the same setup under Quercus
> (again with the Apache + mod_caucho setup) it seems these URL's don't
> get converted, so the site right now is full of broken links. Its a
> shame because some pages do work, and the content is there meaning the
> db is ok, the compilation and cache is ok and it runs 3x faster ;-) So
> any tips on how I can get Resin + Quercus to do what the current setup
> is doing with respect to these URL rewrites please?

You should use Resin's  rules.  There's an example  
at http://wiki.caucho.com/Rewrite-dispatch_for_Mediawiki_and_Quercus.   
The full docs are at http://caucho.com/resin/rewrite.xtp

   http://caucho.com/resin/doc/rewrite-tags.xtp

If you can post Joomla's recommended mod_rewrite rules, we can help  
convert them to .

-- Scott

>
>
> Resin 3.2.1 Pro / RH Fed7
>
>
>
> ___
> 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] is unknow bean property of

[Scott Ferguson]

On Feb 2, 2009, at 8:45 AM, Jay Ballinger wrote:

> Tuan,
>
> Did you try ${object.price} ?
>
> We also found Resin 3.1.x to be more specific than 3.0.x about the
> conventions used with EL. We made a pass through our code looking for
> these capitalization differences and that solved our problems.

Exactly.  Resin 3.1 is more strict than 3.0 for EL behavior (because  
it's based on a newer version of the EL spec.)

-- Scott

>
>
> + jay
>
>
>
> Tuan Tran wrote:
>> Hi all!
>>
>>
>>
>> We are having a lot of “javax.el.PropertyNotFoundException” when
>> updating from version 3.0 to 3.1.8.
>>
>>
>>
>> An example:
>>
>>
>>
>> JSP-files with code like this ${object.Price} will give an error like
>> this one :
>>
>>
>>
>> 500 ‘Price’ is an unknown bean property of
>>
>>
>>
>> The only thing that seems to fix this is to change it to
>>
>>
>>
>> ${object.getPrice()}.
>>
>>
>>
>> The problem is that we have alot of jsp files to be changed, just
>> wondering if there is an easy way to fix this?
>>
>>
>>
>> Thanks!
>>
>>
>>
>> Tuan Tran
>>
>>
>>
>>
>>
>>
>>
>>
>> 
>>
>> ___
>> 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] is unknow bean property of

[Scott Ferguson]

On Feb 3, 2009, at 1:30 PM, Ethan Eldridge wrote:

> Does Resin 3.1.x have a 'backwards-compatibility' mode so that it's
> possible to upgrade from 3.0.x to 3.1.x without making the EL  
> changes in
> the JSP files?  We looked for such a setting and didn't see anything.
>
> In other words, do you need to fix the JSP files in order to upgrade
> from 3.0.x to 3.1.x, or is there another (lazy but less risky) way?

Unfortunately, that's not possible because of the way that EL is  
designed.

The javax.el handlers themselves are doing the validation, not Resin  
classes, and the handlers can't be changed because their behavior is  
defined by the EL specification.  So we're stuck.

-- Scott

>
>
> Ethan
>
> -Original Message-
> From: resin-interest-boun...@caucho.com
> [mailto:resin-interest-boun...@caucho.com] On Behalf Of Scott Ferguson
> Sent: Monday, February 02, 2009 8:53 AM
> To: General Discussion for the Resin application server
> Subject: Re: [Resin-interest] is unknow bean property of
>
>
>
> On Feb 2, 2009, at 8:45 AM, Jay Ballinger wrote:
>
>> Tuan,
>>
>> Did you try ${object.price} ?
>>
>> We also found Resin 3.1.x to be more specific than 3.0.x about the
>> conventions used with EL. We made a pass through our code looking for
>> these capitalization differences and that solved our problems.
>
> Exactly.  Resin 3.1 is more strict than 3.0 for EL behavior (because
> it's based on a newer version of the EL spec.)
>
> -- Scott
>
>>
>>
>> + jay
>>
>>
>>
>> Tuan Tran wrote:
>>> Hi all!
>>>
>>>
>>>
>>> We are having a lot of "javax.el.PropertyNotFoundException" when
>>> updating from version 3.0 to 3.1.8.
>>>
>>>
>>>
>>> An example:
>>>
>>>
>>>
>>> JSP-files with code like this ${object.Price} will give an error  
>>> like
>>> this one :
>>>
>>>
>>>
>>> 500 'Price' is an unknown bean property of
>>>
>>>
>>>
>>> The only thing that seems to fix this is to change it to
>>>
>>>
>>>
>>> ${object.getPrice()}.
>>>
>>>
>>>
>>> The problem is that we have alot of jsp files to be changed, just
>>> wondering if there is an easy way to fix this?
>>>
>>>
>>>
>>> Thanks!
>>>
>>>
>>>
>>> Tuan Tran
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
> 
>>>
>>> ___
>>> resin-interest mailing list
>>> resin-interest@caucho.com
>>> http://maillist.caucho.com/mailman/listinfo/resin-interest
>>
>>
>> ___
>> resin-interest mailing list
>> resin-interest@caucho.com
>> http://maillist.caucho.com/mailman/listinfo/resin-interest
>
>
>
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest
>
>
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest



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

Re: [Resin-interest] Question about the Comet demo

[Scott Ferguson]

On Feb 4, 2009, at 1:32 PM, Aaron Freeman wrote:

> I know these are simpleton questions but I gotta ask 'em. ;)
>
> In the Comet demo on:
> http://www.caucho.com/resin-3.1/examples/servlet-comet/ , the IFRAME  
> is
> referencing SRC="comet".  I looked in the example resin.conf and
> web-beans.xml but I don't see how and/or what that "comet" call is  
> mapping
> to?  It's obviously connecting to TestCometServlet somehow, but I  
> just can't
> figure out how it knows that.

It should be the servlet-mapping for the actual comet servlet in resin- 
web.xml.

> Also, when I call
> http://www.caucho.com/resin-3.1/examples/servlet-comet/comet  
> directly, in
> order to see the "raw" output from TestCometServlet, I notice it has  
> a nice
> pretty comment block in order to make sure the data gets rendered by  
> IE, due
> to IE's needing to see some amount of bytes before it inteprets a  
> page.

Technically, I think it's Safari that has the problem.  I think IE's  
okay.

> That's not in the example code (understandably), and I am wondering  
> if it's
> better to put that type of logic in a filter or just include it in the
> CometServlet?

I'd put it in the comet servlet, because it's just a buffer of 1024  
bytes at the very beginning, and the comet servlet is a good place to  
put that logic.

Filters are a bit weird with comet, conceptually, because filters  
really expect a simple, single response instead of the comet repeated  
calls.

-- Scott

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



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

Re: [Resin-interest] Quercus with Joomla and Apache mod_rewrite

[Scott Ferguson]

On Feb 4, 2009, at 3:40 PM, Stargazer wrote:

>

>
> ## Begin - Joomla! core SEF Section
> #
> RewriteCond %{REQUEST_FILENAME} !-f
> RewriteCond %{REQUEST_FILENAME} !-d
> RewriteCond %{REQUEST_URI} !^/index.php
> RewriteCond %{REQUEST_URI}
> (/|\.php|\.html|\.htm|\.feed|\.pdf|\.raw|/[^.]*)$  [NC]
> RewriteRule (.*) index.php
> RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]

I believe this part should look something like:


   
   


In other words, anything ending with the specific endings are passed  
through as normal.  Anything else is appended to /index.php.

-- Scott

>
> #
> ## End - Joomla! core SEF Section
>
>
>>> Resin 3.2.1 Pro / RH Fed7
>>>
>>>
>>>
>>> ___
>>> 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
>>
>> 
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 8.0.233 / Virus Database: 270.10.16/1930 - Release Date:  
>> 01/31/09 20:03:00
>>
>>
>
>
>
>
> ___
> 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] Different MD5-base64 digest passwords Resin 2.1 vs. Resin 3.1 with realm of none

[Scott Ferguson]

On Feb 6, 2009, at 8:15 AM, BUSCH Steffen wrote:

> Hi all,
>
> I have a small Issue while trying to prepare the upgrade from Resin
> 2.1.14 to Resin 3.1 Snapshot as of 19th December with the Digest
> Password in Resin XmlAuthenticator.

2.1.14 had an incorrect implementation of base64 encoding.

Is it possible to regenerate the passwords using the correct  
encoding?  There is a backward compatibility flag, but it would be  
much better to use the correct encoding.

-- Scott
>
>
>
> I used to have the following configuration in Resin 2.1.14
>
> 
>  com.caucho.http.security.XmlAuthenticator
>  
>  
> 
>
>
> The passwords in the referenced file passwords.xml are for example  
> like
> this:
>
> 
>  
> 
>
>
> In 3.1 I have configured it as follows:
>
> 
>  
>MD5-base64
>none
>/home/stbu/passwords.xml
>  
> 
>
> => I knew that the default realm is "resin", so I've set it explicitly
> to "none" so that I could reuse my old passwords.
> But trying to login with the Username and Passwords are now rejected.
>
>
> The password used for 2.1.14 have been generated with this utility
> class:
>
> 
> package com.example;
>
> import com.caucho.http.security.PasswordDigest;
> import javax.servlet.*;
>
> public class Digest {
>public static void main(String args[]) throws  
> ServletException {
>PasswordDigest digest = new PasswordDigest();
>digest.setAlgorithm("MD5");
>digest.setFormat("base64");
>
>System.out.println("Preparing Password '" + args[1] +  
> "'
> for User '" + args[0] + "'");
>String password = digest.getPasswordDigest(args[0],
> args[1]);
>System.out.println("Digest Password: '" +password +
> "'");
>}
> }
> 
>
> java com.example.Digest myuser mypassword
> Preparing Password 'mypassword' for User 'myuser'
> Digest Password: 'cXSMXbxTmOz7Hv4lcVvrC3'
>
>
> In order to investigate why the login is rejected, I extended the
> utility class to allow the specification of the realm and used the 3.1
> Jars of Resin to generate the password for a user and compare them
>
> 
> package com.example;
>
> import com.caucho.http.security.PasswordDigest;
> import javax.servlet.*;
>
> public class Digest31 {
>public static void main(String args[]) throws  
> ServletException {
>PasswordDigest digest = new PasswordDigest();
>digest.setAlgorithm("MD5");
>digest.setFormat("base64");
>digest.setRealm(args[2]);
>
>System.out.println("Preparing Password '" + args[1] +  
> "'
> for User '" + args[0] + "'" + " with realm '" + args[2] + "'");
>String password = digest.getPasswordDigest(args[0],
> args[1]);
>System.out.println("Digest Password: '" +password +
> "'");
>}
> }
> 
>
> java com.example.Digest31 myuser mypassword none
> Preparing Password 'mypassword' for User 'myuser' with realm 'none'
> Digest Password: 'cXSMXbxTmOz7Hv4lcVvrtw=='
>
> BTW: The same result is achieved when using the "Calculate Digest" on
> the Login Page of /resin-admin.
>
>
> The passwords look similar, but they are actually not the same - so  
> the
> rejection is clear.
> 2.1: 'cXSMXbxTmOz7Hv4lcVvrC3'
> 3.1: 'cXSMXbxTmOz7Hv4lcVvrtw=='
>
>
>
> Has anybody else got such problems and figured out how to solve it?
> I don't know how I have to set the init values for the  
> XmlAuthenticator
> in order to get the old passwords working.
>
>
> Thanks in advance
> Steffen
>
>
>
>
> ___
> 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] Different MD5-base64 digest passwords Resin2.1 vs. Resin 3.1 with realm of none

[Scott Ferguson]

On Feb 6, 2009, at 9:22 AM, BUSCH Steffen wrote:

>
> Thanks Scott, I think I'm aware of 80 % of the passwords and can
> regenerate them.
> As I'm having several external passwords files with the old base64
> encoded passwords for different web-apps, it would be great if you  
> could
> advise how to set the backward compatibility flag for those web-apps
> where it would be difficult for me to regenerate the passwords.

It should just be "old-encoding", althout you might need to change the  
config to look like:

   .

-- Scott

>
>
> Thanks,
> Steffen
>
>
>>>
>>>
>>>
>>> I used to have the following configuration in Resin 2.1.14
>>>
>>> 
>>> com.caucho.http.security.XmlAuthenticator
>>> 
>>> 
>>> 
>>>
>>>
>>> The passwords in the referenced file passwords.xml are for example
>>> like
>>> this:
>>>
>>> 
>>> > role='resin' />
>>> 
>>>
>>>
>>> In 3.1 I have configured it as follows:
>>>
>>> 
>>> 
>>>   MD5-base64
>>>   none
>>>   /home/stbu/passwords.xml
>>> 
>>> 
>>>
>>> => I knew that the default realm is "resin", so I've set it
>> explicitly
>>> to "none" so that I could reuse my old passwords.
>>> But trying to login with the Username and Passwords are now
>> rejected.
>>>
>>>
>>> The password used for 2.1.14 have been generated with this utility
>>> class:
>>>
>>> 
>>> package com.example;
>>>
>>> import com.caucho.http.security.PasswordDigest;
>>> import javax.servlet.*;
>>>
>>> public class Digest {
>>>   public static void main(String args[]) throws
>>> ServletException {
>>>   PasswordDigest digest = new PasswordDigest();
>>>   digest.setAlgorithm("MD5");
>>>   digest.setFormat("base64");
>>>
>>>   System.out.println("Preparing Password '" +
>> args[1] +
>>> "'
>>> for User '" + args[0] + "'");
>>>   String password = digest.getPasswordDigest(args[0],
>>> args[1]);
>>>   System.out.println("Digest Password: '" +password +
>>> "'");
>>>   }
>>>}
>>> 
>>>
>>> java com.example.Digest myuser mypassword
>>> Preparing Password 'mypassword' for User 'myuser'
>>> Digest Password: 'cXSMXbxTmOz7Hv4lcVvrC3'
>>>
>>>
>>> In order to investigate why the login is rejected, I extended the
>>> utility class to allow the specification of the realm and
>> used the 3.1
>>> Jars of Resin to generate the password for a user and compare them
>>>
>>> 
>>> package com.example;
>>>
>>> import com.caucho.http.security.PasswordDigest;
>>> import javax.servlet.*;
>>>
>>> public class Digest31 {
>>>   public static void main(String args[]) throws
>>> ServletException {
>>>   PasswordDigest digest = new PasswordDigest();
>>>   digest.setAlgorithm("MD5");
>>>   digest.setFormat("base64");
>>>   digest.setRealm(args[2]);
>>>
>>>   System.out.println("Preparing Password '" +
>> args[1] +
>>> "'
>>> for User '" + args[0] + "'" + " with realm '" + args[2] + "'");
>>>   String password = digest.getPasswordDigest(args[0],
>>> args[1]);
>>>   System.out.println("Digest Password: '" +password +
>>> "'");
>>>   }
>>>}
>>> 
>>>
>>> java com.example.Digest31 myuser mypassword none
>>> Preparing Password 'mypassword' for User 'myuser' with realm 'none'
>>> Digest Password: 'cXSMXbxTmOz7Hv4lcVvrtw=='
>>>
>>> BTW: The same result is achieved when using the "Calculate
>> Digest" on
>>> the Login Page of /resin-admin.
>>>
>>>
>>> The passwords look similar, but they are actually not the
>> same - so
>>> the
>>> rejection is clear.
>>> 2.1: 'cXSMXbxTmOz7Hv4lcVvrC3'
>>> 3.1: 'cXSMXbxTmOz7Hv4lcVvrtw=='
>>>
>>>
>>>
>>> Has anybody else got such problems and figured out how to solve it?
>>> I don't know how I have to set the init values for the
>>> XmlAuthenticator
>>> in order to get the old passwords working.
>>>
>>>
>>> Thanks in advance
>>> Steffen
>>>
>>>
>>>
>>>
>>> ___
>>> 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] Apache issue

[Scott Ferguson]

On Feb 6, 2009, at 6:05 AM, Ronan Lucio wrote:

> inds a httpd process consuming 200% from CPU
>
> It got the application much more stable, but once in a while (once in
> week for example) I have the same problem: server gets almost  
> unresponsive.
> So as a workaround it run a "killall -1 httpd" each hour.
>
> It got the server much more stable, but it isn't the ideal behavior.
> Do you guys have some trouble like that?

I have an open report on that issue, but haven't been able to  
reproduce it here under stress testing.  Do you have any information  
in the logs suggesting something that might trigger this? (e.g. some  
connection issue on the Resin side.)

-- Scott

>
> What do you suggest?
>
> The same application in another application server runs without this  
> issue.
>
> Ronan
>
>
> ___
> 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 3.0/3.2 Inconsistency

[Scott Ferguson]

On Feb 6, 2009, at 1:21 PM, Aaron Freeman wrote:

> Under Resin-3.0.x the following code works whether I pass in a  
> 'email' param
> or not.  However on Resin 3.2.1, which I just installed .. It throws  
> an
> exception if an 'email' param wasn't passed in. However it works  
> great if I
> do pass an email param in.  Any thoughts?

Unfortunately, that exception is required by the JSTL specification,  
and Resin 3.2 is stricter about spec compliance.

-- Scott

>
>
> 
> 
>
> 
>   
> 
>
> The work around is to put a  test around the  and  
> test if
> param.email is defined, but I am curious if the forEach should throw  
> an
> exception when the $email variable is empty?
>
> Thanks,
>
> Aaron
>
>
>
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest



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

Re: [Resin-interest] Question about the Comet demo

[Scott Ferguson]

On Feb 9, 2009, at 2:43 PM, Aaron Freeman wrote:

> Ok I was able to find the AddString source with Google.  Now at  
> runtime I am
> receiving the exception below.  This feels like a configuration  
> issue.  I
> didn't do anything with the sample web-beans.xml because it looks  
> empty.  Am
> I supposed to place that somewhere, and is that the problem?

That's a complicated question, because the Java Injection (webbeans)  
spec just changed all packages and  locations for the beans.xml.

The best thing, really, is if I clean up the example with the new Java  
Injection packaging and release a 4.0 snapshot.

-- Scott

>
>
> 500 Servlet Exception
>
> [show] example.TestCometServlet._timerService: Can't find a
> component for 'example.TimerService'
>
> javax.servlet.ServletException: com.caucho.config.ConfigException:
> example.TestCometServlet._timerService:
> Can't find a component for 'example.TimerService'
>   at
> com 
> .caucho 
> .server.dispatch.ServletConfigImpl.createServlet(ServletConfigImpl
> .java:790)
>   at
> com 
> .caucho 
> .server.dispatch.CometServletFilterChain.doFilter(CometServletFilt
> erChain.java:101)
>   at
> com 
> .caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java: 
> 201)
>   at
> com 
> .caucho 
> .server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:1
> 89)
>   at
> com 
> .caucho 
> .server.dispatch.ServletInvocation.service(ServletInvocation.java:
> 266)
>   at
> com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:292)
>   at
> com 
> .caucho.server.port.TcpConnection.handleRequests(TcpConnection.java: 
> 577)
>   at
> com.caucho.server.port.TcpConnection 
> $AcceptTask.doAccept(TcpConnection.java:
> 1211)
>   at
> com.caucho.server.port.TcpConnection 
> $AcceptTask.run(TcpConnection.java:1152)
>   at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:759)
>   at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:681)
>   at java.lang.Thread.run(Thread.java:619)
> Caused by: com.caucho.config.ConfigException:
> example.TestCometServlet._timerService:
> Can't find a component for 'example.TimerService'
>   at
> com 
> .caucho 
> .webbeans.manager.WebBeansContainer.injectError(WebBeansContainer.
> java:1121)
>   at
> com 
> .caucho 
> .webbeans.manager.WebBeansContainer.createProgram(WebBeansContaine
> r.java:470)
>   at
> com 
> .caucho 
> .config.j2ee.InjectIntrospector.introspectInjectImpl(InjectIntrosp
> ector.java:208)
>   at
> com 
> .caucho 
> .config.j2ee.InjectIntrospector.introspectInject(InjectIntrospecto
> r.java:183)
>   at
> com 
> .caucho.webbeans.component.ClassComponent.bind(ClassComponent.java: 
> 411)
>   at
> com 
> .caucho 
> .webbeans.manager.WebBeansContainer.createTransient(WebBeansContai
> ner.java:836)
>   at
> com 
> .caucho 
> .server.dispatch.ServletConfigImpl.createServletImpl(ServletConfig
> Impl.java:834)
>   at
> com 
> .caucho 
> .server.dispatch.ServletConfigImpl.createServlet(ServletConfigImpl
> .java:754)
>   at
> com 
> .caucho 
> .server.dispatch.CometServletFilterChain.doFilter(CometServletFilt
> erChain.java:101)
>   at
> com 
> .caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java: 
> 201)
>   at
> com 
> .caucho 
> .server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:1
> 89)
>   at
> com 
> .caucho 
> .server.dispatch.ServletInvocation.service(ServletInvocation.java:
> 266)
>   at
> com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:292)
>   at
> com 
> .caucho.server.port.TcpConnection.handleRequests(TcpConnection.java: 
> 577)
>   at
> com.caucho.server.port.TcpConnection 
> $AcceptTask.doAccept(TcpConnection.java:
> 1211)
>   at
> com.caucho.server.port.TcpConnection 
> $AcceptTask.run(TcpConnection.java:1152)
>   at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:759)
>   at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:681)
>   at java.lang.Thread.run(Thread.java:619)
>
>
>
>> -Original Message-
>> From: resin-interest-boun...@caucho.com [mailto:resin-interest-
>> boun...@caucho.com] On Behalf Of Aaron Freeman
>> Sent: Monday, February 09, 2009 4:19 PM
>> To: 'General Discussion for the Resin application server'
>> Subject: Re: [Resin-interest] Question about the Comet demo
>>
>> I am trying to run the Comet demo referenced in the post below (only
>> changing the pack

Re: [Resin-interest] Question about the Comet demo

[Scott Ferguson]

On Feb 9, 2009, at 3:24 PM, Aaron Freeman wrote:

> Ok I will wait patiently for that.   What URL should I check for the  
> new
> example?

It would be http://caucho.com/resin/examples/servlet-comet.xtp.

> I finally figured out that if I copy my classes to the WEB-INF  
> folder and
> then create the META-INF/web-beans.xml under there I can get it  
> working.
> But it could find the classes under my [project]/classes folder (I  
> run Resin
> under Eclipse), so I am not sure why it wouldn't work when I created  
> the
> META-INF folder under _that_ 'classes' folder?  Oh well I will first  
> try to
> recreate your next environment and then shoot questions.

The beans.xml should work under any root (jar or classes).  Do you  
have a separate  configuration for the eclipse work  
area?  In other words, how does Resin know about your classes directory?

-- Scott
>
>
> Thanks,
>
> Aaron
>
>> -Original Message-
>> From: resin-interest-boun...@caucho.com [mailto:resin-interest-
>> boun...@caucho.com] On Behalf Of Scott Ferguson
>> Sent: Monday, February 09, 2009 5:02 PM
>> To: General Discussion for the Resin application server
>> Subject: Re: [Resin-interest] Question about the Comet demo
>>
>>
>> On Feb 9, 2009, at 2:43 PM, Aaron Freeman wrote:
>>
>>> Ok I was able to find the AddString source with Google.  Now at
>>> runtime I am
>>> receiving the exception below.  This feels like a configuration
>>> issue.  I
>>> didn't do anything with the sample web-beans.xml because it looks
>>> empty.  Am
>>> I supposed to place that somewhere, and is that the problem?
>>
>> That's a complicated question, because the Java Injection (webbeans)
>> spec just changed all packages and  locations for the beans.xml.
>>
>> The best thing, really, is if I clean up the example with the new  
>> Java
>> Injection packaging and release a 4.0 snapshot.
>>
>> -- Scott
>>
>>>
>>>
>>> 500 Servlet Exception
>>>
>>> [show] example.TestCometServlet._timerService: Can't find a
>>> component for 'example.TimerService'
>>>
>>> javax.servlet.ServletException: com.caucho.config.ConfigException:
>>> example.TestCometServlet._timerService:
>>> Can't find a component for 'example.TimerService'
>>> at
>>> com
>>> .caucho
>>> .server.dispatch.ServletConfigImpl.createServlet(ServletConfigImpl
>>> .java:790)
>>> at
>>> com
>>> .caucho
>>> .server.dispatch.CometServletFilterChain.doFilter(CometServletFilt
>>> erChain.java:101)
>>> at
>>> com
>>> .caucho 
>>> .server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:
>>> 201)
>>> at
>>> com
>>> .caucho
>>> .server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:1
>>> 89)
>>> at
>>> com
>>> .caucho
>>> .server.dispatch.ServletInvocation.service(ServletInvocation.java:
>>> 266)
>>> at
>>>
>> com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java: 
>> 292)
>>> at
>>> com
>>> .caucho.server.port.TcpConnection.handleRequests(TcpConnection.java:
>>> 577)
>>> at
>>> com.caucho.server.port.TcpConnection
>>> $AcceptTask.doAccept(TcpConnection.java:
>>> 1211)
>>> at
>>> com.caucho.server.port.TcpConnection
>>> $AcceptTask.run(TcpConnection.java:1152)
>>> at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:759)
>>> at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:681)
>>> at java.lang.Thread.run(Thread.java:619)
>>> Caused by: com.caucho.config.ConfigException:
>>> example.TestCometServlet._timerService:
>>> Can't find a component for 'example.TimerService'
>>> at
>>> com
>>> .caucho
>>> .webbeans.manager.WebBeansContainer.injectError(WebBeansContainer.
>>> java:1121)
>>> at
>>> com
>>> .caucho
>>> .webbeans.manager.WebBeansContainer.createProgram(WebBeansContaine
>>> r.java:470)
>>> at
>>> com
>>> .caucho
>>> .config.j2ee.InjectIntrospector.introspectInjectImpl(InjectIntrosp
>>> ector.java:208)
>>> at
>>> com
>>> .caucho
>>> .config.j2ee.InjectIntrospector.introspectInject(InjectIntrospecto
>>> r.java:183)
>>>

Re: [Resin-interest] Annotations in the Comet demo

[Scott Ferguson]

On Feb 10, 2009, at 2:59 PM, Aaron Freeman wrote:

> I have a question about the one of the annotations in the Comet demo  
> at:
>
> http://www.caucho.com/resin-3.1/examples/servlet-comet/comet
>
> I am not too familiar with Java's annotations, so I am wondering how  
> I can
> get access to the _timerService, which is declared like:
>
>  @In private TimerService _timerService;
>
> I would like to create a JSTL custom tag, for example, that can  
> access the
> _timerService.  What does @In do?

I've updated the example at http://caucho.com/resin/examples/servlet-comet 
.  The example has been disabled because caucho.com isn't running the  
latest snapshot yet.  (Possible upgrade this weekend)

The META-INF/beans.xml triggers a scan of all the classes to register  
the beans.  For the TimerService, I've marked it as  
@javax.context.ApplicationScoped, which means it has the same lifetime  
as the , i.e. it's essentially a singleton.

The TimerService has a default binding type of @javax.inject.Current.   
You use the binding annotation wherever you want the TimerService (as  
long as the class is managed by Resin).  Since JSP tags are managed by  
Resin, you can use @javax.inject.Current in a JSP tag definition's  
field to get a reference to the TimerService.

With the latest Java DI spec draft, a bean/class like TimerService  
does not automatically get a name.  So it can't automatically be used  
by a JSP/JSF EL expression.  To register the bean with a name for EL,  
you use @javax.annotation.Named on the class, like:

@javax.annotation.Named("timer")
@javax.context.ApplicationScoped
public class TimerService {
   ...
}

Then ${timer} will refer to the timer instance.

> Do I just have to create a getter method that returns TimerService?   
> That
> wouldn't seem to work unless TimerService is a singleton -- but it's  
> not
> declared statically.

Correct.  TimerService is basically a singleton within the context of  
a web-app.  You should avoid static singletons because of classloader  
issues.

-- Scott

>  I am thinking I can solve this easily with
> annotations, but I just don't understand them quite yet.
>
> Thanks,
>
> Aaron
>
>
>
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest



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

Re: [Resin-interest] Is resin vulnerable to session cookie hijacking?

[Scott Ferguson]

On Feb 11, 2009, at 9:17 AM, John Livic wrote:

> Hello,
>
> I would like to know if resin 3 is vulnerable to session cookie
> hijacking. In the documentation it's written that :
>
> "It is conceivable that someone could use a packet sniffer to find
> the session id of a user and then make a fake request to Resin
> thus gaining access to the session. This can be avoided by using
> HTTPS."
>
> Does that mean that a session id is not tied to an IP address?

Correct.  Resin can't tie a session id to an IP address because client  
IP addresses legitimately change for the same cookie.  Ages ago, AOL  
was notorious for being particularly bad about this.

If you need real security, you really need to use HTTPS.

-- Scott

> For performance reasons I would like to use HTTPS on the login
> page only.
>
> Thanks in advance,
>
> John
>
>
> ___
> 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] Context and Dependency Injection

[Scott Ferguson]

On Feb 11, 2009, at 8:38 AM, Aaron Freeman wrote:

> Scott,
>
> I have finally caught up with understanding where you are going with  
> the new
> Resin IoC -- I am excited to use it.  I'd like to do some of the  
> things on
> this doc: http://www.caucho.com/resin/doc/resin-ioc.xtp but I don't  
> see
> where to download a release-candidate for the JSR-299 stuff?  I made  
> it
> here: http://jcp.org/en/jsr/detail?id=299 but I don't see any
> release-candidates that I can download.  Any hints?

I just put up a new 4.0 snapshot at http://caucho.com/download.  The  
4.0 snapshot isn't stable, but it does implement the latest Java  
Injection draft, so you can start working with it.

I've been very happy with how JSR-299 (Java Injection) has developed.   
It's amazingly powerful.

-- Scott

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



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

Re: [Resin-interest] Resin Messaging using JCA

[Scott Ferguson]

On Feb 11, 2009, at 10:08 AM, ngiudici wrote:


Hi all,

I’m trying to figure out how to send jms messages between different  
resin servers.


For now, you may want to use a different provider like ActiveMQ for  
remote JMS.


We're revamping our clustered JMS in Resin 4.0 to use BAM/HMTP as the  
underlying messaging protocol.  One of the major motivations for BAM/ 
HMTP in Resin 4.0 is to improve the capabilities of all of our  
messaging, including JMS.


The 3.1 and 3.2 capabilities only let you queue to a cluster, i.e.  
define a "client" queue that sends remote messages to servers in a  
"server" cluster.  If that's the capability you need, I can show the  
3.1 configuration to make that possible.


-- Scott 



I was able to get the tutorial here, http://www.caucho.com/resin/examples/jms-listener/index.xtp 
, working with no issues when I’m sending the message and receiving  
it on the same instance of resin. Now I need to extend this to be  
able to send the message from one machine and receive it in another  
but I can’t find anything that tell me how to configure this.


It is particularly frustrating that the documentation says  
“Messaging lets a servlet delegate processing to a batch process  
either on the same machine or on a separate machine” then fails to  
talk about how to do it from a separate machine.


Thanks for your time,

Nick
___
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] Issues with init.d files on Redhat/Centos

[Scott Ferguson]

On Feb 12, 2009, at 2:00 PM, jkowall wrote:

> I am using the bundled init files that come with Resin, but they are  
> not updated for 3.x, they seem to be 2.x init scripts.  Is there a  
> good working init script somewhere?

Hmm.  The 3.2.1 scripts were updated for debian/ubuntu, but we didn't  
make separate scripts for RedHat.

-- Scott
>
>
> Thanks guys!
>
> -- 
>
> -jk
> ___
> 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] reverse proxy support like ProxyPass in apache?

[Scott Ferguson]

On Feb 18, 2009, at 1:17 PM, Ryan Vanderwerf wrote:

> Does anyknow know if Resin 3.1 has any kind of reverse proxy support  
> similar to the ProxyPass options in Apache? We are exploring whether  
> Resin could be the font-end web server for our application instead  
> of Apache - mostly due to issues we are having with mod_caucho  
> communications.

There's a proxy servlet name com.caucho.servlets.HttpProxyServlet.

The servlet uses a "host" parameter to specify the backend servers:


   


-- Scott

>
>
>
> Ryan
>
> -- 
>
> NOTICE: This e-mail message is for the sole use of the intended  
> recipient(s) and may contain confidential and privileged  
> information. Any unauthorized review, use, disclosure or  
> distribution is prohibited. Nothing contained in this message or in  
> any attachment shall constitute a contract or electronic signature  
> under the Electronic Signatures in Global and National Commerce Act,  
> any version of the Uniform Electronic Transactions Act or any other  
> statute governing electronic transactions.
>
>
> ___
> 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] mod_caucho failure on CentOS 5.2/Apache 2.2

[Scott Ferguson]

On Feb 19, 2009, at 11:15 AM, david day wrote:

> I have test against another 32 bit server running
> 2.6.18-92.1.22.el5.centos.plusPAE with same installed packages as the
> older 32 bit server running 2.6.18-92.1.22.el5.centos.plus also fails.
> Another test on a new 64 bit CentOS release 5.2 (Final) build running
> 2.6.18-92.el5 yields same results.
>
> To take RedHat's Apache 2.2.3 out of the mix, source
> httpd-2.2.11-1/httpd-devel-2.2.11-1 was built/installed with same
> caucho-status result "Unconfigured Default Virtual Host".

Can you check with the current 3.1.8 snapshot?

We introduced a compile-time error where one of the CFLAGS (the large  
file defines), was messing up an internal Apache data structure,  
causing mod_caucho's configuration to be skipped.

The 3.1.8 snapshot reverts those flags to the ones returned by  
Apache's apr info.  If you're still having trouble with the snapshot,  
then this may be a different issue.

-- Scott

>
>
> At this point, a functional mod_caucho cannot be built on any new  
> CentOS server.
> David
>
>
> ___
> 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] XPath Parsing Error w/ Resin 4.0

[Scott Ferguson]

On Feb 19, 2009, at 11:10 AM, Aaron Freeman wrote:

> This code works on 3.0 and 3.1 ... I don't see why it would fail  
> under Resin
> 4.0.  The exception is being thrown on the  statement.  If  
> you
> comment it out the error is not thrown.  First the error:

We've made some compatibility changes for the JSTL library in 4.0.   
This is probably just a regression.  I've added a bug report at 
http://bugs.caucho.com/view.php?id=3349

-- Scott

>
>
> 500 Servlet Exception
>
> [show] org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made  
> to create
> or
> change an object in a way which is incorrect with regard to  
> namespaces.
>
> javax.servlet.ServletException: javax.servlet.jsp.JspException:
> org.w3c.dom.DOMException:
> NAMESPACE_ERR: An attempt is made to create or change an object in a  
> way
> which is incorrect with regard to namespaces.
>   at
> com 
> .caucho.jsp.PageContextImpl.handlePageException(PageContextImpl.java: 
> 1237
> )
>   at _jsp._test__jsp._jspService(_test__jsp.java:30)
>   at com.caucho.jsp.JavaPage.service(JavaPage.java:61)
>   at com.caucho.jsp.Page.pageservice(Page.java:536)
>   at
> com 
> .caucho 
> .server.dispatch.PageFilterChain.doFilter(PageFilterChain.java:195
> )
>   at
> com 
> .caucho 
> .server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:1
> 84)
>   at
> com 
> .caucho 
> .server.dispatch.ServletInvocation.service(ServletInvocation.java:
> 264)
>   at
> com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:303)
>   at
> com 
> .caucho.server.port.TcpConnection.handleRequests(TcpConnection.java: 
> 603)
>   at
> com.caucho.server.port.TcpConnection 
> $AcceptTask.doAccept(TcpConnection.java:
> 1242)
>   at
> com.caucho.server.port.TcpConnection 
> $AcceptTask.run(TcpConnection.java:1183)
>   at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:769)
>   at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:686)
>   at java.lang.Thread.run(Thread.java:619)
>
>
>
>
> And now the code that you can copy/paste into a test.jsp and run it  
> verbatim
> to see the error.
>
>
> <%@ taglib uri="http://java.sun.com/jsp/jstl/core"; prefix="c" %>
> <%@ taglib uri="http://java.sun.com/jsp/jstl/fmt"; prefix="fmt" %>
> <%@ taglib uri="http://java.sun.com/jsp/jstl/xml"; prefix="x" %>
>
> http://maps.google.com/maps/geo";>
>   
>   
>   
>   
>value="ABQIgrj58PbXr2YriiRDqbnL1RRdqDCIfn-akWLPXbZqJg- 
> hQ6eHehSRJ1rozvQIj
> 0_jjwfMfzxMVY23oQ"/>
> 
>
> 
> 
>
> ${url}
>
> ${googleXml}
>
>
>
> ___
> 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