Re: [Resin-interest] Database Pooling

[Gary Zhu]

If you migrate to Oracle 11, with scan DNS entries defined (google "Oracle 
SCAN", and click the first link), then the connection string is simpler - just 
one ADDRESS entry.

In any case,  you should separate configuration from Java code, define RAC 
configure in Oracle client configuration "tnsnames.ora" and then in resin 
configuration,  define  within it, , , etc...   So 
your java code should just reference the datasource by JNDI name.



From: resin-interest-boun...@caucho.com 
[mailto:resin-interest-boun...@caucho.com] On Behalf Of Steve Francis
Sent: Friday, July 22, 2011 10:54 AM
To: resin-interest@caucho.com
Subject: [Resin-interest] Database Pooling

I'm new to using Resin's database pooling, so I'm wondering if there is 
anything special about setting it up to use an Oracle RAC .  I know that in my 
current  java programs, the connect string is rather complex...

databaseconnect=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(Host=adcracdbq1-racvip.hiw.
com)(Port=1521))(ADDRESS=(PROTOCOL=TCP)(Host=adcracdbq2-racvip.hiw.com)(Port=152
1))(LOAD_BALANCE=yes)(FAIL_OVER=NO)(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME
=HMIQ)))


How is the RAC environment configured with Resin?

Thanks,

Steve Francis
Technical Adviser -- Application Technologies
IHG
Office:  770-442-7157
Cell: 770-906-3122
IM:  francisihg

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

[Gary Zhu]

This is not a Resin issue, all application servers have this issue.

This article presents some practical fixes: 
http://shiflett.org/articles/session-hijacking


Note that HTTPS cookie can also be hijacked if it is not implemented properly. 
I am not going to delve into details on this topic.


-Original Message-
From: resin-interest-boun...@caucho.com 
[mailto:resin-interest-boun...@caucho.com] On Behalf Of John Livic
Sent: Wednesday, February 11, 2009 9:17 AM
To: resin-interest@caucho.com
Subject: [Resin-interest] Is resin vulnerable to session cookie hijacking?

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?

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] submitting bugs on snapshot versions?

[Gary Zhu]

On the download site, the current snapshot version is labeled as  "Resin Pro 
3.1 snapshot (Alpha)"

Could you label it as "Resin Pro 1.3 snapshot (3.1.5 Alpha)" ?

To me, it will be clear that the download is the alpha version (not a 
production release) of 3.1.5, and I'd file bugs accordingly.

Just a suggestion.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ferguson
Sent: Monday, February 25, 2008 3:56 PM
To: General Discussion for the Resin application server
Subject: Re: [Resin-interest] submitting bugs on snapshot versions?


On Feb 25, 2008, at 3:48 PM, Emil Ong wrote:

> On Mon, Feb 25, 2008 at 03:25:18PM -0800, Daniel Spangler wrote:
>> Is it of bad form to submit bugs that have arisen on a snapshot
>> version?  If
>> not, then what release tag do we log it under in Mantis?
>
> Hi Daniel,
>
> Bugs for snapshots are gladly accepted.  :-) Just file it under the
> most recently released version.  For example, if you found a bug in a
> snapshot between 3.1.4 and 3.1.5, you should use 3.1.4.

Other way around :)

If it's a new bug introduced after 3.1.4, it would be reported as 3.1.5.

-- Scott

>
>
> Thanks!
> Emil
>
> 
>
> Emil Ong
> Chief Evangelist
> Caucho Technology, Inc.
> Tel. (858) 456-0300
> mailto:[EMAIL PROTECTED]
>
> Caucho: Reliable Open Source
> --> Resin: application server
> --> Quercus: PHP in Java
> --> Hessian Web 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


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

Re: [Resin-interest] Deploying .war files directly from a maven repository - possible?

[Gary Zhu]

Not sure whether Jetty is doing hot-deploy or not.


With Resin:









-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mark Derricutt
Sent: Thursday, October 25, 2007 1:26 AM
To: General Discussion for the Resin application server
Subject: [Resin-interest] Deploying .war files directly from a maven repository 
- possible?


Hey all,

Does anyone know if its possible to (extend/patch/plugin) get Resin to 
automatically deploy a .war from a maven2 repository similar to what polarrose 
have done with jetty:

http://code.google.com/p/polarrose-jetty-maven-deployer/

The idea is to have a process automatically what a repository for new SNAPSHOT 
wars and automatically redeploy the application with the new one.

Is anything like this possible?

Mark

--
It`s not the tree that forsakes the flower, but the flower that forsakes the 
tree
Someday I`ll learn to love these scars - Bye Bye Beautiful

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

Re: [Resin-interest] Compelling reasons to use Resin?

[Gary Zhu]

Hari,

Would you be able to run the performance test again, on Resin and Tomcat ?
That way, you can charge your client company more time for 'evaluating' the 
products,
and the results of the tests would be an asset for your client company 
management
to make them look smarter (justification of your extra charges ;)).
And, when you have time, would you please post your results here ?

Long time ago, somewhere on Caucho site, I saw some Resin performance data 
against Apache,
Resin was slightly better or equal in regarding serving static pages, that 
would help you simplify your web architecture if you were using Apache as first 
tier to serve static contents.
I am not sure whether that performance data is still valid after several 
revisions and I couldn't even find where it is now.

Thanks, Hari, you have brought up a good topic.


>
> I've been a Resin advocate for several years now. When I first did a
> performance comparison between Resin 2 and Tomcat, Resin's performance
> simply blew me away. Like many other people on this list, I imagine I
> switched entirely to recommending resin as the application server for
> all the projects I've worked on. They were all small startups so it
> didn't count towards hundreds of licenses, but still.
>
> Now, at another startup that I'm working with - with a
> licensed version
> of Resin Pro for our one app server -I'm being asked to
> justify the use
> of Resin over Tomcat, specially as look to grow and add additional
> servers. We use Resin only as a servlet container, so its EJB and PHP
> capabilities are not a justification. Googling around leads me to
> believe that Tomcat has gotten a lot faster recently, with NIO support
> in 6.0.x, and that the performance gap may have narrowed of late.
>
> So I seek the collective wisdom of the list: what are some of the
> compelling reasons that led you to choose Resin Pro over other
> application servers, and Tomcat in particular? Is anyone
> aware of recent
> benchmarks that compare resin and tomcat?
>
> To close, I should say that I personally love resin - its elegance,
> configuration simplicity and developer-friendliness. It's
> just that I'm
> trying to find a reason to convince management why we should
> use it over
> the "free" application server.
>
> Many thanks,
>
> - 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] code too large for try statement error!

