Re: [Resin-interest] Database Pooling
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 database within it, jndi-name, driver, 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.comhttp://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?
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?
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?
Not sure whether Jetty is doing hot-deploy or not.
With Resin:
web-app
!-- when the timestamp of your war file changed, Resin will (cold)
redeploy it --
dependency path={one of your war files}
/web-app
-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] code too large for try statement error!
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
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 character-encodingUTF-8/character-encoding 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] Classpath problem
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\libjava 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\libjava -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\libset 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\libls 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)
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
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
access-log path=log/access.log
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:
access-log path=log/access.log
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] Connection Reset message
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] clearing cache manually or in code
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: allow-admintrue/allow-admin 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 ---BeginMessage--- 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] Resin can't run as different user?
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
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 resin_home/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?
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 host regexp... ) 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
host regexp=... expression and giving me the second element. When
I do that in the host-name 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...
host id= root-directory=/some/path
web-app id=/
root-directory=/some/path/webapp/ROOT/
/host
host regexp=[^:]+:8443
root-directory/some/other/path/root-directory
web-app id=/
root-directory=/some/other/path/webapp/ROOT/
/host
...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=[^:]+
host-name${host.regexp[1]}:${someVar}/host-name
root-directory/some/other/path/root-directory
web-app id=/
root-directory=/some/other/path/webapp/ROOT/
/host
I'm not sure what the intention of that one is. You might try:
host id=www.foo.com
host-alias-regexp[^:]+:${someVar}/host-alias-regexp
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 host 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...
host id= root-directory=/some/path
web-app id=/ root-directory=/some/path/webapp/
ROOT/
/host
host id=:8443 root-directory=/some/other/path
web-app id=/ root-directory=/some/other/path/
webapp/ROOT/
/host
...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
host regexp=[^:]+:8443 ...
/host
-- Scott
Declarations like...
host id=:8080 root-directory=/some/path
web-app id=/ root-directory=/some/path/webapp/
ROOT/
/host
host id=:8443 root-directory=/some/other/path
web-app id=/ root-directory=/some/other/path/
webapp/ROOT/
/host
...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
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
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 host id= root-directory=/usr/local/base/web ... database jndi-namejdbc/appp/jndi-name driver type=org.postgresql.Driver urljdbc:postgresql://localhost:5432/appp/url userxx/user passwordxx/password /driver prepared-statement-cache-size8/prepared-statement-cache-size max-connections20/max-connections max-idle-time30s/max-idle-time /database web-app id=appp document-directory=/usr/local/base/web/appp/ ejb-server jndi-namejava:comp/env/appp/jndi-name data-sourcejava:comp/env/jdbc/appp/data-source config-directory/usr/local/feds/web/appp/WEB-INF/config-directory /ejb-server /web-app /host web.xml webapp ... resource-ref res-ref-namejdbc/appp/res-ref-name res-typejavax.sql.XADataSource/res-type res-authContainer/res-auth /resource-ref /webapp 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] Question on db based distributed session
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 always-load-session. 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 VirtualHost *:80 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 /VirtualHost # Resin snippet !-- Yes i'm aware that client-live-time and read-timeout is not supposed to be manually configured -- cluster client-live-time120s/client-live-time srun id=a host=192.168.1.1 port=6802 index=1 read-timeout=120s/ srun id=b host=192.168.1.2 port=6802 index=2 read-timeout=120s/ /cluster persistent-store type=jdbc init data-sourcejdbc/session/data-source /init /persistent-store host id=somedomain.com root-directory=/www/appA web-app id=/ document-directory=/www/appA session-config !-- 3 hour timeout -- session-timeout180/session-timeout use-persistent-store/ always-save-session/ /session-config servlet-mapping url-pattern=/servlet/* servlet-name=invoker/ /web-app /host 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 always-save-session, 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 always-load-session ?? 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
Re: [Resin-interest] EJB and Resin 3.1
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: resin.home/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