[Gary Zhu]

To solve your problem, make sure that your JSP compiled/generated Java files do 
not have try blocks and Java methods too large, for (rough) example, exceeding 
10,000 lines. It's just the limitation of try blocks and java methods, the size 
of java file has no limit.

When a java file is compiled into .class file, there is a limitation in "JVM 
spec" that try block represented in the java byte code cannot exceed 64K. Since 
the largest try block could be the entire Java method (a method throws 
exceptions),  this 64K limitation is also (conveniently) imposed on each Java 
method.


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] [EMAIL 
PROTECTED]
Sent: Saturday, September 08, 2007 9:43 AM
To: resin-interest@caucho.com
Subject: [Resin-interest] code too large for try statement error!

What should I do to fix the jsp page when resin server ran into the
following errors?

code too large for try statement

-Henry


___
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] Problem with round tripping xml file - encoding response

[Gary Zhu]

Don't know the other part of your code, but try this:


Remove these two lines:

res.setContentType("application/xml; charset=UTF-8");
res.setCharacterEncoding("UTF-8");

and put in only:

res.setContentType("application/xml");

See what Resin will do...


> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Robert Edgar
> Sent: Thursday, June 21, 2007 6:59 PM
> To: resin-interest@caucho.com
> Subject: [Resin-interest] Problem with round tripping xml file -
> encoding response
>
>
> I am trying to round trip an xml document that contains some
> UTF-8 symbols.
>
> The doc is constructed on the client (displays correctly).
>
> It is then posted to the server.
>
> Server writes the data to a file under ROOT (data is correct)
>
> Server also writes data back to client as the response.
>
> Client displays response (data is corrupted - its still a
> valid xml but the
> symbols are no longer correct)
>
> Client directly requests the file copy of the data from the
> server (data
> display correctly)
>
>
> Server side this is being processed by a servlet, and I have
> included the
> following line at the start of doPost():
> //Set the Output Stream to XML
> res.setContentType("application/xml; charset=UTF-8");
> res.setCharacterEncoding("UTF-8");
> //set input stream to UTF8
> req.setCharacterEncoding("UTF-8");
>
> I have also added UTF-8 to
> web-app-default configuration file.
>
>
> I am using the latest stable release of Resin(dl yesterday),
> standalone,
> running on my local PC under WinXP.
>
> I assume the problem has to do with encoding but does anyone
> know how to
> resolve this problem?
>
>
> Thanks
> Rob
>
>
>
>
> ___
> 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] Application Memory Profiling

[Gary Zhu]

It could be as simple as your ThreadLocal, in addition to that, this could also 
be caused by others.

The class-loader problem has bugged many people. JavaOne07 had this late 
evening FOB session on the topic, and a lot of people showed up, looking for 
answer.

In short, 'An object can only be garbage collected if the object is 
unreachable'.
A sample code:

import java.util.logging.*;

public class your_class {
   private static final Level CUSTOMLEVEL = new Level("test", 555) {};
   
Logger.getLogger("test").log("CUSTOMLEVEL, "something");
   
};

Since CUSTOMLEVEL contains java.util.logging.Level.INFO (SEVERE, etc), and they 
are 'reachable' from other part of JVM, so your_class is not garbage collected.

On that FOB session, Edward used JHat to trace PermGen leaks, and found 5-6 
violations in that application server and a couple of places in the user 
application. A note to Caucho engineers: that case study was not based on Resin.

You can find these discussions from the blogs of two Sun engineers who 
presented this FOB:

http://blogs.sun.com/fkieviet
http://blogs.sun.com/edwardchou

one of the good articles is on Frank's blog:
http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java



> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Scott Ferguson
> Sent: Monday, June 11, 2007 9:12 AM
> To: General Discussion for the Resin application server
> Subject: Re: [Resin-interest] Application Memory Profiling
>
>
>
> On Jun 11, 2007, at 3:00 AM, Daniel López wrote:
>
> >
> > Something similar happens with com.caucho.xml.Xml: I start with 2
> > instances, one referenced from a class of mine and another from
> > java.lang.ThreadLocal. After a restart I get 2 instances referenced
> > from
> > java.lang.ThreadLocal. Another restart and I have 3 referenced from
> > java.lang.ThreadLocal... In this case, the problem seems to be a
> > growing
> > number of instances from
> org.apache.xml.utils.XMLReaderManager... that
> > are themselves related to the aforementioned
> > com.caucho.loader.EnvironmentClassLoader.
>
> Do you know what is holding the ThreadLocal references?
>
> This definitely looks like a threading/ThreadLocal issue.  There have
> been libraries which have neglected to clear the ThreadLocals
> properly, which will cause major problems with garbage collection and
> classloading.   That would be the first thing to look at.
>
> ThreadLocal needs to be used with the following pattern:
>
>ThreadLocal _local = new ThreadLocal();
>
>...
>
>Object oldValue = _local.get();
>try {
>  _local.set(newValue);
>
>  ...
>} finally {
>  _local.set(oldValue);
>}
>
> If the application forgets the second set, then the oldValue will not
> be garbage collected.
>
> >
> > So my question would be if anybody has run into similar
> issues or has
> > any idea what could be causing the proliferation of
> > com.caucho.loader.EnvironmentClassLoader instances. I
> suspect it might
> > be that some library is keeping a reference to the
> classloader through
> > some daemon thread that is not being properly initialised when the
> > context is restarted.
> >
> > Any hints on how to further debug this issue? Any similar
> experience?
>
> Look for the ThreadLocal reference.  Also, double check that there
> isn't a daemon thread that isn't properly closed on restart.
>
> -- Scott
>
> > Thanks,
> > 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
>


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

Re: [Resin-interest] Classpath problem

[Gary Zhu]

Set your class path to include all resin jar files:

CLASSPATH=.;C:\resin30\resin-3.0.22\lib\resin.jar;C:\resin30\resin-3.0.22\lib\jsdk-24.jar;C:\resin30\resin-3.0.22\lib\j2ee-management-10.jar;..;C:\Program
 Files\Java\jre1.6.0_01\lib\ext\QTJava.zip

and then, the following command should do:

java com.caucho.jsp.JspCompiler -app-dir "/opt/www/foo" test/foo.jsp

Resin distribution does not include  setenv.cmd or setenv.sh file, which allows 
users conveniently set environment, though usages are rare.


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Tim Manchester [EMAIL 
PROTECTED]
Sent: Friday, June 08, 2007 2:25 PM
To: resin-interest@caucho.com
Subject: [Resin-interest] Classpath problem

I'm trying to use the jsp compiler and I know I must be having classpath 
problems. When I attempt to execute the following command:
C:\resin30\resin-3.0.22\lib>java com.caucho.jsp.JspCompiler -app-dir 
"/opt/www/foo" test/foo.jsp

I get the following exception:
Exception in thread "main" java.lang.NoClassDefFoundError: 
com/caucho/jsp/JspCompiler

So I modified my command to this:
C:\resin30\resin-3.0.22\lib>java -jar resin.jar com.caucho.jsp.JspCompiler 
-app-dir "/opt/www/foo" test/foo.jsp
and got this exception instead:
Exception in thread "main" java.lang.NoClassDefFoundError: 
com/caucho/server/boot/ResinBoot

This is my classpath:
C:\resin30\resin-3.0.22\lib>set classpath
CLASSPATH=.;C:\resin30\resin-3.0.22\lib;C:\Program 
Files\Java\jre1.6.0_01\lib\ext\QTJava.zip

The root dir for resin is C:\resin30\resin-3.0.22\ and the lib directory 
contains the files:
C:\resin30\resin-3.0.22\lib>ls
activation.jar j2ee-deploy-10.jar   jca-15.jarjstl-11.jar   
 resin-jdk15.jar
aopalliance.jar  j2ee-management-10.jar  jms-11.jar   jta-101.jar   
resin.jar
ejb-20.jar  java   jmx-12.jar   
portlet-10.jar   resinboot.jar
ejb-30.jar  javamail-14.jarjsdk-24.jar  quercus.jar 
script-10.jar

So, what am I missing? resinboot.jar is here. resin.jar is here. Which jar file 
is ResinBoot in?

Regards,

Tim


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

Re: [Resin-interest] Resin 3.1.1 httpd is failing to bind to "*" - solved (for now)

[Gary Zhu]

>  the application is to be used in an
> appliance, which is just plugged into a network served by a
> DHCP server and expected to work.
>

Sounds like an interesting project, with Resin.

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


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

Re: [Resin-interest] Resin stops logging if logs are deleted manually

[Gary Zhu]

The existing log file was not missing, just that you could not see it. Resin 
still had the file handle and wrote bytes into it.
If you paid attention to the file system free space, you would see the log 
space was not released, until you restarted Resin.

If you still want to use logrotate, please use postrotate command to restart 
Resin; if you 'really' know logrotate, you would have noticed plenty of 
programs that use postrotate to reload or restart programs -- for the very same 
reason. It's the UNIX thing.



> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Manas Gupta
> Sent: Wednesday, June 06, 2007 3:26 PM
> To: General Discussion for the Resin application server
> Subject: Re: [Resin-interest] Resin stops logging if logs are deleted
> manually
>
>
> Still, wouldn't it make sense for Resin to start logging to
> new file, if
> the existing log file went missing.
>
> On Wed, 2007-06-06 at 16:38 -0500, Michael Ebeling wrote:
> > > -Original Message-
> > > Sent: Tuesday, June 05, 2007 11:54 AM
> > > Subject: [Resin-interest] Resin stops logging if logs are deleted
> > manually
> > >
> > > We are using Resin-3.0.19. Our access log is configured in
> > resin.conf
> > as follows
> > >
> > >  > >format='%h %l %u %t "%r" %s %b "%{Referer}i" "%{User-Agent}i"
> > Time
> > of request:<%Ts>'
> > >rollover-period="1D" archive-format="access-%Y%m%d.log.gz"/>
> > >
> > > If a utility like logrotate deletes the logs, resin stops logging
> > > completely. The server continues to run and serve requests.
> >
> > Since you are using resin to roll the logs for you, it
> would probably
> > be
> > better not to use logrotate to manipulate the same logs. Resin will
> > also
> > delete the oldest logs for you when it rolls them if you add the
> > "rollover-count" directive:
> >
> > >  format='%h %l %u %t "%r" %s %b "%{Referer}i" "%{User-Agent}i"
> > Time
> > of request:<%Ts>'
> >  rollover-period="1D"
> >  rollover-count="7"
> >  archive-format="access-%Y%m%d.log.gz"/>
> >
> > This would save a week's worth of logs plus the current one, for
> > example.
> >
> > > The same behaviour is observed for :-
> > > stdout.log & stderr.log (configured at command line)
> >
> > We have entries in the resin conf file to handle our stderr-log and
> > stdout-log the same way.
> >
> >
> >
> > ___
> > 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] clearing cache manually or in code

[Gary Zhu]

First of all, Expire header and If-Modified-Since header are there to serve 2 
different purposes

There was an email in this forum that I think should address your concern, IF 
you actually follow the link and read the articles.

I dug this email up from my deleted section, and attached it here(without 
asking the permission from Lokitech).

By the way, it would be nice to keep those email discussions organized online.


> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of
> Bernard Bernstein
> Sent: Thursday, May 31, 2007 12:49 PM
> To: General Discussion for the Resin application server
> Subject: [Resin-interest] clearing cache manually or in code
>
>
> We are using the Resin proxy cache by setting Expire headers on some
> files (jsp files that generate css and some javascript).
> Occasionally, we want to get a new version of these files loaded, but
> we don't want to set a short expiration time for the occasional
> change in something.
>
> For example.
>
> We might have a .jsp file that is the stylesheet, where we can set
> the font size through some frontend setting. We want that page to be
> cached most of the time, but when someone changes that font, we don't
> want them to need to wait for an hour for the cached version to
> expire before everyone sees the new font size. We also don't want the
> overhead of executing the jsp for every pageview.
>
> The jsp file itself isn't changing, so resin wouldn't necessarily
> know that the page has expired. So, is there any way we can
> programmatically clear that page cache, or all cached pages for that
> matter.
>
> Looking through archives I see discussion of adding:
>
> true
>
> to a webapp setup, but that doesn't seem to work anymore now that
> we're starting to use 3.1 (I haven't tested on 3.0 which we are using
> in production).
>
> I've also tried calling
> com.caucho.server.resin.ServletServer.clearCache() and doesn't seem
> to compile.
>
> I'm using jconsole to look at the jmx-accessible beans, but I don't
> see anything there that can help with this either.
>
> What is the modern way to clear the cache during runtime? I'm having
> some trouble finding an answer, so I thought I'd ask here.
>
> Thanks,
>
>
> Bernie
>
>
>
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest
>
--- Begin Message ---
Jean-François,

This is the best write-up I've seen on how browsers and proxy servers
cache:

http://www.mnot.net/cache_docs/

Then once you know what you want in headers, this page is a good
discussion of the various browser and server-side caching features in
Resin 3.1:

http://www.caucho.com/resin-3.1/doc/proxy-cache.xtp

What you want is certainly very doable and hopefully straight-forward
after reading these docs.  The first site also links to an online tool
that can test whether you've got the headers working right.

--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. [EMAIL PROTECTED]

Jean-Francois Lamy wrote:
> I am trying to understand how resin, apache and proxies interact with
> respect to caching.
>
> I have a jsp page which is meant to be always dynamic; headers are used to
> prevent it from being cached.
> However, the page loads js, css, and various images, which I would like to
> be cached.
>
> Currently,  the browser (IE7) requests those items, and Resin returns 304
> (up-to-date) status.  The browser is NOT set to force request at each page.
> This generates a lot of requests, which are painful when going through
> proxies.
>
> Is there a recipe for forcing the JSP to always reload (my JSPs are served
> through a dispatching servlet which does an include, and therefore servlet
> is able manipulate the headers), and yet let the browser know that the js
> and css it has in cache are just fine ?
>
> Jean-François Lamy
> Technologies Teximus inc.
> www.teximus.com
> +1 514.878.1577 (Canada)
> +33(0) 8.70.44.49.02 (Europe)
>
>
>
>
>
> ___
> 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
--- End Message ---
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Connection Reset message

[Gary Zhu]

Before you start doing it the hard way:

Double check your apache.conf and resin.conf to make sure keepalive are both 
off.
If you want to have keepalive on, set the timeout to be the same. Mismatching 
of keepalive settings (on all the servers for your web site, including proxy) 
might cause "connection reset" errors, depending on timing.


> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Keith Fetterman
> Sent: Thursday, May 31, 2007 7:58 AM
> To: General Discussion for the Resin application server
> Subject: Re: [Resin-interest] Connection Reset message
>
>
> Hi Scott,
>
>  >
>  > You might double check the timeouts and netstat between Resin and
>  > Apache.  It sounds like something is timing out incorrectly.
>  >
>
> Are the timeouts specified in Resin or Apache or are they native to
> Linux?  I know netstat is a Linux command.
>
> I have narrowed the problem down to the pop-up blocking feature in
> Symantec's Norton Internet Security (NIS) 2007 Add on pack.  When this
> is turned off or disabled, the problem goes away.  If I turn
> it on, then
> pages are frequently not displayed in IE or I get the connection reset
> message in firefox.
>
> The weird thing is is that I never see this problem with
> other Web sites
> when the pop-up blocking is enabled.  The Go2marine.com web site does
> not use pop-up windows (new windows) except when a user
> clicks for more
> information, help, etc.  So, I think the problem is definitely in NIS
> when it is scanning our pages for pop-ups.
>
> If you could recommend a Linux utility/command that I could use to
> analyze the HTTP / TCP communication while I am browsing our site with
> the pop-up blocking enabled, that would be very helpful.
>
> Thanks a lot.
>
> Keith
>
>
> Scott Ferguson wrote:
> > On May 21, 2007, at 7:15 PM, Keith Fetterman wrote:
> >
> >> I am experiencing a problem displaying pages from our Website on
> >> Windows
> >> XP computers running Symantec's Norton Internet Security 2007 (NIS
> >> 2007.)  Frequently, I will get a "Connection Reset" message in
> >> Firefox 2
> >> and "Page cannot be displayed" message in Internet Explorer 7 when
> >> I am
> >> browsing our Website.
> >>
> >> I have tried other Websites and it seems that the problem
> only occurs
> >> with our Website, http://www.go2marine.com
> >>
> >> Our Web server is running RedHat Enterprise 3. We are running Resin
> >> pro
> >> 3.0.23 with Apache 2.0.46 front end.
> >>
> >> Has anyone else experienced this problem with Resin or
> Apache & Resin
> >> and NIS 2007?  If so, please share how you fixed it or what the
> >> cause of
> >> the problem might be.
> >
> > You might double check the timeouts and netstat between Resin and
> > Apache.  It sounds like something is timing out incorrectly.
> >
> > -- Scott
> >
> >> Thanks,
> >> Keith
> >>
> >> --
> >> -
> >> Keith Fetterman  206-780-5670
> >> Mariner Supply, Inc. [EMAIL PROTECTED]
> >> http://www.go2marine.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
>
> --
> -
> Keith Fetterman  206-780-5670
> Mariner Supply, Inc. [EMAIL PROTECTED]
> http://www.go2marine.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 cluster performance drops with number of nodes

[Gary Zhu]

One advantage of cluster is for failover.

You might get performance gain when you maxed out CPU time on each of the 
physical servers. But if you have 95% idle time when running jmeter on single 
server configuration, it won't help you if you run it on 2 server cluster mode.


However, you brought up a good topic, I am also interested in the performance 
data on Resin cluster.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of MORAWETZ Martin
Sent: Friday, May 25, 2007 10:32 AM
To: General Discussion for the Resin application server
Subject: [Resin-interest] Resin cluster performance drops with number of nodes



Hallo,

I'm evaluating the resin-cluster capabilities. My problem is
that with the current setup using just one node performes
much better than having two nodes running.

The setup is:
Two apache server as frontend, I use the mod_caucho
module as load-balancer, two resin server. One Apache
and one resin instance is running on one physical server.

I tested the performance with Jmeter. Throughput with one
resin node running is about the double of the throughput
when I use both resin nodes (same load-Jmeter setup / 80 Users).
I was expecting an increased throughput having 2 nodes running.

Could that be a configuration issue? What are common
reasons for that behavior? Any ideas?

Regards
Martin

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

Re: [Resin-interest] mod_caucho and resin 2.1.17 and sockets

[Gary Zhu]

On the issue of tcp connection (client <-->apache)  on CLOSE_WAIT for a long 
time: unfortunately, I don't know how to tune it on Linux. But I tune this down 
to 10 seconds  on Solaris (tcp_time_wait). This was recommended when I was on 
BEA land, for high traffic web site, with a lot of people come and go. That 
would reduce the number of lingering (CLOSE_WAIT) connections.  Assuming you 
are not using keep alive.

If you haven't changed TCP buffer size, then, you should. That will get your 5M 
data from resin to apache quicker.  Default buffer sizes are too small for 
'real' application.

Update  /etc/sysctl.conf with sample values (adjust them accordingly)  and then 
do "sysctl -p"
(http://dsd.lbl.gov/TCP-tuning/linux.html)

# increase TCP max buffer size
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
# increase Linux autotuning TCP buffer limits
# min, default, and max number of bytes to use
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

You can find your current settings by "sysctl -a"



From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of okrische [EMAIL 
PROTECTED]
Sent: Friday, May 25, 2007 7:57 AM
To: resin-interest@caucho.com
Subject: [Resin-interest] mod_caucho and resin 2.1.17 and sockets

Hello everyone,

i face a problem with

- apache-2.0.59-prefork as httpd,
- mod_caucho from resin 2.1.17 and
- Linux Debian Etch (2.6.18-4-amd64)

The httpd uses the mod_deflate module to compress the output. It delivers
the output in chunks to the client, as far as i can see.

This is the scenario:

Resin passes the output for a huge page (e.g. 5MB) back to mod_caucho.
mod_caucho passes it to the httpd.
The httpd delivers the compressed chunks to the client.

So far so good.

But now the client decides "i have got everything i need", and "pushes the
stop button".
So not everything from those 5MB have been received by the client.

a) the socket "client <-> httpd" on httpd server goes into 'CLOSE_WAIT'
("The remote end has shut down, waiting for the httpd socket to close")

b) the socket "mod_caucho" <-> "resin" on httpd server is 'ESTABLISHED'
and has data in its tcp input queue
(can not pass the content to httpd anymore?)

c) the socket "resin <-> mod_caucho" on resins server is 'ESTABLISHED'
 and has data in its tcp output queue
(can not pass the content to mod_caucho on httpd server)

But for any reason, as long as the socket from a) stays in CLOSE_WAIT,
the connection from b) can not be re-used for new requests. It just hangs.

So, if more clients do the same as above, earlier or later all connections
to the Resin are busy.

Does someone know this kind of problem and has some ideas to share?

Why the httpd could stay so long in CLOSE_WAIT? Why it could not shut down
and send his FIN?

Can the mod_caucho recognize, that the socket from its httpd process has
been closed by the remote client
and could release all ressources? So mod_caucho can go on with the next
request from another httpd process?

Or is mod_caucho bound to one httpd process as long this httpd process
"lives" ?

Thanks for some ideas or tips or hints.

Olaf Krische
--
View this message in context: 
http://www.nabble.com/mod_caucho-and-resin-2.1.17-and-sockets-tf3816644.html#a10804724
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 can't run as different user?

[Gary Zhu]

Quick question below:

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Scott Ferguson
> Sent: Wednesday, April 25, 2007 11:35 AM
> To: General Discussion for the Resin application server
> Subject: Re: [Resin-interest] Resin can't run as different user?
> 
> 
> 
> On Apr 25, 2007, at 11:28 AM, Nick Johnson wrote:
> 
> > I've been Googling all morning, but there's a huge amount of noise
> > relative to signal.
> 
> Which version of Resin is this with? You might want to check 
> with the  
> new snapshot as well.
> 

In general, does the snapshot version always represent(or close to) the 
upcoming release ?
More specifically, can I assume I can get some of the 3.1.1 features (like 
thread pool) or some other bug fixes being done(or mentioned) sometime ago, 
from 4/24 snapshot version ?  

I understand snapshot version is not production release.


Gary Zhu




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

Re: [Resin-interest] Resin 3.0.x, 64bit CPU and Linux

[Gary Zhu]

The ONLY catch is to make sure you have 64bit enabled JVM and configure your 
resin to be 64 bit enabled.
 
For resin configure, I simply edit /configure file to make sure it 
picks up 64bit. It's faster than reporting a resin bug saying 64bit was NOT 
enabled on certain platforms -- by the way, there were a couple of those bugs.

Good luck
Gary Z.

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Keith Fetterman
> Sent: Tuesday, April 17, 2007 10:42 AM
> To: resin-interest@caucho.com
> Subject: [Resin-interest] Resin 3.0.x, 64bit CPU and Linux
> 
> 
> We currently run resin 3.0.19 in production on a single x86 
> 32 bit CPU 
> running Red Hat Enterprise 3 Linux.
> 
> We are thinking about upgrading the hardware to a 64 bit CPU 
> so we can 
> leverage the expanded memory footprint of the JVM.  We will 
> continue to 
> use Linux.
> 
> Is anyone experiencing problems running Resin 3.0.x on the 64 bit 
> Intel/AMD servers running Linux.  If so, please share your 
> experiences 
> with me.  I would like to know if this is a good move or not.
> 
> Thanks,
> Keith
> 
> -- 
> -
> Keith Fetterman  206-780-5670
> Mariner Supply, Inc. [EMAIL PROTECTED]
> http://www.go2marine.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] one resin, one host, but two ports?

[Gary Zhu]

Resin.conf is for the configuration of resin on a particular host, if you want 
to deploy your application onto different hosts, then treat it as an deployment 
issue. 

One way to address different deployments  is to have your ant do the job:

ant deploy-windows_host# generate resin.conf file with file path relevant 
to the host windows_host, and copy resin.conf along with your war files to 
windows_host
ant deploy-linux_host# generate another resin.conf, copy the files to 
linux_host
 

The flexibility(capability of  ) in resin.conf is mainly for 
configuring single physical host to facilitate multiple virtual hosts.

I wouldn't go into the trouble to mix  single host configuration issue with 
deployment (on to different hosts) issue.



> -Original Message-
> From: [EMAIL PROTECTED]
> [ mailto:[EMAIL PROTECTED] Behalf Of Jay Ballinger
> Sent: Wednesday, April 04, 2007 1:03 PM
> To: General Discussion for the Resin application server
> Subject: Re: [Resin-interest] one resin, one host, but two ports?
>
>
> Scott,
>
> Thanks, again, for giving me a hand.
>
> The setup that includes ${host.regexp[1]} was something I found while
> poking around your documentation. I figure that it is referencing the
>  expression and giving me the second element. When
> I do that in the  directive - and include the port - it
> didn't work for me. When I get a chance, I'll try repeating the actual
> regexp, like you did in your example, and see if that works.
>
> What I was trying to accomplish was allowing the port to be
> configured, rather than hard-wired, and combining that with the
> wildcard regexp to answer any request presented to that port.
>
> I must say that this exercise has been ... challenging and rewarding.
> We're running ResinPro3.0.x on many windows hosts, but wanted to
> employ Resin3.1 on a linux host in a very flexible manner for this
> particular project. Between the config, the host directives, and the
> port forwarding (to not run as root), it requires that you wrestle the
> OS and Resin into the format that will work. I'll have to document the
> setup in a blog somewhere for others to review.
>
> + jay
>
>
> On 4/3/07, Scott Ferguson <[EMAIL PROTECTED]> wrote:
> >
> > On Apr 2, 2007, at 1:22 PM, Jay Ballinger wrote:
> >
> > > Scott,
> > >
> > > Thanks, very much, for your help. The following does work...
> > >
> > > 
> > >root-directory="/some/path/webapp/ROOT"/>
> > > 
> > >
> > >
> > > 
> > >   /some/other/path
> > >root-directory="/some/other/path/webapp/ROOT"/>
> > > 
> > >
> > >
> > > ...but, is there any way to sneak in a variable in the regexp?
> >
> > Not in that attribute.
> >
> > > regexp="[^:]+:${someVar}" certainly doesn't work. I've
> been trying to
> > > find other escaping mechanisms, but haven't been
> successful. I've also
> > > tried...
> >
> >
> > >
> > >
> > > 
> > >   ${host.regexp[1]}:${someVar}
> > >   /some/other/path
> > >root-directory="/some/other/path/webapp/ROOT"/>
> > > 
> >
> > I'm not sure what the intention of that one is.  You might try:
> >
> > 
> >[^:]+:${someVar}
> >
> > It looks like the host-alias-regexp does allow variables.  (I'm not
> > sure if this will work, though.  It's not a case we've tested.)
> >
> > -- Scott
> >
> > >
> > > ...but resin doesn't act like I expected. It seems to
> want the port
> > > number in the  tag.
> > >
> > > I'm about this > < close to having this new server environment
> > > configured. This is my last hiccup, so far.
> > >
> > >
> > > + jay
> > >
> > >
> > >
> > > On 4/2/07, Scott Ferguson <[EMAIL PROTECTED]> wrote:
> > >>
> > >> On Apr 2, 2007, at 10:27 AM, Jay Ballinger wrote:
> > >>
> > >>>
> > >>>
> > >>> My hope would be to use something like the following...
> > >>>
> > >>> 
> > >>>   
> > >>> 
> > >>>
> > >>> 
> > >>>   
> > >>> 
> > >>>
> > >>> ...but this results in the 'blank' host directive serving all
> > >>> requests
> > >>> - http and https.
> > >>
> > >> Ok, that makes sense.  Actually, I'm surprised that idea
> hasn't come
> > >> up before.
> > >>
> > >> You could try using the regexp as a workaround
> > >>
> > >> 
> > >> 
> > >>
> > >> -- Scott
> > >>
> > >>>
> > >>> Declarations like...
> > >>>
> > >>> 
> > >>>   
> > >>> 
> > >>>
> > >>> 
> > >>>   
> > >>> 
> > >>>
> > >>> ...result in the server launching, but the user gets a
> 404 for each
> > >>> request as it seems that nothing is mapped as resin
> would expect to
> > >>> find it.
> > >>>
> > >>> I even tried silly entries like "*" and "*:8443", but
> those resulted
> > >>> in stack traces on server startup.
> > >>>
> > >>>
> > >>> So when I said, "I was hoping to not have to set a host name at
> > >>> all",
> > >>> I really meant that I was hoping to not lock myself in to an
> > >>> explicit
> > >>> host name nor lock myself into a long list of host-alias names

Re: [Resin-interest] CMP 2.1 Relationship Not Closing Connections

[Gary Zhu]

I don't see anything wrong with your configuration, except one comment: unless 
you are running distributed databases, you really don't need XADataSource, just 
DataSource is fine.  That might save you some troubles, in case your JDBC 
driver has bugs in connection handling for 'multi-database' setup (I am not 
familiar with postgresql).
 
Again, the result of CMP failure does not mean CMP is the cause of connection 
leaks.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Tim Riley
Sent: Tuesday, February 27, 2007 9:34 AM
To: General Discussion for the Resin application server
Subject: Re: [Resin-interest] CMP 2.1 Relationship Not Closing Connections



Hrmmm

Maybe I have resin configured wrong then, because this did not occur in resin 
2.1.17 would you mind taking a look?

 

resin.conf

 



...

  

 jdbc/appp

 

jdbc:postgresql://localhost:5432/appp

xx

xx

 

 8

 20

 30s

  

  



   java:comp/env/appp

   java:comp/env/jdbc/appp

   /usr/local/feds/web/appp/WEB-INF



  

 



 

web.xml



...

  

jdbc/appp

javax.sql.XADataSource

Container

  

 



 

The following keeps occurring in my logs

[12:16:04.439] Closing dangling connections.  All connections must have a 
close() in a finally block.

[12:16:04.517] java.lang.IllegalStateException: Connection [EMAIL PROTECTED] 
was not closed. Connections must have a close() in a finally block.

[12:16:04.517]  at 
com.caucho.jca.UserTransactionImpl.abortTransaction(UserTransactionImpl.java:497)

[12:16:04.517]  at 
com.caucho.jca.UserTransactionProxy.abortTransaction(UserTransactionProxy.java:183)

[12:16:04.517]  at 
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:193)

[12:16:04.517]  at 
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229)

[12:16:04.517]  at 
com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:274)

[12:16:04.517]  at 
com.caucho.server.port.TcpConnection.run(TcpConnection.java:511)

[12:16:04.517]  at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:520)

[12:16:04.517]  at com.caucho.util.ThreadPool.run(ThreadPool.java:442)

[12:16:04.517]  at java.lang.Thread.run(Thread.java:595)

[12:16:40.445] Closing dangling connections.  All connections must have a 
close() in a finally block.

 

I would appreciate any help or guidance you could provide.

 

Thanks

Tim


  _  


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gary Zhu
Sent: Tuesday, February 27, 2007 12:16 PM
To: General Discussion for the Resin application server
Subject: Re: [Resin-interest] CMP 2.1 Relationship Not Closing Connections

 

Most likely the other parts of your code are leaking the DB connections. CMP is 
not likely the source of leak.

We use CMPs extensively, our site is stable, with an over $10 million worth of 
single day on-line transactions.

We are currently running resin 3.0.22.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Tim Riley
Sent: Tuesday, February 27, 2007 8:39 AM
To: resin-interest@caucho.com
Subject: [Resin-interest] CMP 2.1 Relationship Not Closing Connections

My name is Tim Riley and I currently upgrading from 2.1.17 to 3.0.23 and I use 
CMP 2.1 (EJB 2). I do not want to upgrade from EJB 2 to EJB 3 however I ran 
into this issue http://bugs.caucho.com/bug_view_page.php?bug_id=1286. Does 
anyone know if there is a work around to this issue or if it is planned to be 
fixed in an up coming release. I am also using Postgresql 8.1.

 

Thanks

Tim

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

Re: [Resin-interest] CMP 2.1 Relationship Not Closing Connections

[Gary Zhu]

Most likely the other parts of your code are leaking the DB connections. CMP is 
not likely the source of leak.
We use CMPs extensively, our site is stable, with an over $10 million worth of 
single day on-line transactions.
We are currently running resin 3.0.22.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Tim Riley
Sent: Tuesday, February 27, 2007 8:39 AM
To: resin-interest@caucho.com
Subject: [Resin-interest] CMP 2.1 Relationship Not Closing Connections



My name is Tim Riley and I currently upgrading from 2.1.17 to 3.0.23 and I use 
CMP 2.1 (EJB 2). I do not want to upgrade from EJB 2 to EJB 3 however I ran 
into this issue http://bugs.caucho.com/bug_view_page.php?bug_id=1286. Does 
anyone know if there is a work around to this issue or if it is planned to be 
fixed in an up coming release. I am also using Postgresql 8.1.

 

Thanks

Tim

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

Re: [Resin-interest] Resin... ?????

[Gary Zhu]

Since it's RedHat Linux, I'd double check the OS resource limits.

Try  "/sbin/sysctl -a"  to see if those values are good enough for you, or 
simply edit /etc/security/limits.conf, you can change nofile, nproc, stack, 
data, etc..  You can even grant a specific (Resin) user to have "soft nofile" 
and "hard nofile", in limits.conf.   You will have to reboot your Linux after 
modifying limits.conf -- assuming you know Linux Sys. Admin., otherwise, please 
do not touch limits.conf.

Also, check your /var/log/messages file (if your system is configured 
correctly), that might give you clue on what failures you had, memory 
allocation or open files ?

Gary 



> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Scott Ferguson
> Sent: Monday, January 15, 2007 9:13 AM
> To: General Discussion for the Resin application server
> Subject: Re: [Resin-interest] Resin... ?
> 
> 
> 
> On Jan 14, 2007, at 9:06 PM, Akila Amarathunga wrote:
> 
> > Hi Knut,
> >
> > JVM sets the -Xss to 1 Megabytes.. It has open 1028 files 
> (REG) at the
> > time of giving the error..
> > At the moment my app open lots of Jar files which uses 10 mb of
> > space...
> >
> > java27042   xxx844rREG 9,1 1189992
> > 11814189//WEB-INF/lib/wicket-1.2.1.jar
> >
> > Am I geeting the 503 error cos of that ?
> 
> Assuming your file descriptor limit is near 1024, that's likely.  Do  
> you know anything that might be keeping those file 
> descriptors open?   
> I'm not familiar with wicket.
> 
> -- Scott
> 
> >
> > Thanks,
> > Akila
> >
> > On Sun, 2007-01-14 at 12:13 -0800, Knut Forkalsrud wrote:
> >> You might want to try "jconsole" or something to figure 
> out if you're
> >> running out of heap space.  Depending on what your application  
> >> does 512
> >> MBytes may not be enough.  With 2GB of physical RAM on the 
> machine  
> >> you
> >> can probably afford to allow the JVM more memory.
> >>
> >> When you get close to 1024 open files, try to figure out what  
> >> those file
> >> handles represent, with a command like "lsof -p 32335 | awk  
> >> '{ print $5
> >> }' | sort | uniq -c" where 32335 is the process id of the JVM.   
> >> Are they
> >> all files (REG) or sockets (IPv4/IPv6)?
> >>
> >> A long shot: I assume the stack size you report is from "ulimit -s"
> >> which reports in kilobytes.  Resin's startup script by default  
> >> sets the
> >> "-Xss" switch for the JVM to limit the stack size to 1 Megabyte.   
> >> Make
> >> sure that is the case for your installation as well, for 
> example with
> >> "cat /proc/32335/cmdline | tr \\0 \\n | fgrep -- -Xss" 
> where 32335 is
> >> the Resin JVM process id.  Otherwise you have up to 2048 threads *
> >> 10MB/thread = 20GByte of address space.  If you're on a 32 
> bit CPU  
> >> that
> >> won't work.  You're likely to have problems at 2GByte (the OS,  
> >> JVM, etc
> >> want some address space too), which means about 200 simultaneous  
> >> threads.
> >>
> >> -Knut
> >>
> >>
> >> [EMAIL PROTECTED] wrote:
> >>> hi All,
> >>>
> >>> Well I used resin for few months now ... but i'm really sorry to  
> >>> say its a
> >>> bad experience. At the moment my settings are,
> >>> Server - RHEL (with 2 pros.)
> >>> RAM - 2 GB
> >>> Resin-pro-3.0.21
> >>> stack size 10240
> >>> Heap - 256 MB - 512 MB
> >>> Open files limit (ulimit -n) - 2048
> >>> Threads - 2048
> >>>
> >>> If the number of files open by resin exceeds (used lsof) 1024,  
> >>> apache
> >>> gives 503 server down for maintenance error.
> >>> Please tell me what I'm doing wrong here..?
> >>>
> >>> Regards,
> >>> Akila
> >>>
> >>>
> >>> ___
> >>> 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 on db based distributed session

[Gary Zhu]

Jacky,
 
Whatever you quoted (in red) does not apply to your case, because in most of 
your situations, you did not have another Resin instance to be notified, as in 
"it will notify the owner of the change" At some point of step 2 and 
step 5, you did not even have any Resin instance running.
 
But that does not mean this is not a problem. JDBC based session store should 
always contain the last known valid state, no matter which server was running.  
I noticed that your case has been filed into Resin bug 
http://bugs.caucho.com/view.php?id=1544 
<http://bugs.caucho.com/view.php?id=1544.> .
 
So, stop worrying.
 
 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jacky
Sent: Monday, January 15, 2007 2:17 AM
To: General Discussion for the Resin application server
Subject: Re: [Resin-interest] Question on db based distributed session


Eric? Sam?

Warm regards,

Jacky Wong

Software Engineer

Qinetics Solution Berhad


Jacky wrote: 

Dear all,

First of all, thanks for all the attentions. Greatly appreciated.

Josh,
- Please forgive me as i do not understand your "have your cake and eat it too" 
metaphor :S
- I'm trying to implement the database backed distributed sessions as shown in 
http://www.caucho.com/resin-3.0/config/sessions.xtp and i dont take "turn it 
off" as a solution, at least not until i fully understand that this will not 
work.
- You may be right with the clock of server A and server B not in sync, I'll 
have it checked..

Eric,

- Yes, resin knows about my load balanced cluster (refer to the specific 
settings below)
- I'm using apache with mod_caucho as the load balancer, is this inside or 
outside? :D
- No, i'm not using . I didnt' think that i need (but i'll 
give it a shot). Referring to 
http://www.caucho.com/resin-3.0/config/sessions.xtp, there is a paragraph 
stating this:

"For efficiency, the owning JVM keeps a cache of the session value, so it only 
needs to query the database when the session changes. If another JVM stores a 
new session value, it will notify the owner of the change so the owner can 
update its cache. Because of this notification, the database store is 
cluster-aware."

my specific settings:

#Apache snippet

  DocumentRoot /www/appA
  ServerName somedomain.com
  DirectoryIndex index.jsp
  ResinConfigServer 192.168.1.1 6802
  ResinConfigServer 192.168.1.2 6802
  CauchoStatus yes

  # do not remove, otherwise apache will serve the jsp source code once resin 
is down
  AddHandler caucho-request .jsp


# Resin snippet


  120s
  
  


  

  jdbc/session

  


  

  
  180
  
  


  


Sam,

I have 2 questions:

Quote:



At this point, A (the primary) will contact B to try to get any updates

to the session that have been made.  Since B is down, A cannot get the

session from it. 



- Since i use , shouldn't it try to get from B, but 
couldn't it get from the DB?



Quote:



So it has to go with the outdated session that it

has, because it cannot get the updated session from B.



- Please do correct me if i'm wrong, referring to this:



"If another JVM stores a new session value, it will notify the owner of the 
change so

the owner can update its cache.  Because of this notification, the database

store is cluster-aware."



- When B logs out my session, shouldn't it updates A's cache and the database 
at the same time?

- Is it because i didn't use  ??



Gary Zhu,



Quote:

Even if server A and server B are configured to use the same database on server 
C, for a particular user session (say session id: abcDGs299928), server A and 
server B will have two different database entries of the session data, am I 
getting it right ?



- I have thought of this as well when i look at the records in the table 
persistent_session of my mysql database.

- But still...



"If another JVM stores a new session value, it will notify the owner of the 
change so

the owner can update its cache.  Because of this notification, the database

store is cluster-aware."



PS:

Apache/2.0.55

Resin professional 3.0.19.



Thanks all !!

  
Warm regards,

Jacky Wong

Software Engineer

Qinetics Solution Berhad

  


Sam wrote: 

1. I start server A and login to my application

  



At this point, A will get your request and will become your primary

server, and B will be your secondary server.



  

2. I stop Server A and start Server B

3. I continue to work in the browser, my session stays intact and i 

can proceed normally

  



At this point, you are using secondary server B.  Your session updates

are saved on B.



  

4. I logout from my application and logout successfully cleared my 

session variables (notice this from app log)

5. I stop Server B and s

Re: [Resin-interest] Question on db based distributed session

[Gary Zhu]

Thank you Sam, for the explanation.

Even if server A and server B are configured to use the same database on server 
C, for a particular user session (say session id: abcDGs299928), server A and 
server B will have two different database entries of the session data, am I 
getting it right ?


> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Sam
> Sent: Monday, January 08, 2007 1:17 PM
> To: General Discussion for the Resin application server
> Subject: Re: [Resin-interest] Question on db based distributed session
> 
> 
> > >1. I start server A and login to my application
> 
> At this point, A will get your request and will become your primary
> server, and B will be your secondary server.
> 
> > >2. I stop Server A and start Server B
> > >3. I continue to work in the browser, my session stays 
> intact and i 
> > >can proceed normally
> 
> At this point, you are using secondary server B.  Your session updates
> are saved on B.
> 
> > >4. I logout from my application and logout successfully cleared my 
> > >session variables (notice this from app log)
> > >5. I stop Server B and start Server A
> 
> > >6. I try to type a password protected page in the browser 
> and i *CAN 
> > >ACCESS* the protected page
> 
> At this point, A (the primary) will contact B to try to get 
> any updates
> to the session that have been made.  Since B is down, A cannot get the
> session from it.  So it has to go with the outdated session that it
> has, because it cannot get the updated session from B.
> 
> -- Sam
> 
> ___
> 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] EJB and Resin 3.1

[Gary Zhu]

If you were using the snapshot version 3.1.s061203, you might ran into a Resin 
bug. 

I found my EJB3 stopped working on this version and noticed Resin sample 
stateless EJB not working either. 

By the way, Markus, you can find sample code under:

/webapps/resin-doc/tutorial/ejb-stateless/WEB-INF/classes/example/...

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Markus Wolf
> Sent: Friday, December 08, 2006 8:48 AM
> To: General Discussion for the Resin application server
> Subject: Re: [Resin-interest] EJB and Resin 3.1
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi,
> 
> > Do you mean simply having a "web application" as a place 
> where you deploy
> > your EJBs that are then accessed from other web 
> applications? Or do you
> > mean simply not packaging your web application as an 
> .ear/.war file and
> > still have your EJBs deployed?
> > 
> I've meant to create an EAR package containting WARs and 
> EJB-JARs based
> on annotations and EJB3.
> But instead of using the Dependency Injection I want to do a JNDI
> lookup, because we want to access the EJBs from Quercus.
> 
> If we don't specify a name for a SessionBean in the annotation what is
> the default JNDI name Resin deploys them at?
> 
> If I find some time I'll send a demo application package next week.
> 
> Thanks
> Markus
> - --
> NMMN - New Media Markets & Networks
> http://www.nmmn.com/
> Langbehnstrasse 6
> 22761 Hamburg
> Tel. 040 284 118 - 720
> Fax 040 284 118 - 999
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.3 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFFeZclDBHISU1oEKERAq1iAJ9ONsfVpqgn+S3Id6079GmEdVWw+ACfdQFm
> LAIoBM2HA/uk949rbuXYXIA=
> =zBtw
> -END PGP SIGNATURE-
> 
> ___
> 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