Re: [Resin-interest] too many open files
On Sep 18, 2006, at 10:34 AM, David Hansen wrote: Following the suggested lsof idea, it appears that Resin is continually opening file descriptors to the same jar. java 11390root 33u REG8,3 1886356 503420273 /opt/deployments/jars/wtcls.jar about 900 more of these referencing wtcls.jar Thanks. How is that .jar configured in the resin.conf? Can you give the class-loader section of the resin.conf that references it? In particular, if it's defined in a web-app-default or defined directly in a web-app, but some other detail might matter. -- Scott java 11390root 1020r REG8,3 1886356 503420273 /opt/deployments/jars/wtcls.jar java 11390root 1021r REG8,3 1886356 503420273 /opt/deployments/jars/wtcls.jar java 11390root 1022r REG8,3 1886356 503420273 /opt/deployments/jars/wtcls.jar java 11390root 1023r REG8,3 1886356 503420273 /opt/deployments/jars/wtcls.jar When the number of open files reaches the kernel's max, Resin falls over and restarts itself, then begins the process again. Additional information( if it helps ): wtcls.jar is our own code. it is symlinked to resin_home/lib/local/ wtcls.jar If we remove the symlink, resin will do the same thing, but with a different jar file( in this case, wicket.jar, from the wicket project ) Any help solving this problem would be appreciated, thanks. - Dave ___ 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] throttle filter
On Sep 18, 2006, at 10:39 AM, sksamuel wrote: How do I get a thread dump without using jstack because that doesn't work on Fedora 3 unfortunately (just my luck). It's fixed in Mustang I think. kill -QUIT on the java process. kill -QUIT is a bit better than jstack, actually, since it shows the thread names and any locks the thread has, which is really nice. The thread dump output should be in jvm.log. Ok done. I have hosted the thread dump here: Seems to be a lot stuck in ThrottleFilter but I suppose you'll know straight away if that's normal. I might try removing that filter anyway. That looks like some kind of problem with ThrottleFilter. The bug report is at http://bugs.caucho.com/view.php?id=1356 -- Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Bizarre CMP behavior
On Sep 27, 2006, at 9:47 AM, David Hansen wrote: We are getting some really odd behavior in production with Resin's CMP. Intermittently, resin begins throwing NPE's in its Amber code Thanks, I've added it as http://bugs.caucho.com/view.php?id=1380 ( why Resin is using Amber for 2.x beans is another question, but I'll save that for another time ). Because one persistence engine is easier to maintain than two. The differences are relatively minor, with the exception of the syntax of the inputs. -- Scott For example: [09:01:47.850] null [09:01:47.850] java.lang.NullPointerException [09:01:47.850] at com.caucho.amber.manager.AmberConnection.parseQuery (AmberConnection.java:1286) [09:01:47.850] at com.caucho.amber.manager.AmberConnection.prepareQuery (AmberConnection.java:1268) [09:01:47.850] at com.caucho.amber.manager.AmberConnection.prepareQuery (AmberConnection.java:1235) [09:01:47.850] at _ejb.InternalUserPermissionHome.InternalUserPermissionBean__EJB $LocalHome.findByUser(InternalUserPermissionBean__EJB.java:390) [09:01:47.850] at delegates.security.PermissionsDelegate.canYou (PermissionsDelegate.java:21) it appears to happen exclusively with finders. We have verified that we are NOT passing nulls into any of the finders when this occurs. Looking at the code, it looks like an internal AmberPersistenceUnit object is for some reason null. Any help on this would be appreciated, thanks. - Dave ___ 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] logging with log4j!
On Oct 4, 2006, at 12:07 PM, Swaminathan Subramanian wrote: Hi! I upgraded from Resin 2.1 to Resin 3.0.21. The web application uses log4j to log messages. When I moved the code over, I changed the resin.conf file to include fine level logging. But, I am not seeing any application level log messages. Moreover, I have two web applications and I need to log these separately. I tried to add logging under each web application. The log files got created but again there were no application level messages. Am I missing something? Someone else might need to answer about log4j. For Resin's configuration, there was a bug/confusion introduced in 3.0.21. You'll probably need to have two separate configuration items: a log and a logger. The log is equivalent to a java.util.logging.Handler. The logger is equivalent to java.util.logging.Logger. With 3.0.21, the level doesn't automatically configure the logger's level (this is a mistake.) So you might need something like: resin xmlns=... log name= level=finer path=log/debug.log timestamp=[%H:%M:% S.%s] / logger name= level=info/ logger name=com.foo.mypackage level=finer/ You can have different logging levels in each web-app. Just add the logger with the appropriate level in each one. web-app xmlns=... logger name=com.foo.mypackage level=finer/ ... web-app xmlns=... logger name=com.foo.otherpackage level=finest/ (The whole environment/logging level is tricky internally, so if you don't see appropriate behavior when setting the level in a resin- web.xml it is possible there would be a Resin bug.) You can test the logging with the following jsp test.jsp %@ page import=java.util.logging.* % % Logger log = Logger.getLogger(com.foo.mypackage.Test); log.info(info-level test); log.fine(fine-level test); log.warning(warning-level test); % -- Scott Thanks in advance! SS __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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] Unicode characters supplanted by HTML 4.0 entity references
On Oct 9, 2006, at 10:58 AM, Michael Stevens wrote: Hello, I am seeing behavior in Resin where unicode characters are being replaced by HTML entity references in the page response. Can you check for any filters? Resin doesn't automatically escape anything. The only processing Resin does is for PrintWriter (e.g. JSP) converting 16-bit chars to 8-bit binary. -- Scott For example, when the unicode character ç (ccedil if it's not appearing correctly) appears in the JSP source, when it's compiled into a servlet, it appears in the servlet source as the escaped Unicode reference \u00e7, and then when the page is served by Resin, it is again transformed in the page source into the HTML entity reference #231 (with semicolon of course). Another example: using JSF, a JSP source will contain a Faces tag that gets a string from a backing bean. If the string contains the Unicode character ç (ccedil), when Resin serves the page it will transform the character into the HTML entity reference. Does anyone know if there is some setting that is causing this entity reference transformation to occur? Is it possible to configure Resin to leave the original Unicode character unmolested? I have messed with a few character-encoding and encoding settings in various places in resin.conf, but I may be missing something. I suppose I can say that the page is correctly served as UTF-8 encoded -- the content type header specifies UTF-8 -- but actually if Resin is replacing any characters beyond the first 128 code points with HTML entity references anyway, it's a bit of a moot point. Many thanks, Michael ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] apache 2.2.3 + mod_caucho.dll on windows server 2003 x64
On Oct 7, 2006, at 11:26 AM, Jean-Francois Lamy wrote: Configuration: Windows Server 2003, 64 bit edition + resin 3.0.21 + Apache 2.2.3 When trying to configure Apache 2.2 to talk to resin, I get an error message stating that the specified module (mod_caucho.dll) could not be found. I get the message no matter whether I use setup.exe or do the change manually, and no matter whether I leave mod_caucho.dll in its original location or copy it under the apache modules directory. We need to add Apache 2.2 to the build process. It's the same source code, but a separate dll. -- Scott Any one running Apache under x64 windows with resin as back end ? 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
Re: [Resin-interest] shutdown an webapp in resin
On Oct 4, 2006, at 2:27 PM, maildli wrote: Hi, Does any body know how to shutdown a web application using Java code? I am working on a project that it does an initialization check right after an applicataion starts up, if the init failed, then the web application should be shut down automatically. Does anybody knows how to make such function call? That function is available in JMX. If you get the WebAppMXBean, you can call stop() on it. The Javadoc is at http://caucho.com/resin-javadoc/com/caucho/ management/server/WebAppMXBean.html The stop() method is part of the DeployControllerMXBean. -- Scott -- View this message in context: http://www.nabble.com/shutdown-an- webapp-in-resin-tf2385177.html#a6648741 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] configure
On Oct 12, 2006, at 7:10 PM, tllcll wrote: is there anyway for me configure without having the laster version of resin the other application is plan to run on tomcat/apache Oh, you're trying to run Resin and Tomcat at the same time? That's a little strange. For Resin, if you want to configure a virtual host, just add/change the following: resin ... server... host id=www.abc111.com root-directory/var/abc111/root-directory /host You can copy the configuration from the default host block. Or just share common information in a host-default. In other words, it should be simple to create a virtual host using Resin. The aaa would do in /var/abc111/webapps/aaa -- Scott Scott Ferguson wrote: On Oct 12, 2006, at 6:37 PM, tllcll wrote: Hi, I have installed apache/tomcat and import the war file. I have tried to run using localhost:8081, it is working... My server have another web server runnning on port 8080 with address eg.. www.abc111.com. (this will go to the index page of that web app) What do I need to set to make it able to display/run the webpage from address eg... www.abc.com111.com/aaa? You're making a terrible mistake. Go to http://www.caucho.com/download and download the latest version of Resin (3.0.21). (Or if you're brave, download Resin-3_1- snap.zip.) You'll either want to run Resin with its own internal web server, or if you want a two-tier server, use Resin as the web server and another instance of Resin as the app server. (The two tier Resin system will be easier to configure in Resin 3.1.0). -- Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest -- View this message in context: http://www.nabble.com/configure- tf2434415.html#a6788671 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] 3.0.21 vs. 3.1.snap
On Oct 28, 2006, at 2:59 AM, Thomas Moorer wrote:Is the 3.1 download production ready or should I use the 3.0.21 version?The snapshots are never production ready, so you should use 3.0.21 for now.We're trying to get 3.0.22 out this week.We've delayed 3.1.0 for another 2-3 weeks. There's an important refactoring we need to do for Quercus and we also want to spend some extra time on QA and stress testing.However, the 3.1.0 snapshot is actually pretty good. It has all of Servlet 2.5 and JSP 2.1, so now would be a good time for anyone who wants to check out JSF with Resin.-- Scott Thomas C. Moorer, Jr.Sleepycat Solutions, LLChttp://www.sleepycatsolutions.com ___resin-interest mailing listresin-interest@caucho.comhttp://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] How to control the location of the work directory
On Oct 29, 2006, at 7:48 PM, Markus Ken Moriyama wrote:
Hi Francois,
regarding the location, you can specify it in the web-app element:
web-app id='/' document-directory='bar'
work-dir/your/work_dir/path/work-dir
...
Yes, but it's normally not a good idea to change the work directory.
Configuring deletion / keeping of the work-dir - I don't think that's
possible via normal configuration, but maybe someone else can give
a hint.
Resin doesn't delete the work directory.
-- Scott
Regards,
markus
Francois Richard wrote:
Hi all,
I am looking for a way to control the followings:
1- With Resin 3.0.* how can I control the location of the “work”
directory for each web applications?
Right now I see it located in: {$WEBAPP-ROOT}/WEB-INF/work
2- With Resin 3.0.* How can I control the fact that the work
directory
is deleted or kept between resin restarts?
Thanks,
Francois Richard
-
---
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
--
--
Markus Ken Moriyama [EMAIL PROTECTED]
Development Director
Co-Founder
Eastbeam Co., Ltd.
Jingumae Happy Bldg 8F, 6-19-14 Jingumae, Shibuya-ku
150-0001 Tokyo, Japan
Tel: +81 3 5766 0874
Fax: +81 3 3499 8217
http://www.eastbeam.co.jp/
___
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] Does Resin have a built-in Proxy Server?
On Nov 7, 2006, at 4:39 AM, Daniel López wrote: In fact, it is nothing too fancy, it basically does the same that the Caucho Proxy Servlet does but it allows you to specify a list of init parameters that, working in pairs, allow you to specify a recognition regexp pattern and a replacement pattern. Something like that: Excellent. I've added it as a bug report. Another enhancement we're looking at for the proxy is to give it the same load-balancing capabilities that the resin load-balancer already uses. Your enhancement looks fairly straightforward. -- Scott filter filter-nameProxyFilter/filter-name filter-classorg.leaf.filters.ProxyFilter/filter-class init-param param-nameMATCHING_URL_APP_1/param-name param-value/ca/app/(.*).html/param-value /init-param init-param param-nameREPLACEMENT_URL_APP_1/param-name param-valuehttp://internal.com:9080/html/$1.html/param-value /init-param init-param param-nameMATCHING_URL_APP_2/param-name param-value/ca/app/(.*)/param-value /init-param init-param param-nameREPLACEMENT_URL_APP_2/param-name param-valuehttp://internal.com:9080/app/$1/param-value /init-param ... /filter You only need to make sure the mapping of the filter matches all the requests you want, and the ones that match no criteria from the init parameters simply pass through the filter untouched. Not sure how useful it will be to others, but in our case it works pretty well as it gets SiteMesh to believe that some remote pages are local resources, so they get decorated appropriately. It is an intermediate step before we migrate to a real portal solution, but time and resources forced us to get something done before schedule. Barring some implementation problems when we perform the stress tests, it is working great for us. S! D. Scott Ferguson escribió: On Nov 6, 2006, at 2:10 AM, Daniel López wrote: Before we found out about that one, we developed our own ProxyFilter, instead of a servlet, with a bit more complex URL mapping features, using regular expressions. Sounds very cool. We've been discussing the idea of integrating the ProxyFilter with the rewrite-dispatch tag like we've done for the load balancer. We have done it to be able to integrate some back-end dynamic services with a site driven by SiteMesh, and so far it works pretty well. We have to test it under heavy load yet, as we are still developing it and have not reached that phase. I thought about contributing it back to Resin, the extra regexp based mapping fatures, as I did it for our own OS framework, but I haven't had time to find out if/how Caucho handles contributions and integrate that part into the Resin servlet. A bug report detailing the configuration/features would really be great. The hard part is generally coming up with a good design or understanding what applications really need. --Scott Cheers. D. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] resin load distribution
On Nov 7, 2006, at 6:05 PM, Jacky wrote: Dear Scott, Is there anyway that the "client-weight" can be used with Apache? I'm using 3.0.29 professional.No. It's both a multithreaded issue and a testing one. Since Java is a fully-multithreaded language, and Apache/C isn't really, it's much harder to share the information across the different processes/connections in Apache than it is in Java.In addition, since it's much easier to automatically test Java, we need to keep the Apache functionality simpler than the corresponding Java functionality. Another example is failover. If the Java load-balancer tries a backend server which fails, it can retry on the next backend server. That capability is more complicated than we would want to put into Apache. In other words, the Java load-balancer will always be more capable than the Apache/mod_caucho one.-- Scott I checked the caucho site and i the only thing i can find that is most relevant to my needs is this: http://www.caucho.com/resin-3.0/install/cse-apache.xtp#balance but it does not allow me to configure the weight. please advice. Scott Ferguson wrote: On Nov 6, 2006, at 9:33 AM, Sam wrote: How can i configure one server to serve more than the other? Since 3.0.20, there is a "client-weight" option for each srun. For eaxample, the following causes server a to get used twice as much as server b: For 3.1 and later, it is called "load-balance-weight": True, but it's only available using Resin as a load balancer, not Apache/mod_caucho. -- Scott -- 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 -- Warm regards, Jacky Wong ___resin-interest mailing listresin-interest@caucho.comhttp://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 of application reload
On Nov 8, 2006, at 8:04 PM, Carfield Yim wrote: According to http://wiki.caucho.com/Losing_session , once the timestamp of web.xml change, the application will reload. However my installation of resin don't do that. I've check resin3.log but nothing special show. Anyone have any idea about that? It also depends on the dependency-check-interval. If the interval is large, then Resin won't check the web.xml very often. Also, there are some dependency checks (web.xml?) where Resin computes a CRC of the file and only updates if the crc changes. In that case, you'd need to actually modify the file (e.g. adding a space) to force the reload. By the way, I am using wicket and there is always wicket.util.watch.ModificationWatcher running to watch if the template updated. Will it affect the application reload? That should be independent. -- Scott -- View this message in context: http://www.nabble.com/Problem-of- application-reload-tf2599604.html#a7252166 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-interest Digest, Vol 5, Issue 16
On Nov 9, 2006, at 6:59 AM, sksamuel wrote: Does resin pro have any kind of monitoring that will show me which sites are taking up the most bandwidth / cpu time ? You mean for virtual-hosts? Not currently. You could write a filter, of course, but I think that would be some useful data we could add. -- Scott That would be a very worthwhile upgrade. ___ 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] Includes and response outputstream/writer
On Nov 15, 2006, at 10:58 AM, Christian Amott wrote: Hi, At least in resin 2.1, it appears that when one does an include using RequestDispatcher.include(), the included data is piped through the responses outputStream and not it's writer - thus the included data is not encoded as per the java spec for response.getOutputStream (). Because of this, all of our text comes out as UTF-8 and non-ascii characters won't show up unless we force charset=UTF-8 in the response header. You can also set the content-type of the included file to iso-8859-1 as a workaround. I was hoping if someone knew if the .include() is suppose to use the responses outputstream and not the writer or is this a bug with resin?? If not, how does one get encoded data out from an include?? i.e. we want ISO-8859-1 encoded data to come out but I can only do that if i write data out via the responses writer (as per spec). It's a bug. Or rather, the 2.1 behavior doesn't follow the spec. That behavior was changed in 3.0. -- Scott Cheers Christian ___ 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 with jdk1.6.0
On Nov 27, 2006, at 4:26 AM, George Moschovitis wrote:
Dear devs,
I am trying to use resin with jdk1.6.0. I have the following code in
my servlet init method:
I've added it as a bug report. It's possible there's some issue with
the Quercus implementation of the javax.script API.
-- Scott
...
import javax.script.*;
...
public void init() throws ServletException {
// create a ScriptEngineManager
ScriptEngineManager m = new ScriptEngineManager();
// get an instance of JavaScript script engine
engine = m.getEngineByName(js);
// expose the current script engine as a global variable
engine.put(engine, engine);
}
...
And I get the following error:
[14:22:03.364] myservlet: init
[14:22:03.373] java.lang.AbstractMethodError
[14:22:03.373] at
javax.script.ScriptEngineManager.getEngineByName
(ScriptEngineManager.java:216)
[14:22:03.373] at myservlet.AdapterServlet.init
(AdapterServlet.java:26)
[14:22:03.373] at javax.servlet.GenericServlet.init
(GenericServlet.java:69)
[14:22:03.373] at
com.caucho.server.dispatch.ServletConfigImpl.createServletImpl
(ServletConfigImpl.java:646)
[14:22:03.373] at
com.caucho.server.dispatch.ServletConfigImpl.createServlet
(ServletConfigImpl.java:587)
[14:22:03.373] at
com.caucho.server.dispatch.ServletFilterChain.doFilter
(ServletFilterChain.java:97)
[14:22:03.373] at
com.caucho.server.webapp.WebAppFilterChain.doFilter
(WebAppFilterChain.java:173)
[14:22:03.373] at
com.caucho.server.dispatch.ServletInvocation.service
(ServletInvocation.java:229)
[14:22:03.373] at
com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:274)
[14:22:03.373] at
com.caucho.server.port.TcpConnection.run(TcpConnection.java:511)
[14:22:03.373] at com.caucho.util.ThreadPool.runTasks
(ThreadPool.java:520)
[14:22:03.373] at com.caucho.util.ThreadPool.run(ThreadPool.java:442)
[14:22:03.373] at java.lang.Thread.run(Thread.java:619)
Some times the error says something about a QuercusScriptingEngine.
Any idea?
thanks in advance for your help,
George.
--
http://blog.gmosx.com
http://nitroproject.org
___
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] Simply.... thanks
On Nov 27, 2006, at 11:59 PM, Daniel López wrote: Hi there, Just following my own advice* :), I would like to simply say thanks to the Caucho guys and all the helpful people on this list. I've been using Resin for many years, first for development, then with an easy license and now with the GPL version. Thanks! -- Scott We use it extensively at the university where I work and I also try to spread the usage wherever I go, simply because I think good products should be rewarded by being used ;). In any case, none of this would have been possible without the generous licensing ad the great work of the Caucho guys, and the helpful tips of the people on this list throughout the years. So, in one word: thanks. Cheers! D. *) http://www.jroller.com/page/greeneyed?entry=paying_the_price_of_open https://javatools.dev.java.net/newsletter/20061122.html#tools_tips ___ 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] OpenSSL 0.9.8d won't work with Resin 3.0.21 Pro?
On Nov 30, 2006, at 2:47 PM, Rob Lockstone wrote: Environment: Windows 2003 Server, Resin Pro 3.0.21, Java 1.4.2 Wow, is Resin so sensitive to versions of OpenSSL that it will ONLY work with the specific letter version, e.g. 'b' but not 'd' of the 0.9.8 code base? Are there any alternatives to OpenSSL? This is kind of pathetic, no? I'm scared to even try 3.0.22. Which letter does it need? 'c'? One issue is that the OpenSSL windows build has changed the *.dll file names that it uses. That happened relatively recently, so that may be what you're running into. I do need to check to make sure there isn't anything odd about how Resin's linking to OpenSSL on windows that might be causing extra problems. As long as they don't change the exported functions, the new OpenSSL *.dll should work. But I think you may have run into a reorg issue on OpenSSL's part. (And, yes, this issue doesn't exist at all on Unix, although there are some other openssl issues.) -- Scott Rob [14:37:42.440] java.lang.UnsatisfiedLinkError: D:\resin\win32 \resinssl.dll: This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem [14:37:42.440]at java.lang.ClassLoader$NativeLibrary.load(Native Method) [14:37:42.440]at java.lang.ClassLoader.loadLibrary0 (ClassLoader.java:1586) [14:37:42.440]at java.lang.ClassLoader.loadLibrary(ClassLoader.java: 1511) [14:37:42.440]at java.lang.Runtime.loadLibrary0(Runtime.java:788) [14:37:42.440]at java.lang.System.loadLibrary(System.java:834) [14:37:42.440]at com.caucho.vfs.OpenSSLFactory.clinit (OpenSSLFactory.java) [14:37:42.440]at java.lang.Class.forName0(Native Method) [14:37:42.440]at java.lang.Class.forName(Class.java:141) [14:37:42.440]at com.caucho.server.port.Port.createOpenssl (Port.java:321) [14:37:42.440]at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) [14:37:42.440]at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) [14:37:42.440]at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) [14:37:42.440]at java.lang.reflect.Method.invoke(Method.java:324) [14:37:42.440]at com.caucho.config.CreateAttributeStrategy.configure (CreateAttributeStrategy.java:81) [14:37:42.440]at com.caucho.config.NodeBuilder.configureAttributeImpl(NodeBuilder.java: 381) [14:37:42.440]at com.caucho.config.NodeBuilder.configureBeanImpl (NodeBuilder.java:341) [14:37:42.440]at com.caucho.config.TypeStrategy.configureBean (TypeStrategy.java:103) [14:37:42.440]at com.caucho.config.BeanTypeStrategy.configureBean (BeanTypeStrategy.java:228) [14:37:42.440]at com.caucho.config.NodeBuilder.configureImpl (NodeBuilder.java:257) [14:37:42.440]at com.caucho.config.NodeBuilder.configureChildImpl (NodeBuilder.java:303) [14:37:42.440]at com.caucho.config.BeanTypeStrategy.configure (BeanTypeStrategy.java:197) [14:37:42.440]at com.caucho.config.SetterAttributeStrategy.configure (SetterAttributeStrategy.java:91) [14:37:42.440]at com.caucho.config.NodeBuilder.configureAttributeImpl(NodeBuilder.java: 381) [14:37:42.440]at com.caucho.config.TypeStrategy.configureAttribute (TypeStrategy.java:112) [14:37:42.440]at com.caucho.config.EnvironmentTypeStrategy.configureAttribute (EnvironmentTypeStrategy.java:89) [14:37:42.440]at com.caucho.config.NodeBuilder.configureAttribute (NodeBuilder.java:230) [14:37:42.440]at com.caucho.config.NodeBuilderChildProgram.configureImpl (NodeBuilderChildProgram.java:54) [14:37:42.440]at com.caucho.config.BuilderProgramContainer.configureImpl (BuilderProgramContainer.java:62) [14:37:42.440]at com.caucho.config.BuilderProgram.configure (BuilderProgram.java:60) [14:37:42.440]at com.caucho.server.deploy.EnvironmentDeployController.configureInstance (EnvironmentDeployController.java:377) [14:37:42.440]at com.caucho.server.resin.ServerController.configureInstance (ServerController.java:198) [14:37:42.440]at com.caucho.server.resin.ServerController.configureInstance (ServerController.java:52) [14:37:42.440]at com.caucho.server.deploy.DeployController.startImpl (DeployController.java:619) [14:37:42.440]at com.caucho.server.deploy.AbstractDeployControllerStrategy.start (AbstractDeployControllerStrategy.java:56) [14:37:42.440]at com.caucho.server.deploy.DeployController.start (DeployController.java:517) [14:37:42.440]at com.caucho.server.resin.ResinServer.start (ResinServer.java:546) [14:37:42.440]at com.caucho.server.resin.Resin.init(Resin.java) [14:37:42.440]at com.caucho.server.resin.Resin.main(Resin.java:625)
Re: [Resin-interest] JSTL issue with Resin 3.0.22
On Dec 3, 2006, at 5:41 PM, Josh Rehman wrote: 2) Adding this configuration doesn't fix the problem. The doc attribute of x:parse is most certainly supported by JSTL 1.1: http://java.sun.com/products/jsp/jstl/1.1/docs/tlddocs/index.html Which tag declaration are you using for the x:* tags? It looks like the @doc attribute is declared in Resin's 1.1 tld, but not the 1.0 tld. Also, Resin will use the jstl.jar if it's available (and fast-jstl is turned off) in preference to its own tag libraries. -- Scott - Interestingly, I just checked and realized that I had configured Tomcat with JSTL at the container level, and so this project does not contain the jstl.jar and standard.jar. I'm going to try adding these next (and adding the taglib declaration to web.xml). But I see this as a seperate bug in Resin: if I disable fast jstl, I would expect the application to fail faster with a taglib not found type of error. I am very much hoping that there is some oversight on my part. I do not like JBoss's baroque configuration at all and would very much like to convince my peers that Resin is the way to go. Kind regards, Josh Rehman ___ 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] An interesting memory leak
On Dec 8, 2006, at 8:37 AM, Rob Lockstone wrote: On Dec 8, 2006, at 00:10 , sksamuel wrote: Here is an interesting one, If I package my application up as a JAR and put it in WEB-INF/lib then I get memory leaks in the perm gen space as none of the Class objects are garbage collected. This is easily re-producable every time. If however I put the application's .class files inside WEB-INF/class and don't bother with the JAR then it will work fine, no memory leaks, runs forever. Any ideas on what I'm doing wrong or if there is some subtle issue with classloaders here that I don't understand ? If what you describe is really happening, it's gotta be nominated for the Bizzaro Bug of the Month or something. :-) You're sure the perm space is being exhausted? Are you using -XX: +PrintGCDetails or something similar to see the results of gc's on the perm space? Also, very important, what environment are you running? Versions of OS, Resin, Java? This sounds like the JDK/introspection/debug perm-gen GC issue (which is really weird). It's a JDK bug, which appears to be fixed in the most recent JDKs. -- Scott 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] com.caucho.vfs.JniStream.readNative flakiness? [Was: Another weird OpenSSL/Resin Error.]
On Dec 8, 2006, at 8:56 AM, Rob Lockstone wrote: Environment: Windows 2003 Server, Resin Pro 3.0.21, OpenSSL 0.9.8b, Java 1.4.2_12 More information on what caused the JVM/Resin to spontaneously reboot. I get these fairly often (multiple times per month). They're not always the same exact thing. Often the stack trace references one of the SSL DLL's, but other times, like this one, it references the JVM DLL. In any event, since the Java frames section references some Caucho JNI calls, I'm sending this in. Scott, let me know if you want an official bug filed. That would be great. I'm attaching two files to this email since the emailer likes to reformat stuff into unreadable chunks. One is the weird SSL_UNDEFINED_FUNCTION error I have never seen before and reported a few minutes. The other is the top portion of the JVM crash log where the jvm.dll was the source of the crash and Caucho JNI routines are being called. Btw, whenever the crash log mentions an SLL DLL as the source of the crash, the Java frames section is always something along these lines: Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j com.caucho.vfs.JniStream.readNative(J[BII)I+0 j com.caucho.vfs.JniStream.read([BII)I+43 j com.caucho.vfs.ReadStream.readBuffer()Z+53 j com.caucho.vfs.ReadStream.waitForRead()Z+12 j com.caucho.server.port.TcpConnection.run()V+181 j com.caucho.util.ThreadPool.runTasks()V+187 j com.caucho.util.ThreadPool.run()V+85 j java.lang.Thread.run()V+11 v ~StubRoutines::call_stub Which is similar to the attached JVM DLL crash. What's up with com.caucho.vfs.JniStream.readNative ? readNative itself should be solid. We've run it for days under very heavy load (CPU load around 40 on multi-cpu systems) with no issues. But there has been less time stressing openssl, so there might be something odd there. -- Scott Rob SSL_UNDEFINED_FUNCTION.log jvmDLLCrash.log ___ 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] Error using custom log formatter
On Dec 7, 2006, at 6:05 PM, jason rutherglen wrote:
Where org.apache.solr.cluster.ClusterLogFormatter extends
java.util.logging.Formatter. Get this error:
[17:49:24.453] com.caucho.config.LineConfigException: WEB-INF/
web.xml:16: java.l
ang.IllegalAccessException: Class
com.caucho.config.BeanTypeStrategy can not acc
ess a member of class java.util.logging.Formatter with modifiers
protected
I've added this as a bug report. It definitely looks like an
introspection issue, but I'm not sure why the introspection would not
be allowed.
-- Scott
--
package org.apache.solr.cluster;
import java.util.logging.*;
import java.io.*;
import java.text.*;
import java.util.Date;
import java.sql.SQLException;
import java.util.concurrent.locks.*;
import org.apache.commons.lang.exception.*;
import org.apache.commons.dbutils.DbUtils;
/**
* Prints out full stack traces of all nested exceptions
*
* @author jasonr
*/
public class ClusterLogFormatter extends java.util.logging.Formatter {
Date dat = new Date();
private final static String format = {0,date} {0,time};
private MessageFormat formatter;
private ReentrantLock lock = new ReentrantLock();
private Object args[] = new Object[1];
public static void main(String[] args) {
LogManager logManager = LogManager.getLogManager();
//logManager.
}
// Line separator string. This is the value of the line.separator
// property at the moment that the SimpleFormatter was created.
private String lineSeparator = (String)
java.security.AccessController.doPrivileged(
new sun.security.action.GetPropertyAction
(line.separator));
public ClusterLogFormatter() {
super();
}
public String format(LogRecord record) {
lock.lock();
try {
StringBuffer sb = new StringBuffer();
// Minimize memory allocations here.
dat.setTime(record.getMillis());
args[0] = dat;
StringBuffer text = new StringBuffer();
if (formatter == null) {
formatter = new MessageFormat(format);
}
formatter.format(args, text, null);
sb.append(text);
sb.append( );
if (record.getSourceClassName() != null) {
sb.append(record.getSourceClassName());
} else {
sb.append(record.getLoggerName());
}
if (record.getSourceMethodName() != null) {
sb.append( );
sb.append(record.getSourceMethodName());
}
sb.append(lineSeparator);
String message = formatMessage(record);
sb.append(record.getLevel().getLocalizedName());
sb.append(: );
sb.append(message);
sb.append(lineSeparator);
if (record.getThrown() != null) {
Throwable throwable = record.getThrown();
if (throwable instanceof SQLException) {
SQLException sqlException = (SQLException)throwable;
StringWriter stringWriter = new StringWriter();
DbUtils.printStackTrace(sqlException, new PrintWriter
(stringWriter));
sb.append(stringWriter.toString());
} else {
String string = ExceptionUtils.getFullStackTrace(throwable);
sb.append(string);
}
/**
* try {
* StringWriter sw = new StringWriter();
* PrintWriter pw = new PrintWriter(sw);
* record.getThrown().printStackTrace(pw);
* pw.close();
* sb.append(sw.toString());
* } catch (Exception ex) {
* }
**/
}
return sb.toString();
} finally {
lock.unlock();
}
}
}
___
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] com.caucho.vfs.JniStream.readNative flakiness? [Was: Another weird OpenSSL/Resin Error.]
On Dec 8, 2006, at 10:34 AM, Rob Lockstone wrote: Fwiw, I just restarted a server and got three of these SSL-related crashes in a row. It's just really, really bad when you try to restart a server and add it to a pool of active servers and it starts taking requests. Just awful. So it sounds like there might be a startup synchronization issue. Your previous case shows something similar. Again, I'd like to request that, at least for Windows, Caucho includes its own we trust this build of OpenSSL DLL's for use with Resin. The constant crashing is painful to watch. And since I'm the resin guy, even though I'm not a sysadmin, I get blamed when everything goes to pot. It's not fun. :-( We can add the OpenSSL version we tested with. That's a good idea. We can't distribute the dll itself. I'll see if I can figure out how to reproduce it. It may be a bit tricky to track down, though. Java's thread dumps are so much nicer. -- Scott Rob SSLdllCrash.log On Dec 8, 2006, at 09:10 , Scott Ferguson wrote: On Dec 8, 2006, at 8:56 AM, Rob Lockstone wrote: Environment: Windows 2003 Server, Resin Pro 3.0.21, OpenSSL 0.9.8b, Java 1.4.2_12 More information on what caused the JVM/Resin to spontaneously reboot. I get these fairly often (multiple times per month). They're not always the same exact thing. Often the stack trace references one of the SSL DLL's, but other times, like this one, it references the JVM DLL. In any event, since the Java frames section references some Caucho JNI calls, I'm sending this in. Scott, let me know if you want an official bug filed. That would be great. I'm attaching two files to this email since the emailer likes to reformat stuff into unreadable chunks. One is the weird SSL_UNDEFINED_FUNCTION error I have never seen before and reported a few minutes. The other is the top portion of the JVM crash log where the jvm.dll was the source of the crash and Caucho JNI routines are being called. Btw, whenever the crash log mentions an SLL DLL as the source of the crash, the Java frames section is always something along these lines: Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j com.caucho.vfs.JniStream.readNative(J[BII)I+0 j com.caucho.vfs.JniStream.read([BII)I+43 j com.caucho.vfs.ReadStream.readBuffer()Z+53 j com.caucho.vfs.ReadStream.waitForRead()Z+12 j com.caucho.server.port.TcpConnection.run()V+181 j com.caucho.util.ThreadPool.runTasks()V+187 j com.caucho.util.ThreadPool.run()V+85 j java.lang.Thread.run()V+11 v ~StubRoutines::call_stub Which is similar to the attached JVM DLL crash. What's up with com.caucho.vfs.JniStream.readNative ? readNative itself should be solid. We've run it for days under very heavy load (CPU load around 40 on multi-cpu systems) with no issues. But there has been less time stressing openssl, so there might be something odd there. -- Scott Rob SSL_UNDEFINED_FUNCTION.log jvmDLLCrash.log ___ 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] com.caucho.vfs.JniStream.readNative flakiness? [Was: Another weird OpenSSL/Resin Error.]
On Dec 8, 2006, at 6:00 PM, Rob Lockstone wrote: We can add the OpenSSL version we tested with. That's a good idea. We can't distribute the dll itself. Damn. :-( Well, can you distribute the source AND your particular build flags, etc? That should allow us to build the dll with the same source/process and hopefully obtain the exact same dll's. I've been using the shining light build: http://www.slproweb.com/ products/Win32OpenSSL.html. If you're rebuilding openssl, you need to make sure you've set the threaded flag (although looking at their docs, it looks like it's set automatically in windows.) It used to be that openssl's default build would compile in non-multithreaded on unix. The build info for resinssl should be part of the pro distribution in modules/c/resinssl if that's helpful tracking this down. -- Scott Rob I'll see if I can figure out how to reproduce it. It may be a bit tricky to track down, though. Java's thread dumps are so much nicer. -- Scott Rob SSLdllCrash.log On Dec 8, 2006, at 09:10 , Scott Ferguson wrote: On Dec 8, 2006, at 8:56 AM, Rob Lockstone wrote: Environment: Windows 2003 Server, Resin Pro 3.0.21, OpenSSL 0.9.8b, Java 1.4.2_12 More information on what caused the JVM/Resin to spontaneously reboot. I get these fairly often (multiple times per month). They're not always the same exact thing. Often the stack trace references one of the SSL DLL's, but other times, like this one, it references the JVM DLL. In any event, since the Java frames section references some Caucho JNI calls, I'm sending this in. Scott, let me know if you want an official bug filed. That would be great. I'm attaching two files to this email since the emailer likes to reformat stuff into unreadable chunks. One is the weird SSL_UNDEFINED_FUNCTION error I have never seen before and reported a few minutes. The other is the top portion of the JVM crash log where the jvm.dll was the source of the crash and Caucho JNI routines are being called. Btw, whenever the crash log mentions an SLL DLL as the source of the crash, the Java frames section is always something along these lines: Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j com.caucho.vfs.JniStream.readNative(J[BII)I+0 j com.caucho.vfs.JniStream.read([BII)I+43 j com.caucho.vfs.ReadStream.readBuffer()Z+53 j com.caucho.vfs.ReadStream.waitForRead()Z+12 j com.caucho.server.port.TcpConnection.run()V+181 j com.caucho.util.ThreadPool.runTasks()V+187 j com.caucho.util.ThreadPool.run()V+85 j java.lang.Thread.run()V+11 v ~StubRoutines::call_stub Which is similar to the attached JVM DLL crash. What's up with com.caucho.vfs.JniStream.readNative ? readNative itself should be solid. We've run it for days under very heavy load (CPU load around 40 on multi-cpu systems) with no issues. But there has been less time stressing openssl, so there might be something odd there. -- Scott Rob SSL_UNDEFINED_FUNCTION.log jvmDLLCrash.log ___ 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 ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Did resin support epoll?
On Dec 26, 2006, at 9:59 AM, Serge Knystautas wrote: Steve Z wrote: Hi Sun JRE nio has supported epoll from JDK5.0_up9,JDK6.0 at bottom, I wanna know whether it meaned resin support epoll now? thanks. Resin does not use nio, so how the Sun JVM implements NIO is not significant. This is an interesting read on the matter from when epoll was a new feature: http://www.theserverside.com/discussions/thread.tss? thread_id=26700 Yep. Threads aren't all that bad, especially on recent operating systems. Remember, that any epoll/nio solution has extra overhead associated with detaching/attaching the thread. A poll/epoll is essentially the same as an operating system block, but handled at the user level (and so requires several extra system calls). OS blocks essentially do the exact same thing, but are handled by the kernel, which is far more efficient. The problem at the moment is really 32-bit memory limitations. Since threads take up virtual memory, lots of threads take up lots of memory. In a 64-bit system, that's not an issue. But we're running up to the limits of 32-bit virtual memory with lots of threads. That issue will go away in the next 3-5 years as we transition to 64- bits. At that point, it would make sense to just stick with lots of threads and avoid the epoll issue entirely. -- Scott -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 3.1.0 release
On Dec 26, 2006, at 1:22 PM, Alex Sharaz wrote:
Scott, many thanks for the official release of 3.1
I've installed it on a RHEL4 system with the BEA Jrockit JVM.
Got all my ususal stuff working but sadly not Gallery2 or media wiki.
I've switched debug logging on and have what might be some useful
logging. Should I send it to the list or [EMAIL PROTECTED]
bugs.caucho.com would be best (if the logs are small).
We also refactored Quercus in a major way for 3.1.0, so that's almost
certainly what you're running into. We should be able to split out
the interpreted half of Quercus as a standalone web-app (i.e. non-
Resin), so we can have non-Resin users working on Quercus too.
-- Scott
All the best for the new year
Alex
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Scott Ferguson
Sent: 26 December 2006 17:56
To: General Discussion for the Resin application server;
[EMAIL PROTECTED]
Subject: [Resin-interest] Resin 3.1.0 release
Resin 3.1.0 is now available. Keep in mind that 3.1.x is a
development branch. 3.1.1 will have new features as well as bug
fixes, so it is possible that 3.1.1 may introduce new bugs.
Main changes in 3.1.0:
Requires JDK 1.5
Servlet for JavaEE 1.5
JSP for JavaEE 1.5
Amber progress (almost, but not quite passing JPA)
resin.conf refactoring for improved cluster configuration
watchdog/startup changes
web services configuration (as servlet)
Quercus updates for PHP 6 (i18n), Java reflection
I) Watchdog/startup changes:
The most visible change is the Resin startup, particularly on Unix.
The wrapper.pl is now gone, replaced by a Java watchdog process. The
unix command-line startup is:
unix java -jar resin-3.1.0/lib/resin.jar start
Or, for foreground, development work, just
unix java -jar resin-3.1.0/lib/resin.jar
For different configuration files and servers, use
unix java -jar lib/resin.jar -conf conf/myconfig.conf -server app-
a start
Windows users can also use the new startup, but can still use the old
httpd.exe.
Because the watchdog process is in Java, JDK command-line arguments
now belong in the resin.conf. This will be nice, since all the
relevant configuration will now be in resin.conf.
II) resin.conf clustering changes.
We've reorganized the resin.conf to better handle multiple clusters.
The most important use is for web-tier and app-tier load-balancing.
Now, both the web-tier and the app-tier fit into the same resin.conf.
The old 3.1.0 syntax is still available as backward compatibility,
but we encourage people to upgrade.
The basic structure is:
resin xmlns=http://caucho.com/ns/resin;
cluster id=app-tier
server-default
!-- common configuration for all servers in a cluster,
like thread-max --
http address=* port=8080/
/server-default
!-- server replaces srun --
server id=app-a address=192.168.2.10 port=6800/
host id=www.caucho.com
!-- usual virtual host configuration --
/host
/cluster
/resin
III) web services
Web services can now be configured as servlets (this is part of the
Servlet 2.5 spec). If the servlet-class implements @WebService, it
will be treated as a web-service. The class does not need to
implement Servlet. The lifecycle is the same as for a servlet, i.e.
only a single, multithreaded instance (no pooling).
Resin allows a choice of protocols, including Hessian, Burlap, and
REST. So the configuration might look like:
servlet-mapping url-pattern=/hello/*
servlet-class=example.HelloServiceImpl
protocol type=hessian
api-classexample.Hello/api-class
/protocol
/servlet-mapping
IV) JSP and Servlet for JavaEE 5
See the specs. :)
The main new capabilities are @Resource injection and capabilities
for the new JSF (i.e. %{foo}).
The @Resource injection is very nice. It removes the requirement for
most JNDI lookup, e.g.
public class MyServlet ... {
@Resource(name=jdbc/db)
private DataSource _dataSource;
...
}
Resin will inject the DataSource into the servlet before it calls the
init() method.
V) @Resource for java.util.concurrent.Executor
In Resin you can use the @Resource to get access to Resin's thread
pool for Executor-launched threads. This means you can launch short-
lived threads using Resin's thread pool.
However, you still need to be careful about lifecycle issues. We
haven't yet implemented an ExecutorService which would let Resin stop
the thread on web-app restart automatically. So you still need to
have the destroy() method stop the thread.
class MyServlet {
@Resource
private Executor _executor;
private void foo()
{
_executor.execute(new MyRunnableTask());
}
}
VI) Resin 3.1.1 roadmap
The roadmap always changes, so take this as a rough guideline of
intent. We think the following will be ready for 3.1.1
Re: [Resin-interest] Multiple SSL Certificates with Resin Pro 3.0.21
On Dec 28, 2006, at 1:16 PM, Rob Lockstone wrote: Environment: Windows Server 2003, Resin Pro 3.0.21, JDK 1.4.2, OpenSSL 0.9.8b Can Resin be configured to support multiple SSL certificates? If so, how? You'd need to have separate http blocks for each certificate: http address=10.1.1.1 port=443 openssl /http http address=10.1.1.2 port=443 openssl /http -- Scott For example, this works: http port=443 openssl ca-certificate-filekeys/verisign.premium.intermediate.crt/ca- certificate-file certificate-filekeys/mySiteOne.mydomain.com.crt/certificate-file certificate-key-filekeys/mySiteOne.mydomain.com.key/certificate- key-file passwordmyPassword/password /openssl /http How would Resin support multiple certificates for different sites? Will this work? (This is difficult for us to test without affecting real users, so I was just hoping to see if someone knew before we try it live.) http port=443 openssl ca-certificate-filekeys/verisign.premium.intermediate.crt/ca- certificate-file certificate-filekeys/mySiteOne.mydomain.com.crt/certificate-file certificate-key-filekeys/mySiteOne.mydomain.com.key/certificate- key-file passwordmyPassword/password /openssl openssl ca-certificate-filekeys/verisign.premium.intermediate.crt/ca- certificate-file certificate-filekeys/mySiteTwo.mydomain.com.crt/certificate-file certificate-key-filekeys/mySiteTwo.mydomain.com.key/certificate- key-file passwordmyPassword/password /openssl /http 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] 3.0.22: session.maxInactiveInterval in milliseconds
On Jan 3, 2007, at 10:18 AM, L Logue wrote: Date: Wed, 3 Jan 2007 09:06:49 -0800 From: Scott Ferguson [EMAIL PROTECTED] On Jan 3, 2007, at 7:23 AM, L Logue wrote: The 1.4 EE API specified that maxInactiveInterval is an integer specifying the number of seconds this session remains open between client requests. In my development resin conf , when I set the session-timeout configuration to 1 minute, session.maxInactiveInterval came out as 6, but it should be 60 instead. In what context are you seeing the 6? JMX? The JMX value is in milliseconds like the other JMX time values. In the web-app context. I registered an HttpSessionListener, and in sessionCreated(): httpSessionEvent.getSession ().getMaxInactiveInterval() was 6. I just checked and getMaxInactiveInterval() is returning the correct value (60, for a session-timeout1/session-timeout) for both 3.1 and 3.0. -- Scott Thanks. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Quercus and Java Exceptions
On Jan 5, 2007, at 8:00 AM, Markus Wolf wrote: Hi, is there a way to catch a JavaException (e.g. QuercusException) in PHP? I have webservice throwing an exception which is wrapped in an QuercusException, but I cannot handle it in the PHP script. It's an open bug currently: http://bugs.caucho.com/view.php?id=1455 I haven't yet decided how that should be handled. -- Scott Markus Wolf -- NMMN - New Media Markets Networks http://www.nmmn.com/ Langbehnstrasse 6 22761 Hamburg Tel. 040 284 118 - 720 Fax 040 284 118 - 999 ___ 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 OpenSSO
On Jan 12, 2007, at 12:15 AM, Simona borrello wrote: Hi all, i'm trying to install OpenSSO under Resin. When i start the web application, typically: I've filed it as a bug at http://bugs.caucho.com/view.php?id=1557. I'm not familiar with openssl, so I'm not sure what the issue is. -- Scott http://localhost:8080/opensso i receive this error: java.lang.NullPointerException at com.sun.identity.authentication.service.AuthD.(AuthD.java:224) at com.sun.identity.authentication.UI.LoginLogoutMapping.initializeAuth (LoginLogoutMapping.java:75) at com.sun.identity.authentication.UI.LoginLogoutMapping.init (LoginLogoutMapping.java:56) at com.caucho.server.dispatch.ServletConfigImpl.createServletImpl (ServletConfigImpl.java:766) at com.caucho.server.dispatch.ServletConfigImpl.createServlet (ServletConfigImpl.java:697) at com.caucho.server.dispatch.ServletManager.init (ServletManager.java:150) at com.caucho.server.webapp.WebApp.start(WebApp.java :1699) at com.caucho.server.deploy.DeployController.startImpl (DeployController.java:623) at com.caucho.server.deploy.DeployController.restartImpl (DeployController.java:586) at com.caucho.server.deploy.StartAutoRedeployAutoStrategy.request (StartAutoRedeployAutoStrategy.java:125) at com.caucho.server.deploy.DeployController.request (DeployController.java:556) at com.caucho.server.webapp.WebAppContainer.getWebApp (WebAppContainer.java:884) at com.caucho.server.webapp.WebAppContainer.buildInvocation (WebAppContainer.java:724) at com.caucho.server.host.Host.buildInvocation(Host.java:476) at com.caucho.server.host.HostContainer.buildInvocation (HostContainer.java:331) at com.caucho.server.cluster.Server.buildInvocation (Server.java:795) at com.caucho.server.dispatch.DispatchServer.buildInvocation (DispatchServer.java:200) at com.caucho.server.http.HttpRequest.handleRequest (HttpRequest.java:258) at com.caucho.server.port.TcpConnection.run (TcpConnection.java:477) at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:591) at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:513) at java.lang.Thread.run(Thread.java:595) I also try to put the libraries used by opensso under the Resin lib dir, but i receive another error. Do you know how to resolve this problem? I've also installed OpenSSO under Apache Tomcat and goes well. Anyway i'd like to install under Resin. Thanks in advance for the responses :) Simona ___ 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] Using resin for selected PHP apps
On Jan 11, 2007, at 3:36 PM, Stargazer wrote: I'm on a dedicated RH Linux server which has been preconfigured with Plesk and a few PHP apps. I installed resin and changed Apache to use mod_caucho. All was fine until I upgraded to resin 3.1, using the default config resin and my webapps were fine, but all the existing PHP stuff broke - all *.php files were directed to resin. So, I changed resins config to basically tell it not to serve PHP, I think I just needed to comment 2 lines in the end. But resin serving PHP is too useful to ignore, so I'd like to keep this setup but reactivate resins PHP for some specific web apps. For instance, how would I add a new web app, install Drupal into it and with my setup activate resins PHP handler please? You can create a web-app for Drupal in webapps/drupal, and then add a resin-web.xml with the QuercusServlet configuration: servlet-mapping url-pattern=*.php servlet- class=com.caucho.quercus.servlet.QuercusServlet/ The sample resin.conf with Resin 3.1 includes that servlet-mapping in a web-app-default, which enables PHP for everything, but you can enable it for selected web-apps if that's what you need. -- Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin... ?????
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/app-dir/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
Re: [Resin-interest] Disable automatic restart on config changes
On Jan 17, 2007, at 6:10 AM, Kenneth Svee wrote: Hi. Is there any way, in Resin 3.x, to disable the automatic restarts of the server when it detects changes in resin.conf, or disable/delay the detection process? This does not seem to be related to Resin catching modfications in the code (e.g. updated WAR-files) that we can configure via the 'redeploy-mode' and 'dependency-check-interval' directives. The resin.conf checking does depend on the dependency-check- interval. You would need to put the directive at the resin level, and you can set it to -1 to avoid any checking. But there isn't an equivalent to redeploy-mode at the top-level. -- Scott Rgds, Kenneth Svee ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Cluster and java.lang.IllegalArgumentException:block 30720 must match store Table[srun_b:1] error
On Jan 22, 2007, at 12:47 PM, Yogesh Gowdra wrote: Deleting srun_*.db files and restarting server solved the problem. More than licensing issue, it was the size (close to a gig) of these files which created problem. That makes sense. That was one of the fixes we needed to make for 3.1. -- Scott From: [EMAIL PROTECTED] [mailto:resin-interest- [EMAIL PROTECTED] On Behalf Of Yogesh Gowdra Sent: Thursday, January 11, 2007 1:55 PM To: resin-interest@caucho.com Subject: [Resin-interest] Cluster and java.lang.IllegalArgumentException:block 30720 must match store Table[srun_b:1] error Hi, We use resin 3.0.14 professional in clustered environment on Linux OS. We have 2 nodes in cluster behind hardware loadbalancer. Everything used to work fine until recently when our production licence expired. Scenario: When user navigates to certain point in application, session invalidates and will be thrown to application login page and we see following error in stdout.log (and it happens consistenly at that point, it used work fine before licence expiry). Now we replaced expired licence with new valid licence file that we received from caucho, inspite of it we see following error happening. Do you see any need for me to cleanup cluster store (srun_*.db) (which was created when server was running with old licence) or is there any thing I am missing out? Any quick response would be greatly appreciated. Thanks [2007-01-11 19:05:57.117]java.lang.IllegalArgumentException: block 30720 must match store Table[srun_b:1]. [2007-01-11 19:06:00.752]com.caucho.vfs.IOExceptionWrapper: java.lang.IllegalArgumentException: block 30720 must match store Table[srun_b:1]. [2007-01-11 19:06:00.752] at com.caucho.vfs.IOExceptionWrapper.create(IOExceptionWrapper.java:65) [2007-01-11 19:06:00.752] at com.caucho.server.session.SessionImpl.load(SessionImpl.java:836) [2007-01-11 19:06:00.752] at com.caucho.server.session.SessionManager.load(SessionManager.java: 1235) [2007-01-11 19:06:00.752] at com.caucho.server.cluster.ClusterObject.load(ClusterObject.java:274) [2007-01-11 19:06:00.752] at com.caucho.server.cluster.FileBacking.loadSelf(FileBacking.java:318) [2007-01-11 19:06:00.752] at com.caucho.server.cluster.ClusterStore.load(ClusterStore.java:404) [2007-01-11 19:06:00.752] at com.caucho.server.cluster.ClusterObject.load(ClusterObject.java:245) [2007-01-11 19:06:00.752] at com.caucho.server.session.SessionImpl.load(SessionImpl.java:677) [2007-01-11 19:06:00.752] at com.caucho.server.session.SessionManager.getSession (SessionManager.java:1035) [2007-01-11 19:06:00.752] at com.caucho.server.connection.AbstractHttpRequest.createSession (AbstractHttpRequest.java:1364) [2007-01-11 19:06:00.752] at com.caucho.server.connection.AbstractHttpRequest.getSession (AbstractHttpRequest.java:1174) [2007-01-11 19:06:00.752] at com.caucho.server.connection.AbstractHttpRequest.getSession (AbstractHttpRequest.java:1152) [2007-01-11 19:06:00.752] at org.apache.struts.action.RequestProcessor.processLocale (RequestProcessor.java:631) [2007-01-11 19:06:00.752] at org.apache.struts.action.RequestProcessor.process (RequestProcessor.java:230) [2007-01-11 19:06:00.752] at org.apache.struts.action.ActionServlet.process(ActionServlet.java: 1482) [2007-01-11 19:06:00.752] at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525) [2007-01-11 19:06:00.752] at javax.servlet.http.HttpServlet.service (HttpServlet.java:154) [2007-01-11 19:06:00.752] at javax.servlet.http.HttpServlet.service (HttpServlet.java:92) [2007-01-11 19:06:00.752] at com.caucho.server.dispatch.ServletFilterChain.doFilter (ServletFilterChain.java:99) [2007-01-11 19:06:00.752] at com.caucho.server.cache.CacheFilterChain.doFilter (CacheFilterChain.java:188) [2007-01-11 19:06:00.752] at com.caucho.server.webapp.WebAppFilterChain.doFilter (WebAppFilterChain.java:163) [2007-01-11 19:06:00.752] at com.caucho.server.dispatch.ServletInvocation.service (ServletInvocation.java:208) [2007-01-11 19:06:00.752] at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:259) [2007-01-11 19:06:00.752] at com.caucho.server.port.TcpConnection.run(TcpConnection.java:363) [2007-01-11 19:06:00.752] at com.caucho.util.ThreadPool.runTasks (ThreadPool.java:490) [2007-01-11 19:06:00.752] at com.caucho.util.ThreadPool.run (ThreadPool.java:423) [2007-01-11 19:06:00.752] at java.lang.Thread.run(Thread.java:534) ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Issue with Content-Type Header Being Overwritten
On Jan 22, 2007, at 8:12 PM, Michael Varshavsky wrote: Scott, Thank you so much for trying to help me. I did some thinking and now I'm starting to blame the RequestDispatcher. Could it be that some special HttpServletResponse wrapper prevents servlet resources that are called through the RequestDispatcher from setting content type on the parent? This would fit with the rest of the facts: - Works on Tomcat because it has a different RequestDispatcher implementation - Works when requesting a .jsp directly, since there is no forwarding involved Is there any way to tell the RequestDispatcher to leave the contentType alone? BTW, we're using Resin 2.1.10 but have an option of upgrading to 3.0.19 if the issue has been resolved in between those versions. Can you check with 3.0 or 3.1? That code has changed significantly. The RequestDispatcher is part of the servlet spec that's really a mess, especially its interactions with filters. So some parts of Resin's implementation needs to jump through hoops to make all the weird spec interactions work. -- Scott Regards, Misha On 1/22/07, Scott Ferguson [EMAIL PROTECTED] wrote: On Jan 21, 2007, at 9:07 PM, Michael Varshavsky wrote: Hi, I've received a request to convert a currently existing mobile Struts/Tiles-based web application to serve content as MimeMultipart instead of XHTML. I wrote a ServletFilter that captures all markup in the response, then parses it to find all the necessary (css and img) files and downloads them. After that I create a MimeMultipart object, add markup as a parent part and styles and images as regular MimeBodyPart(s). Then I set contentType of the response object to be that of the MimeMultipart (ends up being multipart/related; boundary xxx), write MimeMultipart to it and close. I developed and tested on my local Tocat installation and everything worked as expected. When we attempted to deploy the code onto our QA server that is running Resin, we ran into a problem. The filter executes fine, body parts are added as expected and the contentType is set correctly to multipart/related (prints fine in the Logs). However, when it gets to the client, the contentType is overwritten to be text/ html; charset=UTF-8. As a result, browser tries to interpret the Mutlipart as regular markup writing out binary data for images, etc. - which is obviously not the desired result. At first I thought this could be due to the fact that our jsps/ tiles explicitly and through directives set the contentType to be text/html. So I captured the markup from a regular page in the app, added %@ page language='java' session='true' contentType='text/ html; charset=UTF-8'% % response.setContentType(text/html; charset=UTF-8); % to it and saved it as jsp page outside of WEB-INF so that I can hit it directly. This worked fine on Resin!!! I then created a fake Struts action mapping (ForwardAction) which forwarded to a fake Tiles definition - which pointed to the same exact test jsp page (that worked). In this scenario the problem resurfaced and contentType got overwritten to text/html. I started blaming Struts. Struts has a way to set contentType on a per-module basis, through controller's contentType attribute. I decided to check if that was the root of my problem, so I've added controller contentType=text/plain/ to my struts configuration hoping to see my contentType being overwritten to be text/plain instead of text/html. However, the contentType header still got overwritten to be text/html. Trying to think what can possibly be downstream from my filter I became suspicious of Apache. However, even after disabling mod_mime, the problem persisted! To debug, you can open a Resin http port to 8080 to eliminate Apache as a consideration (I doubt it's the cause.) I'm not sure what's calling the extra setContentType, since it looks like some kind of struts interaction. Is it possible to reproduce this with just forwards/includes and filters? -- Scott At this point I don't know what to think and any help would be greatly appreciated! Thanks in advance!!! Misha. ___ 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] JSTL issue with Resin 3.0.22
On Jan 25, 2007, at 11:12 PM, Josh Rehman wrote: It would be nice if the JSTL tags made some assertion about their environment, but that's hardly a Resin bug, except insofar as it's internal fast implementation should probably do the same. If the tags had failed fast I would have been saved a lot of frustration! I've added a bug report. We try to detect and report errors as quickly as possible, so these are useful bug reports. -- Scott Peace, Josh ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Is there an easy way to do this? port
On Feb 1, 2007, at 9:35 AM, Vinny wrote: Hi, I am trying figure out a way to do a kind of virtual hosting based on port number. I want my production apps running under port 443 docroot : (/web/production/webapps) and my dev apps running under 8080. docroot : (/web/dev/webapps) both production and dev apps will have the same context names (like ROOT.war for example) I just need resin to differentiate on port number basically. You can just add the port to the virtual host: host id=foo.com:8080 root-directorydev/root-directory ... /host host id=foo.com root-directoryproduction/root-directory ... /host -- Scott I was thinking perhaps I could nest host/ under http/ but it seems like I will have to make a completely seperate server/ block? Is that really the case? Thanks in advance -- Ghetto Java: http://www.ghettojava.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] Is there an easy way to do this? port
On Feb 2, 2007, at 12:39 AM, Daniel López wrote: Jose Quinteiro escribió: Hi, As Jose, I would recommend having different instances for development and deployment. Even though Resin does a good job on separating contexts and detecting changes and restarting just the appropriate web app. You will still affect your deployment applications with the common frequent restarts during development. True. And as Jose said, you don't need two copies of the whole Resin software, just two config files so you don't have to worry about maintaing/upgrading two full instances. FYI, in Resin 3.1 you could just use one config file and have two separate cluster blocks. The -server foo will select which cluster will be active for that JVM. -- Scott In fact, we use more than one instance even in deployment, as that allows us to handle upgrades/problems more gracefully as applications affected by what happens to others is minimised. Cheers! D. The way I've accomplished this is by having two different instances of Resin, with different conf files. It's easy to do with 3.0.x, a little harder with 3.1.0. HTH, Jose. Vinny wrote: Hi, I am trying figure out a way to do a kind of virtual hosting based on port number. I want my production apps running under port 443 docroot : (/web/production/webapps) and my dev apps running under 8080. docroot : (/web/dev/webapps) both production and dev apps will have the same context names (like ROOT.war for example) I just need resin to differentiate on port number basically. I was thinking perhaps I could nest host/ under http/ but it seems like I will have to make a completely seperate server/ block? Is that really the case? Thanks in advance -- Ghetto Java: http://www.ghettojava.com http://www.ghettojava.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] Odd problem with JSP recompile
On Feb 2, 2007, at 4:37 PM, Gerry Panganiban wrote: The dependency list looks correct. The tag files I am changing are listed there. Although I noticed that some of the values that are being passed into the lastModified attribute are actually negative (e.g.: -6419312961657006312L) That number's just a CRC. So half of them should be negative. Are you changing the return values for things like doStartTag()? Resin's tag analysis code looks to see what values your tag can return from doStartTag() and generates optimized code based on those values. But the dependency checking code only validates the signatures, not the actual code. So it's possible that Resin isn't detecting your changes because it thinks you haven't done anything significant to the class. Does that sound possible? -- Scott --Gerry --- [EMAIL PROTECTED] wrote: From: Scott Ferguson [EMAIL PROTECTED] To: General Discussion for the Resin application server resin- [EMAIL PROTECTED] Subject: Re: [Resin-interest] Odd problem with JSP recompile Date: Fri, 2 Feb 2007 16:21:46 -0800 On Feb 2, 2007, at 3:21 PM, Gerry Panganiban wrote: This problem has been baffling me for weeks now. We are running resin (somewhat older 3.0.14 release) and I'm seeing something strange. Much of our application's interface is implemented in JSP 2.0 *.tag files. As part of our build process (using ant), we auto- generate a *.jsp file which is a simple wrapper around a main tag file, which itself embeds many other *.tag files underneath it. Normally, in our development environment, any change in the underlying tag files are detected by resin, which will then recompile the tag and redeploy just the tag files that changed and its 'parent' tags. Can you look at the generated *.java class for the JSP file? It should list the dependencies, which may give an idea why that dependency isn't being detected. -- Scott The problem is that for ONE specific wrapper tag, changes in tags underneath it are never seen by resin and does not trigger a recompile. Our only workaround so far has been to: 1) Stop the resin server 2) Rebuild the entire web app, including the auto-generated wrapper JSPs 3) Copy the entire web app's directory structure to the resin webapps directory 4) Restart the resin server This causes resin to have to *recompile* all the tag and jsp files which can be very time consuming (it takes as long as 30 minutes). What I don't understand is why for EVERY auto-generated wrapper JSP except this one, resin does not detect that a dependent tag file has been changed. I've made sure that resin.conf file has the proper settings (jsp auto-compile=true ... etc ). Another oddity is that this problem only started happening fairly recently. Nothing in the development environment has changed. Can anyone shed some light as to why this might possibly be happening? Thanks! ___ 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] Recommended ThreadStackSize for worker mpm/mod_caucho
On Feb 12, 2007, at 4:01 PM, Caleb Richardson wrote: Are there any recommended values for this Apache2 directive when using Apache2 on Linux (worker mpm). The default is 8MB, and 1MB seems to work, but I'd like to set it as low as possible if mod_caucho guarantees to operate within a fixed memory footprint. mod_caucho doesn't use too much space, so 1MB is plenty. -- Scott Thanks, Caleb Richardson ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Authenticator Tag in web.xml for Resin 3.0
On Feb 26, 2007, at 3:05 AM, Karthik_rcs wrote: HellO Team, We have some issues while migrating from 2 to 3 of resin. login-config auth-methodform/auth-method form-login-config form-login-page=/jsp/logon.jsp form-error-page=/jsp/logonerror.jsp internal-forward=true form-uri-priority=false/ authenticator class-namecom.A.B.B.C/class-name init-param serviceClass=AAA.BB.CCC/ /authenticator /login-config The Class name is kept intentionally of not exposing the internal information. I am getting the instantiation exception while starting resin with the above thing in web.xml saying error as [2007/02/26 16:35:31.765] com.caucho.config.LineConfigException: WEB-INF/web.xml:242: java.lang.InstantiationException: com.caucho.server.security.ServletAuthenticator Is your class extending com.caucho.server.security.AbstractAuthenticator? -- Scott Kindly Clarify what can be done with this Karthik R -- View this message in context: http://www.nabble.com/Authenticator- Tag-in-web.xml-for-Resin-3.0-tf3292145.html#a9156939 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] how to configure 2 https applications on the same front
On Feb 22, 2007, at 3:14 AM, Riccardo Cohen wrote: Hi I have a front server that answers request for one HTTPS application. http port=443 openssl certificate-file.../crt/certificate-file certificate-key-file.../key/certificate-key-file password???/password /openssl /http You need to have two http tags, with different address=foo.com values. Since the openssl is a child of the http, each http will have a different openssl and therefore can have different certificate-file values. -- Scott It has 4 application servers for load balancing : cluster id=art_sf srun server-id=app1 host=192.168.10.2 port=10001 index=1/ srun server-id=app2 host=192.168.10.3 port=10001 index=2/ etc.. /cluster and one webapp : host id=salesforce.articque.com web-app id='/' document-directory='/...' etc. Now we need to host a second secured application on the same front server. I will first configure a second IP address for this front server, for the certificate to work. Then I need to add host id=newapp I wonder where I can put my new certificate??? Should I add an IP in the http tag, and add a second http tag for the new application ? or should I use the port tag ? Did anyone have done this before ? Thanks PS:I use resin 3.0.18 / linux debian -- Très cordialement, Riccardo Cohen ligne directe : 02-47-49-63-24 --- Articque http://www.articque.com Moulin des Roches 37230 Fondettes - France tel : 02-47-49-90-49 fax : 02-47-49-91-49 ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] trouble with session cookie and multiple apps
On Mar 1, 2007, at 1:25 PM, luv2hike wrote: I am trying to do a seemingly simple thing, but have run into issues. I have a single instance of Resin running 2 different web apps that have nothing to do with each other except for running on the same server. If a user logs into appA then opens a new browser window or tab and logs into appB, appA's session is lost as the session cookie is common to both apps. What I need is a way to change JSESSIONID to something unique for each app. Starting another instance of Resin is not desired due to RAM and OS/X service startup issues. Can this be done? Or is there another way with one instance of Resin to support simultaneous but independent sessions in 2 or more web apps? I think we might be able to add that capability. It would look like: session-config session-cookieAPP2/session-cookie There might be a few complications in implementing it, since the load- balancer only understands a single cookie. So we might need to generate an APP2 cookie as well as a JSESSIONID cookie, where the JSESSIONID is used for sticky-sessions. -- Scott -- View this message in context: http://www.nabble.com/trouble-with- session-cookie-and-multiple-apps-tf3329855.html#a9258847 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] How to start Resin at bootup time with non-rootuser
On Mar 13, 2007, at 9:09 AM, David Campbell wrote: Kuntz, Tim wrote: Mike, You can only do this if you are running Resin Pro with a valid license. This also only works if you start Resin with watchdog as it changes the users. Actually, you can also set LD_LIBRARY_PATH=$RESIN_HOME/libexec before starting Resin and then start Resin in the foreground. The main issue is that LD_LIBRARY_PATH needs to be set to pickup the JNI code before starting the JVM. -- Scott Are you saying that this is now fixed? Does it work when invoking resin via httpd.sh? Dave -- Visit Guardian Unlimited - the UK's most popular newspaper website http://guardian.co.uk http://observer.co.uk -- The Newspaper Marketing Agency Opening Up Newspapers http://www.nmauk.co.uk -- This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group PLC Registered Office Number 1 Scott Place, Manchester M3 3GG Registered in England Number 908396 ___ 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] How to start Resin at bootup timewith non-rootuser
On Mar 13, 2007, at 10:10 AM, David Campbell wrote: Kuntz, Tim wrote: It works partly and you must invoke it using bin/httpd.sh start. The start is important because the watchdog manager won't start otherwise and that is what handles the user switching. Well it doesn't work for me on 3.19 Pro with a valid licence This only applies to 3.1.x, not 3.0.x. -- Scott Dave ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] java.util.zip.ZipException: Too many open files. Resin 3.0.14
On Mar 20, 2007, at 5:54 PM, Yogesh Gowdra wrote: Hi All, I had posted this in the past, but did not get any appropriate answer, hence posting it again. We have web application running on Caucho's resin server (3.0.14) on jdk 1.5.0_11 and Red hat Linux. We are noticing that java process is running out of file handles within 24-30 hours. We have file limit of 5000 which it consumes in 24 hours throwing 'java.util.zip.ZipException: Too many open files'. I have made sure all sorts of file handles are closed from application point of view. Here is the snapshot of lsof (list of file handles) from java process. The following list keeps growing until it runs out of limit. Do you have tips/suggestions on how to mitigate this problem (considering we dont want to increase ulimit for this process)? Also, can you make out any thing more from the description of file handles like, are they unclosed POP3 connections or URL connection to external sites? java 7156 resin 120u IPv4 34930051 UDP localhost.localdomain:59693 java 7156 resin 121u IPv4 34927823 UDP localhost.localdomain:59663 I don't know what these are from, but it looks like the likely problem. Resin uses TCP for its clustering, not UDP. Do you know what might be using UDP? If you aren't sure from the packages you're using, a thread dump might show something. -- Scott java 7156 resin 122u IPv4 34931861 UDP localhost.localdomain:59739 java 7156 resin 123u IPv4 34932023 UDP localhost.localdomain:59745 java 7156 resin 124u IPv4 34930054 UDP localhost.localdomain:59700 java 7156 resin 125u IPv4 34927826 UDP localhost.localdomain:59665 java 7156 resin 126u IPv4 34927829 UDP localhost.localdomain:59666 java 7156 resin 127u IPv4 34930057 UDP localhost.localdomain:59703 java 7156 resin 128u IPv4 34930713 UDP localhost.localdomain:59727 java 7156 resin 129u IPv4 34930716 UDP localhost.localdomain:59730 java 7156 resin 130u IPv4 34932238 UDP localhost.localdomain:59789 java 7156 resin 131u IPv4 34932026 UDP localhost.localdomain:59749 java 7156 resin 132u IPv4 34932221 UDP localhost.localdomain:59770 java 7156 resin 133u IPv4 34932224 UDP localhost.localdomain:59775 java 7156 resin 134u IPv4 34932029 UDP localhost.localdomain:59753 java 7156 resin 135u IPv4 34932032 UDP localhost.localdomain:59754 java 7156 resin 138u IPv4 34932035 UDP localhost.localdomain:59760 java 7156 resin 139u IPv4 34932038 UDP localhost.localdomain:59763 java 7156 resin 140u IPv4 34932227 UDP localhost.localdomain:59780 java 7156 resin 141u IPv4 34932230 UDP localhost.localdomain:59781 java 7156 resin 144u IPv4 34932234 UDP localhost.localdomain:59786 java 7156 resin 146u IPv4 34932241 UDP localhost.localdomain:59792 java 7156 resin 147u IPv4 34932247 UDP localhost.localdomain:59802 Thanks ___ 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] Persistent store - issue with select query
On Mar 21, 2007, at 10:36 AM, Jaswinder Kaur wrote: Does anyone has any suggestion ? Date: Mon, 19 Mar 2007 17:56:44 -0700 From: Jaswinder Kaur [EMAIL PROTECTED] Subject: Re: [Resin-interest] Persistent store - issue with select query To: resin-interest@caucho.com Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Hello I am running into 2 issues with resin upgrade. 1. The following query is executing around 7 times more on server 2 than server 1. SELECT ACCESS_TIME, DATA FROM SRUN_SERVER2 WHERE ID= ? 2. The srun*.db file keeps increasing in size? The specifics: We are using resin-pro 3.0.21 and jdk 1.4.2_03. There are two servers in the farm that are using cluster store for the sessions. Below is a snippet of resin.conf. There were a number of distributed session fixes between 3.0.21 and 3.0.23. 3.1 has some additional distributed session fixes. -- Scott http server-id=server1 host=server1 port=80/ http server-id=server2 host=server2 port=80/ http server-id=server1 host=server1 port=443 openssl . /openssl /http http server-id=server2 host=server2 port=443 openssl . /openssl /http cluster srun server-id=server1 host=server1 port=6802/ srun server-id=server2 host=server2 port=6802/ /cluster persistent-store type=cluster init path=cluster/ /persistent-store web-app id=/ session-config cookie-domain=vsp.com use-persistent-store/ /session-config /web-app The problems that we are experiencing could they be related to the above configuration or resin itself? Thank you in advance. == Attention: This message is intended only for the individual to whom it is addressed and may contain information that is confidential or privileged. If you are not the intended recipient, or the employee or person responsible for delivering it to the intended recipient, you are hereby notified that any dissemination, distribution, copying or use is strictly prohibited. If you have received this communication in error, please notify the sender and destroy or delete this communication immediately. == ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Quercus GD lib
On Mar 23, 2007, at 11:56 AM, Gregory Stewart wrote:
Has anybody here noticed issues with the Quercus image module ('gd')?
I am trying to resize a few jpg and gif files. It works with some jpg
files only, and none of the gif files.
What version of GD is the library? 1 or 2?
It's not using GD, it's using the JDK's awt. So either the Quercus
adapter isn't properly translating the calls or the JDK isn't
resizing properly. (Most likely it's an adapter issue.)
-- Scott
We probably are going to switch over to JMagick for now, as a quick
fix.
Greg
___
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] HELP: caucho-status duplicate hosts!
On Mar 29, 2007, at 6:13 AM, Stargazer wrote: Adam Allgaier wrote: That did the trick! Really appreciate your expertise. Your steak is on the way Is this being looked at by Caucho (please)? Yes, it's one of the things we're looking at before the 3.1.1 release. -- Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] one resin, one host, but two ports?
On Mar 30, 2007, at 3:33 PM, Jay Ballinger wrote: I am setting up a new resin installation and ran into a fork in the config. We would like to have http://foo.bar.com and https://foo.bar.com to be answered by the same resin, but with different webapps defined for each. http://foo.bar.com would answer with a welcome page while ... https://foo.bar.com would have all the functional pages. Looking at the resin.conf file, I find the following options... 1 - configure a different host which would require foo.bar.com:80 and baz.bar.com:443 to be defined if I want to run with one resin instance. 2 - run separate resin instances - one for port 80 and the other for port 443 3 - run one resin instance and allow both ports to serve all content (and do some fancy url checking in the application to keep them parked on 443) Is there any possible way to have one resin instance with port 80 defined with a webapp and port 443 defined with different webapps? Sure, just use host id=bar.baz.com .. /host host id=bar.baz.com:443 ... /host -- Scott Thanks for the help. + jay ___ 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?
On Mar 31, 2007, at 9:41 PM, Jay Ballinger wrote: Scott, I've been playing around with the host / directives and could use a little help. If I explicitly set the listen ports to 8080 and 8443, and then if I set the host names to foo.bar.com and foo.bar.com:8443, it works exactly as expected by serving pages from different webapp directories. But I was hoping to not have to set a host name at all. I'm not sure I understand. If you want different webapp directories, you need separate host/ blocks. Otherwise it's the same host, not two different ones. So I don't understand how you would have two different directories without setting a host name. -- Scott If I set the hosts to and :8443, I get both ports serving from the same webapps directory (the one set for port 8080). If I set the hosts to :8080 and :8443, I get a 404 error saying the / was not found, and the console reports that web-app root directory should not be the same as resin.home and it appears to try to start a non-existant webapp (WebApp[] starting). I tried *:8443, but got a stack trace on server start. I was really hoping to not have to set a host name at all. I would like to simply have any request hitting port 8080 served from one set of defined webapps, while all requests hitting port 8443 served from another set of defined webapps regardless of which host name has brought the user to this server. Is this possible? + jay On 3/30/07, Jay Ballinger [EMAIL PROTECTED] wrote: Thanks, Scott. I was about to try that combo, but hadn't done it yet. (I have a laundry list of config items to try.) I think I remember you giving that same solution to someone a few weeks ago, now that I think about it. Might be a good candidate for some examples in the docs. ;) Thanks again! + jay On 3/30/07, Scott Ferguson [EMAIL PROTECTED] wrote: On Mar 30, 2007, at 3:33 PM, Jay Ballinger wrote: I am setting up a new resin installation and ran into a fork in the config. We would like to have http://foo.bar.com and https://foo.bar.com to be answered by the same resin, but with different webapps defined for each. http://foo.bar.com would answer with a welcome page while ... https://foo.bar.com would have all the functional pages. Looking at the resin.conf file, I find the following options... 1 - configure a different host which would require foo.bar.com: 80 and baz.bar.com:443 to be defined if I want to run with one resin instance. 2 - run separate resin instances - one for port 80 and the other for port 443 3 - run one resin instance and allow both ports to serve all content (and do some fancy url checking in the application to keep them parked on 443) Is there any possible way to have one resin instance with port 80 defined with a webapp and port 443 defined with different webapps? Sure, just use host id=bar.baz.com .. /host host id=bar.baz.com:443 ... /host -- Scott Thanks for the help. + jay ___ 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] one resin, one host, but two ports?
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 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. Thanks, again, for the help, Scott. Hopefully I was a little clearer this time in what I am trying to accomplish. + jay On 4/2/07, Scott Ferguson [EMAIL PROTECTED] wrote: On Mar 31, 2007, at 9:41 PM, Jay Ballinger wrote: Scott, I've been playing around with the host / directives and could use a little help. If I explicitly set the listen ports to 8080 and 8443, and then if I set the host names to foo.bar.com and foo.bar.com:8443, it works exactly as expected by serving pages from different webapp directories. But I was hoping to not have to set a host name at all. I'm not sure I understand. If you want different webapp directories, you need separate host/ blocks. Otherwise it's the same host, not two different ones. So I don't understand how you would have two different directories without setting a host name. -- Scott If I set the hosts to and :8443, I get both ports serving from the same webapps directory (the one set for port 8080). If I set the hosts to :8080 and :8443, I get a 404 error saying the / was not found, and the console reports that web-app root directory should not be the same as resin.home and it appears to try to start a non-existant webapp (WebApp[] starting). I tried *:8443, but got a stack trace on server start. I was really hoping to not have to set a host name at all. I would like to simply have any request hitting port 8080 served from one set of defined webapps, while all requests hitting port 8443 served from another set of defined webapps regardless of which host name has brought the user to this server. Is this possible? + jay On 3/30/07, Jay Ballinger [EMAIL PROTECTED] wrote: Thanks, Scott. I was about to try that combo, but hadn't done it yet. (I have a laundry list of config items to try.) I think I remember you giving that same solution to someone a few weeks ago, now that I think about it. Might be a good candidate for some examples in the docs. ;) Thanks again! + jay On 3/30/07, Scott Ferguson [EMAIL PROTECTED] wrote: On Mar 30, 2007, at 3:33 PM, Jay Ballinger wrote: I am setting up a new resin installation and ran into a fork in the config. We would like to have http://foo.bar.com and https://foo.bar.com to be answered by the same resin, but with different webapps defined for each. http://foo.bar.com would answer with a welcome page while ... https://foo.bar.com would have all the functional pages. Looking at the resin.conf file, I find the following options... 1 - configure a different host which would require foo.bar.com: 80 and baz.bar.com:443 to be defined if I want to run with one resin instance. 2 - run separate resin instances - one for port 80 and the other for port 443 3 - run one resin instance and allow both ports to serve all content (and do some fancy url checking in the application to keep them parked on 443) Is there any possible way to have one resin instance with port 80 defined with a webapp and port 443 defined with different webapps? Sure, just use host id=bar.baz.com .. /host host id=bar.baz.com:443 ... /host -- Scott Thanks for the help. + jay ___ 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
Re: [Resin-interest] mod_caucho, Solaris 10, Apache 2.2.4 problem
On Apr 18, 2007, at 2:42 PM, Mica Cooper wrote: I also did a fresh install of the latest Apache and was unable to get the proxy to work. I posted here to the list but no one responded. This was last Thursday with 2.2.4 and Windows. Windows should be an entirely different issue, because windows has precompiled dlls. (Unless I misunderstood the question before, since that was mod_caucho.dll for 2.0 vs 2.2.) I'm not sure why 2.2.4 would behave any differently than 2.2.0. That's not the sort of thing that should vary in a .4 release, but we'll test 3.1.1 against 2.2.4 before releasing it to see if we can find anything. -- Scott Mica -Original Message- From: [EMAIL PROTECTED] [mailto:resin-interest- [EMAIL PROTECTED] Behalf Of Jonathan Millett Sent: Wednesday, April 18, 2007 4:32 PM To: resin-interest@caucho.com Subject: [Resin-interest] mod_caucho, Solaris 10, Apache 2.2.4 problem I just upgraded from apache 2.2.0 to 2.2.4 and mod_caucho no longer connects to resin. Is this a known issue? I have both resin 3.0.19 and 3.0.23 installed. The mod_caucho is compiled with gcc4 (I don't have a copy of the sun compiler) Both versions of resin/mod_caucho work with apache 2.2.0, and neither work with apache 2.2.4. I don't see any error messages, apache just happily serves up the .jsp files unmodified. Apache was installed from the blastwave stable repository. Thanks, Jon ___ 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?
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. We've made some changes to the classloading of the boot classes and JNI loading which should avoid some of the problems people have seen with 3.1.0. The uid lookup is in modules/c/src/resin/boot.c in Java_com_caucho/boot_JniProcess_exec Look for getpwnam. -- Scott I'll go look for Scott's message in particular. On Wed, 25 Apr 2007, Kuntz, Tim wrote: Nick, Did you search the archives for user and groups? There have been a number of posts about that issue in the last month that might help you. Some items mentioned... * must be running resin pro * must start resin with the watchdog process not directly * problems with port 443 user/group binding Scott from Caucho had provided some detailed information. -- Humans are a dangerously insane and very sick species. -- Eckhart Tolle This message has been brought to you by Nick Johnson 2.2 and the number 6. http://healerNick.com/ http://morons.org/http:// spatula.net/ ___ 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?
On Apr 25, 2007, at 4:03 PM, Gary Zhu wrote: In general, does the snapshot version always represent(or close to) the upcoming release ? It's a build based on our current development tree. So it's the most up-to-date version we have. 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 ? Yes. If the snapshot date is after the bug fix date, it will have the bug fix. If you're still seeing the same problem with a snapshot after the bug fix date, please report it as a new bug. (Our test case might find a closely-related bug, but there might be a second case that we didn't catch.) I understand snapshot version is not production release. Right. The snapshot is great for verifying bug fixes before the release, but not suitable for production. -- Scott Gary Zhu ___ 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] Jmx in Resin 3.0.23 with JRockit R27.2.0
On Apr 26, 2007, at 3:21 AM, Sandro Gattuso wrote: Hi, I've tried to use Jmx in Resin 3.0.23 with JRockit-R27.2.0-jdk1.6.0 but I've this stacktrace on console You might need to check the classpath that JRockit is starting with. It looks like JRockit isn't including the resin.jar when it's looking for its JMX startup. -- Scott javax.management.JMRuntimeException: Failed to load MBeanServerBuilder class com.caucho.jmx.MBeanServerBuilderImpl: java .lang.ClassNotFoundException: com.caucho.jmx.MBeanServerBuilderImpl at javax.management.MBeanServerFactory.checkMBeanServerBuilder (MBeanServerFactory.java:480) at javax.management.MBeanServerFactory.getNewMBeanServerBuilder (MBeanServerFactory.java:511) at javax.management.MBeanServerFactory.newMBeanServer (MBeanServerFactory.java:298) at javax.management.MBeanServerFactory.createMBeanServer (MBeanServerFactory.java:213) at javax.management.MBeanServerFactory.createMBeanServer (MBeanServerFactory.java:174) at sun.management.ManagementFactory.createPlatformMBeanServer (ManagementFactory.java:302) at java.lang.management.ManagementFactory.getPlatformMBeanServer (ManagementFactory.java:504) at sun.management.jmxremote.ConnectorBootstrap.initialize (ConnectorBootstrap.java:360) at sun.management.Agent.startAgent(Agent.java:127) at sun.management.Agent.startAgent(Agent.java:239) at bea.jrockit.management.server.Main.start0(Main.java:291) at bea.jrockit.management.server.Main.access$000(Main.java:53) at bea.jrockit.management.server.Main$2.run(Main.java:377) at bea.jrockit.management.server.Main.start(Main.java:375) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at jrockit.management.AgentStarter.startAgent(Unknown Source) Caused by: java.lang.ClassNotFoundException: com.caucho.jmx.MBeanServerBuilderImpl at java.lang.ClassLoader.findClass(ClassLoader.java:358) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at javax.management.MBeanServerFactory.loadBuilderClass (MBeanServerFactory.java:423) at javax.management.MBeanServerFactory.checkMBeanServerBuilder (MBeanServerFactory.java:465) ... 18 more Eccezione dell'agente : javax.management.JMRuntimeException: Failed to load MBeanServerBuilder class com.caucho.jmx.MBea nServerBuilderImpl: java.lang.ClassNotFoundException: com.caucho.jmx.MBeanServerBuilderImpl java.lang.RuntimeException: javax.management.JMRuntimeException: Failed to load MBeanServerBuilder class com.caucho.jmx. MBeanServerBuilderImpl: java.lang.ClassNotFoundException: com.caucho.jmx.MBeanServerBuilderImpl at sun.management.Agent.error(Agent.java:309) at sun.management.Agent.startAgent(Agent.java:153) at sun.management.Agent.startAgent(Agent.java:239) at bea.jrockit.management.server.Main.start0(Main.java:291) at bea.jrockit.management.server.Main.access$000(Main.java:53) at bea.jrockit.management.server.Main$2.run(Main.java:377) at bea.jrockit.management.server.Main.start(Main.java:375) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at jrockit.management.AgentStarter.startAgent(Unknown Source) Caused by: javax.management.JMRuntimeException: Failed to load MBeanServerBuilder class com.caucho.jmx.MBeanServerBuilde rImpl: java.lang.ClassNotFoundException: com.caucho.jmx.MBeanServerBuilderImpl at javax.management.MBeanServerFactory.checkMBeanServerBuilder (MBeanServerFactory.java:480) at javax.management.MBeanServerFactory.getNewMBeanServerBuilder (MBeanServerFactory.java:511) at javax.management.MBeanServerFactory.newMBeanServer (MBeanServerFactory.java:298) at javax.management.MBeanServerFactory.createMBeanServer (MBeanServerFactory.java:213) at javax.management.MBeanServerFactory.createMBeanServer (MBeanServerFactory.java:174) at sun.management.ManagementFactory.createPlatformMBeanServer (ManagementFactory.java:302) at java.lang.management.ManagementFactory.getPlatformMBeanServer (ManagementFactory.java:504) at sun.management.jmxremote.ConnectorBootstrap.initialize (ConnectorBootstrap.java:360) at
[Resin-interest] Resin 3.1.1 is available
We've released Resin 3.1.1 The release notes are at http://caucho.com/resin-3.1/changes/ resin-3.1.1.xtp. Amber: JPA is ready to use and is nearly complete. The main missing functionality is extended transactions. But unless you're actually using those, the other functionality is complete. Web Services: The most commonly-used features of JAXB, JAX-WS and SAAJ are now available, except for Java code generation from XSchema or WSDL. Quercus: Improved Java integration and continued bug fixes and compatibility testing. Quercus now supports import com.foo.*; as a way to instantiate java objects. rewrite-dispatch: The rewriting rules can now look at HTTP header values to dispatch requests. Administration: New capabilities and displays of thread dumps, profiling, memory dumps, and caching. The profiling has low overhead, so it would be possible to enable profiling on some production servers to get real performance data. We strongly recommend looking at the new profiling and caching displays to help improve your application's cachability and performance. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] XML View Question
On May 8, 2007, at 9:51 AM, Aaron Freeman wrote:
Can anybody provide me with any links/hints on this?
JSP 2.1 has a trimDirectiveWhitespace option for the %@ page %
tag. That would be the cleanest way to remove the extra whitespace.
-- Scott
Thanks,
Aaron
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Aaron Freeman
Sent: Thursday, May 03, 2007 10:59 AM
To: resin-interest@caucho.com
Subject: [Resin-interest] XML View Question
We have a controller JSP that looks like this:
Begin Controller %@ taglib
uri=http://java.sun.com/jsp/jstl/core; prefix=c % %@
taglib uri=http://java.sun.com/jsp/jstl/functions; prefix=fn %
c:catch var=exception
... do some logic
/c:catch
c:choose
c:when test=${empty exception param.o == 'xml'}
jsp:include page=/xml/_view.jsp/
/c:when
c:when test=${empty exception}
jsp:include page=/html/_view.jsp/ /c:when
%-- An exception occured. --%
c:when test=${param.o == 'xml'}
jsp:include page=/xml/_error_view.jsp/ /c:when c:otherwise
jsp:include page=/html/_error_view.jsp/ /c:otherwise
/c:choose
End Controller
Then our xml/_view.jsp would look something like this:
Begin xml/_view.jsp jsp:root
version=2.0
jsp:directive.taglib uri=http://java.sun.com/jsp/jstl/core;
prefix=c /
?xml version=1.0 encoding=UTF-8?
result
c:forEach ...
... output some XML tags
/c:forEach
/result
/jsp:root
End xml/_view.jsp
The problem is sometimes the end result has a bunch of white
space at the beginning of the document and sometimes the
c:forEach generates lots of linefeeds which cause XML
parsers to fail. What is the proper way to dump an XML view
such that there are no linefeeds in between the XML tags and
there isn't a lot of whitespace above the XML?
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Authenticator Tag in web.xml for Resin 3.0
On May 11, 2007, at 3:30 PM, Kumar66 wrote: Hello Everyone, I am also running into the same problem with Resin 3.0. Is there is a fix or workaround for this problem ? Can you try pulling the authenticator out of the login-config? Also, try using: authenticator typecom.foo.MyAuthenticator/type ... /authenticator login-config ... /login-config Also, you should be extending your authenticator from com.caucho.server.security.AbstractAuthenticator instead of implementing ServletAuthenticator directly (if you're not already doing that.) -- Scott Thanks in advance. -Kumar Karthik_rcs wrote: HellO Team, We have some issues while migrating from 2 to 3 of resin. login-config auth-methodform/auth-method form-login-config form-login-page=/jsp/logon.jsp form-error-page=/jsp/logonerror.jsp internal-forward=true form-uri-priority=false/ authenticator class-namecom.A.B.B.C/class-name init-param serviceClass=AAA.BB.CCC/ /authenticator /login-config The Class name is kept intentionally of not exposing the internal information. I am getting the instantiation exception while starting resin with the above thing in web.xml saying error as [2007/02/26 16:35:31.765] com.caucho.config.LineConfigException: WEB-INF/web.xml:242: java.lang.InstantiationException: com.caucho.server.security.ServletAuthenticator Kindly Clarify what can be done with this Karthik R -- View this message in context: http://www.nabble.com/Authenticator- Tag-in-web.xml-for-Resin-3.0-tf3292145.html#a10440459 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] 304 status
On May 17, 2007, at 10:02 AM, 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. What are the headers for the JSP page? With no caching headers, Resin doesn't cache at all, i.e. no-cache is the default. So the 304 is strange, unless the headers are telling Resin to cache. (Serge's recommendations are good ones for general understanding of HTTP caching, but the described behavior seems odd.) -- Scott 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
Re: [Resin-interest] 304 status
On May 18, 2007, at 5:02 AM, Alex Sharaz wrote: Other times I get the 304 status code. We've got random occurrences where setting a browser to auto detect proxy settings doesn't work and i'm wondering if these occurrences could coincide with the 304 status codes I can see in the logs. I suppose the question is. Can i reconfigure something to get rid of the 304 entries in the logs? I'm a little confused. I can add a bug report to allow filtering of 304 in the logs, but I'm not sure if there's another issue you're reporting. -- Scott Alex -Original Message- From: [EMAIL PROTECTED] [mailto:resin-interest- [EMAIL PROTECTED] On Behalf Of Scott Ferguson Sent: 17 May 2007 18:45 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] 304 status On May 17, 2007, at 10:02 AM, 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. What are the headers for the JSP page? With no caching headers, Resin doesn't cache at all, i.e. no-cache is the default. So the 304 is strange, unless the headers are telling Resin to cache. (Serge's recommendations are good ones for general understanding of HTTP caching, but the described behavior seems odd.) -- Scott 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** *** To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html ** ***___ 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] request: for openads comp on quercus
On May 22, 2007, at 11:33 AM, atomi wrote: Hi, Just wanted to respectfully request compatibility assurance for openads. Thanks. I've just added a bug report: http://bugs.caucho.com/ view.php?id=1753 -- Scott I'm having trouble getting through the database tables creations phase of the install and I'm not getting any error messages. Since it's a popular ad server I thought I'd just put that out there. thanks, atomi ___ 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] Problems with ADF faces application on JBoss 3.1.1
On May 24, 2007, at 7:31 AM, Taber, Guthrie wrote: I figured this was due to the conflict of the jsf-12.jar shipped with Resin 3.1.1 and the jsf .jars shipped with the adf sample application. Yes, you should delete the jsf-12.jar. That's not supposed to be released yet. I just removed the jsf jar from Resin_home/lib and restarted. Upon this I get the following error: [13:38:43.621] java.lang.NullPointerException [13:38:43.621] at javax.faces.webapp.FacesServlet.init (FacesServlet.java:144) You need to add a listener listener-class=.../ to the web.xml to force JSF to initialize the default implementation. The classname would depend on which JSF implementation you're using. -- Scott [13:38:43.621] at com.caucho.server.dispatch.ServletConfigImpl.createServletImpl (ServletConfigImpl.java:776) [13:38:43.621] at com.caucho.server.dispatch.ServletConfigImpl.createServlet (ServletConfigImpl.java:707) [13:38:43.621] at com.caucho.server.dispatch.ServletManager.init (ServletManager.java:150) [13:38:43.621] at com.caucho.server.webapp.WebApp.start (WebApp.java:1726) [13:38:43.621] at com.caucho.server.deploy.DeployController.startImpl (DeployController.java:623) [13:38:43.621] at com.caucho.server.deploy.StartAutoRedeployAutoStrategy.startOnInit (StartAutoRedeployAutoStrategy.java:72) [13:38:43.621] at com.caucho.server.deploy.DeployController.startOnInit (DeployController.java:505) [13:38:43.621] at com.caucho.server.deploy.DeployContainer.start (DeployContainer.java:155) [13:38:43.621] at com.caucho.server.webapp.WebAppContainer.start (WebAppContainer.java:671) [13:38:43.621] at com.caucho.server.host.Host.start(Host.java:437) [13:38:43.621] at com.caucho.server.deploy.DeployController.startImpl (DeployController.java:623) [13:38:43.621] at com.caucho.server.deploy.StartAutoRedeployAutoStrategy.startOnInit (StartAutoRedeployAutoStrategy.java:72) [13:38:43.621] at com.caucho.server.deploy.DeployController.startOnInit (DeployController.java:505) [13:38:43.621] at com.caucho.server.deploy.DeployContainer.start (DeployContainer.java:155) [13:38:43.621] at com.caucho.server.host.HostContainer.start (HostContainer.java:473) [13:38:43.621] at com.caucho.server.cluster.Server.start (Server.java:1092) [13:38:43.621] at com.caucho.server.cluster.Cluster.startServer (Cluster.java:689) [13:38:43.621] at com.caucho.server.cluster.ClusterServer.startServer (ClusterServer.java:431) [13:38:43.621] at com.caucho.server.resin.Resin.start(Resin.java:710) [13:38:43.621] at com.caucho.server.resin.Resin.initMain (Resin.java:1146) [13:38:43.621] at com.caucho.server.resin.Resin.main(Resin.java:1343) [13:38:43.627] javax.servlet.ServletException: java.lang.NullPointerException [13:38:43.627] at com.caucho.server.dispatch.ServletConfigImpl.createServlet (ServletConfigImpl.java:745) [13:38:43.627] at com.caucho.server.dispatch.ServletManager.init (ServletManager.java:150) [13:38:43.627] at com.caucho.server.webapp.WebApp.start (WebApp.java:1726) [13:38:43.627] at com.caucho.server.deploy.DeployController.startImpl (DeployController.java:623) [13:38:43.627] at com.caucho.server.deploy.StartAutoRedeployAutoStrategy.startOnInit (StartAutoRedeployAutoStrategy.java:72) [13:38:43.627] at com.caucho.server.deploy.DeployController.startOnInit (DeployController.java:505) [13:38:43.627] at com.caucho.server.deploy.DeployContainer.start (DeployContainer.java:155) [13:38:43.627] at com.caucho.server.webapp.WebAppContainer.start (WebAppContainer.java:671) [13:38:43.627] at com.caucho.server.host.Host.start(Host.java:437) [13:38:43.627] at com.caucho.server.deploy.DeployController.startImpl (DeployController.java:623) [13:38:43.627] at com.caucho.server.deploy.StartAutoRedeployAutoStrategy.startOnInit (StartAutoRedeployAutoStrategy.java:72) [13:38:43.627] at com.caucho.server.deploy.DeployController.startOnInit (DeployController.java:505) [13:38:43.627] at com.caucho.server.deploy.DeployContainer.start (DeployContainer.java:155) [13:38:43.627] at com.caucho.server.host.HostContainer.start (HostContainer.java:473) [13:38:43.627] at com.caucho.server.cluster.Server.start (Server.java:1092) [13:38:43.627] at com.caucho.server.cluster.Cluster.startServer (Cluster.java:689) [13:38:43.627] at com.caucho.server.cluster.ClusterServer.startServer (ClusterServer.java:431) [13:38:43.627] at com.caucho.server.resin.Resin.start(Resin.java:710) [13:38:43.627] at com.caucho.server.resin.Resin.initMain (Resin.java:1146) [13:38:43.627] at com.caucho.server.resin.Resin.main(Resin.java:1343) [13:38:43.627] Caused by: java.lang.NullPointerException [13:38:43.627] at javax.faces.webapp.FacesServlet.init (FacesServlet.java:144) [13:38:43.627] at com.caucho.server.dispatch.ServletConfigImpl.createServletImpl (ServletConfigImpl.java:776) [13:38:43.627] at com.caucho.server.dispatch.ServletConfigImpl.createServlet
Re: [Resin-interest] Connection Reset message
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
Re: [Resin-interest] JDBCSession-Store gives java.io.StreamCorruptedException
On May 27, 2007, at 12:07 PM, Jan Kriesten wrote: hi, i'm getting the following exception using resin pro 3.1.1 / jdk 1.6 / mysql / mysql-connector 5.0.6: ---8--- [21:01:53.998] java.io.StreamCorruptedException: invalid type code: 00 [21:01:53.998] at I've reported it as a bug: http://bugs.caucho.com/view.php?id=1764. I don't know why that would occur. -- Scott java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1356) [21:01:53.998] at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java: 1945) [21:01:53.998] at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1869) [21:01:53.998] at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1753) [21:01:53.998] at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) [21:01:53.998] at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java: 1945) [21:01:53.998] at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1869) [21:01:53.998] at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1753) [21:01:53.998] at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) [21:01:53.998] at java.io.ObjectInputStream.readObject (ObjectInputStream.java:351) [21:01:53.998] at com.caucho.server.session.SessionImpl.load (SessionImpl.java:962) [21:01:53.998] at com.caucho.server.session.SessionManager.load(SessionManager.java: 1507) [21:01:53.998] at com.caucho.server.cluster.ClusterObject.load(ClusterObject.java:301) [21:01:53.998] at com.caucho.server.cluster.JdbcStore.load (JdbcStore.java:221) [21:01:53.998] at com.caucho.server.cluster.ClusterObject.load(ClusterObject.java:268) [21:01:53.998] at com.caucho.server.session.SessionImpl.load (SessionImpl.java:741) [21:01:53.998] at com.caucho.server.session.SessionManager.load(SessionManager.java: 1444) [21:01:53.998] at com.caucho.server.session.SessionManager.getSession (SessionManager.java:1303) [21:01:53.998] at com.caucho.server.connection.AbstractHttpRequest.createSession (AbstractHttpRequest.java:1455) [21:01:53.998] at com.caucho.server.connection.AbstractHttpRequest.getSession (AbstractHttpRequest.java:1270) [21:01:53.998] at org.apache.wicket.protocol.http.AbstractHttpSessionStore.getSessionId( AbstractHttpSessionStore.java:179) [21:01:53.998] at org.apache.wicket.Session.bind(Session.java:420) ---8--- can anyone enlighten me, why this occurs? best regards, --- jan. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Weird log messages about JniSelect add-native failing
On May 28, 2007, at 11:24 PM, Kai Virkki wrote: Hi! We're getting following messages to the jvm.log with Resin 3.0.15: [08:01:20.953] JniSelect: add-native failed 7036 - -1 for TcpConnection[id=resin-tcp-connection-*:80-149,socket=JniSocketImpl $18322855[1238601824],port=Port[null:80]] Is there any reason to be worried about them? Has anyone else witnessed these kind of messages? We haven't been able to connect these to the problems we're having with Resin, but it would be nice to know more what's going on. Yes, it's something to be concerned about. For some reason, the select/poll keepalive is failing. Resin will recover, so it wouldn't be visible, but it is an internal assertion failure. There have been fixes to the select/poll since 3.0.15, so you may want to disable the select as a workaround. -- Scott regards, Kai ___ 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] hessian init endless loop (line 182, 300, 194, 300, 194, etc.)
On Jun 5, 2007, at 8:04 PM, Vic Cekvenich wrote: OK, here is how I patched it to make it work in HessianServlet: I added the bug report as: http://bugs.caucho.com/view.php?id=1779 It'll be fixed for 3.1.2. -- Scott // in method private void init(... service.init(); // instead of service.init(getSeverltConfig(); This is if you use IOC api/home hessian, old code works as hessian servlet. Above fix should work for both. I'd love for this to be patched into the builds so I do not have to use my hessian. .V Vic Cekvenich wrote: Went back to java 1.5.012 ... same! .V Vic Cekvenich wrote: (Love resin, Love hessina, been using both for a while). I do a simple hessian service... like I always did, and it goes to init endless loop. Bellow is the browser output. To test hessian normally I just have havingate to it's url to get the error hessian requires a post. Now I get this endless init loop. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Command line Quercus?
On Jun 14, 2007, at 12:23 PM, Stargazer wrote: Theres more to php than webapps. Some systems use it from cron, e.g. to suck in rss feeds as in php import_rss.php. This relies on the fact that php from the command line invokes php. Whats the equivalent under quercus please? Basically, a run-at servlet or the equivalent. If you get a RequestDispatcher to the import_rss.php, then you can forward a dummy request/response. It may be common enough that we might want to create another QuercusServlet that just handles cron-type jobs. -- Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Closing dangling connections error
On Jun 18, 2007, at 2:18 AM, koyama wrote:
Hello.
I hava error message from resin 3.1.1
I found status at http://bugs.caucho.com/view.php?id=998.
This is most likely a bug in application code. You need a finally
{ conn.close() } for all connections. You want to look for the next
stack trace, which would show when the connection was allocated
(which will make debugging easier.)
That bug report is referring to the Amber stack trace specifically.
It is not a general report on the dangling connections.
Does resin 3.1.1 have this problem yet ?
It's not a resin problem. It's an application bug that resin 3.1.1
is detecting and reporting.
-- Scott
Closing dangling connections. All connections must have a close()
in a
finally block
java.lang.IllegalStateException: Connection
UserConnection[com.caucho.sql.ManagedConn
[EMAIL PROTECTED] was not closed. Connections must have a close()
in a
finally block.
at
com.caucho.jca.UserTransactionImpl.abortTransaction
(UserTransactionImpl.java:498)
at
com.caucho.jca.UserTransactionProxy.abortTransaction
(UserTransactionProxy.java:182)
at
com.caucho.server.webapp.WebAppFilterChain.doFilter
(WebAppFilterChain.java:195)
at
com.caucho.server.dispatch.ServletInvocation.service
(ServletInvocation.java:240)
at com.caucho.server.http.HttpRequest.handleRequest
(HttpRequest.java:263)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:477)
at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:600)
at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:522)
at java.lang.Thread.run(Thread.java:595)
___
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] Hard to find the root of the exception.
On Jun 20, 2007, at 7:58 PM, Bharath CP wrote: It has become a very difficult job to get to the root of jsp exceptions. The stack trace's last reference to the code is pageContext.handlePageException(_jsp_e); in the compiled jsp (_hotel_0details_0base__jsp.java:483). And this line of code is in the catch block. This line of code (pageContext.handlePageException(_jsp_e);) is there in almost all jsps and it appears to me that all the exceptions that occur are traced only from here though it is very clear that the exception has happened elsewhere. It also doesnot say what kind of exception. Your error reporting code needs to print out the entire stack trace. Wrapped exceptions normally report the getCause() exception as well, but it's possible for error reporting code to only print out the outer wrapper (which isn't particularly useful.) -- Scott Can anyone help me understand how i get to the actual place where the exception is thrown or give me a link to some page or document that might help in solving this problem. below is the stack trace: ERROR com.hcomemea.common.RESPONSEINFO 2007-06-19 16:58:11,956 [tcpConnection-9021-4062] [nl_NL] [aM709nxLgu87] - Could not process the request: /pageDetails.do javax.servlet.jsp.JspException: Exception thrown by getter for property alternativeChoiceURI of bean alternativeHotelViewHelper at com.caucho.jsp.QPageContext.handlePageException(QPageContext.java:669) at _WEB_22dINF._HCOM_0APP._propertysearch._hotel_0details._hotel_0details _0base__jsp._jspService(_hotel_0details_0base__jsp.java:483) at com.caucho.jsp.JavaPage.service(JavaPage.java:75) at com.caucho.jsp.Page.subservice(Page.java:506) at com.caucho.server.http.FilterChainPage.doFilter (FilterChainPage.java:182) at com.caucho.server.http.Invocation.service (Invocation.java:315) at com.caucho.server.http.CacheInvocation.service(CacheInvocation.java: 115) at com.caucho.server.http.QRequestDispatcher.forward (QRequestDispatcher.java:223) at com.caucho.server.http.QRequestDispatcher.forward (QRequestDispatcher.java:103) at com.caucho.server.http.QRequestDispatcher.forward (QRequestDispatcher.java:80) at org.apache.struts.action.RequestProcessor.doForward (RequestProcessor.java:1063) at org.apache.struts.tiles.TilesRequestProcessor.doForward (TilesRequestProcessor.java:263) at org.apache.struts.tiles.TilesRequestProcessor.processTilesDefinition (TilesRequestProcessor.java:239) at org.apache.struts.tiles.TilesRequestProcessor.processForwardConfig (TilesRequestProcessor.java:302) at org.apache.struts.action.RequestProcessor.process (RequestProcessor.java:229) at org.apache.struts.action.ActionServlet.process(ActionServlet.java: 1194) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414) at javax.servlet.http.HttpServlet.service(HttpServlet.java: 126) at javax.servlet.http.HttpServlet.service(HttpServlet.java: 103) at com.caucho.server.http.FilterChainServlet.doFilter (FilterChainServlet.java:96) at com.caucho.server.http.Invocation.service (Invocation.java:315) at com.caucho.server.http.CacheInvocation.service(CacheInvocation.java: 115) at com.caucho.server.http.QRequestDispatcher.forward (QRequestDispatcher.java:223) at com.caucho.server.http.QRequestDispatcher.forward (QRequestDispatcher.java:103) -- View this message in context: http://www.nabble.com/Hard-to-find- the-root-of-the-exception.-tf3956243.html#a11225907 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] application variables, j2ee - php, and shared nothing
On Jun 26, 2007, at 6:08 AM, Nathan Nobbe wrote: all, im curious about application variables under the j2ee web application paradigm. are these used frequently in the context of application servers, like resin, or are they regarded as taboo? For the most part, application state (i.e. single-jvm data) is either configuration or caching/pooling. It's not common to put non-cache state on a single JVM because it doesn't scale. also, has anyone heard of the shared nothing architecture? how does that pertain, if at all, to the j2ee paradigm? That article looks misleading for j2ee (and also for php). For many (most?) major sites, the database is the major headache, and that shared database doesn't really count as shared nothing. A major difference between php and j2ee is caching/pool. Php essentially does zero caching on the app server tier, so some larger sites dedicate a separate tier for caching (e.g. dedicated memcache servers.) J2ee tends to cache on the app-server tier itself, which is simpler and more efficient than the separate caching tier. So there is state on each JVM for j2ee, but it's generally cache/ pooling state, not application state. i was discussing application variables w/ some members of php- general and from the sound of it; they are taboo in the php world. Yes, well, it's difficult to cache/share state in php at all, and thread synchronization is essentially non-existent, so it's taboo mostly because the capability doesn't really exist. (Quercus does not share this PHP limitation, by the way. It's entirely possible to use a Java layer for caching/pooling and expose the cached/pooled values to a PHP layer.) -- Scott can any quercus users shed some light on this conundrum? thanks, -nathan ___ 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] How to set default/global response encoding?
On Jun 27, 2007, at 7:59 AM, Hans Loeblich wrote: I need to know if there is any way to make UTF-8 my default charset encoding. Do I really have to set the page contentType at the top of every jsp? It currently defaults to ISO-8559-1 if I do not explicitly set it. With 3.1.1, you can use character-encodingUTF-8/character- encoding to set the default charset encoding. Technically, this goes beyond the spec. JSP defaults to ISO-8859-1 according to the spec, so you do need a contentType for standard JSP. -- Scott Thank you, Hans Loeblich ___ 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 JCA RAR's containing native libraries
On Jun 28, 2007, at 1:39 AM, Ray Cromwell wrote: Hi all, I couldn't find any mention of this in the documentation, I'm using the latest Resin Pro 3.1 snap on both Linux and OSX with the same results. I have a WAR with an embedded RAR. The RAR contains a JCA component that includes a native library in its root ( libfoo.jnilib on mac, libfoo.so on Linux). The JCA code has been tested and works without the System.loadLibrary(), and the native code has been tested and loads successfully under Jetty using a non- JCA WAR that loads it directly (but requires manually placing the library in the java.library.path) I've filed this as http://bugs.caucho.com/view.php?id=1846 -- Scott I was hoping that by creating a JCA, native library deployment would work automatically without having to hack the LD_LIBRARY_PATH or java.library.path, since it seems that part of the reason for JCA's existence is to provide a mechanism for deploying native code in a container (apart from the inbound stuff, work api, etc) However, I have not been able to get Resin to load the RAR's library. It deploys properly, and non-native routines can be accessed and run from the web application, but anything which triggers the System.loadLIbrary () fails to find it. Does Resin support this functionality? If not, couldn't Resin, after unpacking the RARs automatically copy any native libs (.so/.dll/.jnilib) to the libexec directory or some other standard path that would be in the startup java.library.path? It seems some containers support this capability, and some require manual intervention. It would be nice to have an automated capability however, since I am planning on deploying my app to several machines across a cluster, and if I have to intervene, it means I have to remotely execute something which copies the libraries and/or reconfigures the library path, and I'd rather not have to roll-my-own hacks on each machine to deal with this. As a workaround, I could see deploying a servlet which when pinged would perform the required deployment step (copying the native libs), but that requires the servlet to have special knowledge of the unpacked directory location/name/layout, which seems hacking. Also, the documentation suggests that the connector/resource elements can only be in web-app, host, etc. I'm wondering if I can create a resin-ra.xml file which contains my jndi bindings, and if so, what's the root element and namespace for this file? Thanks, -Ray p.s. quercus rocks ___ 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] Tested/Supported Java-Versions
On Jul 4, 2007, at 6:23 AM, MORAWETZ Martin wrote: Hallo, Is Resin Pro 3.1.x tested with Java 1.6? Is there a list of supported/tested Java-Versions (maybe online)? Resin 3.1 works with 1.5 and 1.6. -- Scott Regards Martin Diese E-Mail sowie jeglicher Anhang sind vertraulich und ausschließlich für den/die bezeichneten Adressaten bestimmt. Diese Mitteilung kann rechtlich geschützte, firmeninterne oder anderweitig vertrauliche Informationen enthalten, deren Weitergabe ohne unsere Zustimmung strengstens untersagt ist. Sofern Sie nicht der beabsichtigte Adressat sind oder diese E-Mail irrtümlich erhalten haben, sind Sie nicht autorisiert, diese Mitteilung bekanntzumachen, zu kopieren, weiterzugeben oder aufzubewahren. Bitte informieren Sie uns in diesem Fall unverzüglich und vernichten diese E-Mail. Diese Fußnote dient auch der Bestätigung darüber, daß diese E-Mail automatisch auf Computerviren, anstößige Inhalte und Einwahlprogramme gescannt wurde. The information in this e-mail and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). This information may be subject to legal, professional or other privilege and further distribution of it is strictly prohibited without our authority. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it, and should notify us immediately. This footnote also confirms that this email has been automatically scanned for the presence of computer viruses, profanities and certain file types. ___ 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] Workaround for Resin bug 1788 - JSP precompiled and functions
On Jul 10, 2007, at 11:02 AM, Mike Wynholds wrote: The following bug exists in Resin 3.1.1 and is reported fixed in 3.1.2: http://bugs.caucho.com/view.php?id=1788 It appears that this bug essentially makes it impossible to use JSP EL functions (such as the JSTL functions) in JSP pages in Resin 3.1.1. The bugs says only precompiled JSPs are affected, but out of the box (config-wise), that includes all JSP tagfiles (*.tag) every time they are used, as far as I can tell. Is there any workaround for this? Only by setting jsp precompile='false'/. This makes Resin 3.1.1 almost unusable for me. It's a major bug. Also, Scott- do you have a release date planned for Resin 3.1.2? It's planned for this week. We're doing the final stress testing and compatibility QA now. There is a new snapshot today by the way. Unless we find something in the QA this week, it will essentially be the 3.1.2 release. -- Scott ..mike.. . Michael Wynholds President Carbon Five, Inc. 310 821 7125 x13 [EMAIL PROTECTED] ___ 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] 3.1.2 quick question pretty please?
On Jul 12, 2007, at 5:07 AM, John Steel wrote: Any chance of an updated list of which PHP apps work with Quercus as opposed to 3.1.1 ? For 3.1.2 Quercus, we focused on cleaning up the buglist. I don't believe we added any new PHP applications to the list. -- Scott -- John -- http://www.phonewebcam.com [EMAIL PROTECTED] ___ 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] config question
On Jul 13, 2007, at 3:43 AM, Jan Kriesten wrote:
hi,
just a short question to the resin.conf which comes with resin 3.1.1:
there is a
resin:if test=${resin.isProfessional()}
cluster id=web-tier
[...]
/cluster
/resin:if
at the end. should i have this by default or should i remove it?
resin-admin
tells me
You don't need it. It's the cluster for the web tier in a Resin load
balancing setup, i.e. replacing Apache/mod_caucho. If you only have
a single server, it's not used.
-- Scott
ServerAddress Status Active IdleConnection Miss LoadLatency
Fail
Total Busy Total
web-a 127.0.0.1:6700 fail0 0 0.00% (0 / 0) 0.000.00
8 0
so, actually this is not started - or do i have to add it to the
startup-script,
too?
just happened to get into my notion. :-)
regards, --- jan.
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Dangling Connections
On Jul 26, 2007, at 7:47 AM, Paul Davis wrote: Hey list, I'm trying to find information on how the error about closing all dangling connections gets generated. At the end of the top-level request, Resin rolls back the UserTransaction, and closes any connections that haven't been closed. This occurs after the top-level request listeners have been closed. I'm using a library that works by attaching a connection to each request and closes it automatically using a ServletRequestListener. As far as I can tell, this behavior is causing resin to spit out copious errors about not closing dangling connections. Are you absolutely sure the connections are closed in all cases? Is there a way to do something similar that won't trigger this error? Or a way to disable the behavior entirely? You really don't want to disable the behavior. It's an important error check. If the connections were actually left dangling, then they'd never get closed and the connection pool would lock up. -- Scott Thanks, Paul Davis ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] java.lang.IllegalStateException: Block 0 is reserved.
On Jul 25, 2007, at 4:57 PM, Ethan Larson wrote: Hi all, We just completed the upgrade to 3.1.2 from 3.1.1, which included a switch to clusterstore from jdbcstore as well. Things look good, except when we shut one of the nodes down, some of the other nodes in the cluster will sometimes throw this exception: Thanks, I've filed a bug at: http://bugs.caucho.com/view.php?id=1911 -- Scott [11:57:01.935] java.lang.IllegalStateException: Block 0 is reserved. [11:57:01.935] at com.caucho.db.store.BlockManager.stateError(BlockManager.java:329) [11:57:01.935] at com.caucho.db.store.BlockManager.getBlock(BlockManager.java:240) [11:57:01.935] at com.caucho.db.store.Store.readBlock(Store.java:466) [11:57:01.935] at com.caucho.db.store.Store.readMiniFragment(Store.java:1319) [11:57:01.935] at com.caucho.db.store.Inode.read(Inode.java:302) [11:57:01.935] at com.caucho.db.store.BlobInputStream.read(BlobInputStream.java:114) [11:57:01.935] at com.caucho.server.cluster.ClusterStore.dumpObjects (ClusterStore.java:1231) [11:57:01.935] at com.caucho.server.hmux.HmuxClusterRequest.dumpObjects (HmuxClusterRequest.java:391) [11:57:01.935] at com.caucho.server.hmux.HmuxClusterRequest.handleRequest (HmuxClusterRequest.java:178) [11:57:01.935] at com.caucho.server.hmux.HmuxRequest.scanHeaders(HmuxRequest.java:641) [11:57:01.935] at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:354) [11:57:01.935] at com.caucho.server.port.TcpConnection.run(TcpConnection.java:481) [11:57:01.935] at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:685) [11:57:01.935] at com.caucho.util.ThreadPool$Item.run (ThreadPool.java:607) [11:57:01.935] at java.lang.Thread.run(Thread.java:619) Is this something to worry about? Should I file a bug? I found a similar bug in mantis here: http://bugs.caucho.com/view.php?id=4 Thanks, Ethan Larson ___ 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] Removing Etags
On Aug 2, 2007, at 12:27 AM, rafael.munoz wrote: Hi all Is there any way to configure resin not to set the 'Etag' header? Not unless you write your own FileServlet. Why would you want to remove the ETag? -- Scott Thanks in advance, Rafa -- View this message in context: http://www.nabble.com/Removing-Etags- tf4204567.html#a11959693 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] Not able to set init parameter in a database
On Jul 31, 2007, at 12:50 AM, Daniel López wrote: Hi there, I was trying to migrate a Jira installation from Resin 3.0 to Resin 3.1 and I just found out I can no longer include init parameters in the database configuration, and that creates a problem as I need to specify the parameter SetBigStringTryClob to true. Is this with 3.1.2? The init-param should be allowed, although that was a bug in earlier versions of 3.1. -- Scott Before, I would use: - web-app database jndi-namejdbc/JiraDS/jndi-name driver typeoracle.jdbc.pool.OracleConnectionPoolDataSource/type url/url user.../user password./password init-param SetBigStringTryClob=true/ /driver /database /web-app - Now it tells me that I cannot use init-param and I have to use - SetBigStringTryClobtrue/SetBigStringTryClob - But then it complains that OracleConnectionPoolDataSource has no such property... I tried also using resource-ref with the same results so... do I better revert back to 3.0? Salute! D. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Removing Etags
On Aug 7, 2007, at 6:23 AM, rafael.munoz wrote: Sorry, I was talking about the whole problem with etags and a server farm, not only about activate/deactivate the etag header. For instance, I'm not sure if the etag value is calculated in Resin taking account the server or only the resource (url, file size, etc). In the later case two identical resources in two servers will have the same etag so there will be no problem at all. The ETag calculation has been changed (for 3.1.3) to a digest of the file contents, not timestamp-based. So each backend server will return the same etag. -- Scott Anyway i'm right now looking to the FileServlet implementation in Resin and i guess i'll have some of the answers i'm looking for reviewing the code :). Thanks for your answer, ssozonoff wrote: Hello Rafael, I thought the answer was pretty clear? Serge rafael.munoz wrote: Any new ideas about this? Nobody? Scott Ferguson wrote: On Aug 2, 2007, at 12:27 AM, rafael.munoz wrote: Hi all Is there any way to configure resin not to set the 'Etag' header? Not unless you write your own FileServlet. Why would you want to remove the ETag? -- Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest -- View this message in context: http://www.nabble.com/Removing-Etags- tf4204567.html#a12034138 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] Content-Length
On Aug 13, 2007, at 6:16 AM, Aaron Freeman wrote: I see from your link that Sun uses an int, but couldn't that be arbitrary? I don't believe Jakarta, and other implementations have this limit -- I just looked and they are using a long. This is a seriously limiting factor and may require us to swap out our underlying servers from Resin (which I really, really don't want to do). The HttpServletRequest.getContentLength() will still return int, but Resin will be able to use a long value internally (in 3.1.3). However, you could also use chunked-encoding for your uploads (assuming you have control over your client). That would avoid the 32- bit issue entirely. -- Scott Thanks, Aaron Freeman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Serge Knystautas Sent: Friday, August 10, 2007 10:16 AM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Content-Length Aaron Freeman wrote: Looking at com.caucho.server.connection.AbstractHttpRequest and com.caucho.server.http.HttpRequest I see that contentLength is being defined as an int, which limits file uploads to a size of 2,147,483,647. How painful would it be to convert this limit to a long so that we can have substantially larger files? That's a servlet API limitation, not something resin can do without breaking their support for the spec really: http://java.sun.com/products/servlet/2.5/docs/servlet-2_5-mr2/ index.html -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] ___ 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] Content-Length
On Aug 13, 2007, at 11:20 AM, Aaron Freeman wrote: I see from your link that Sun uses an int, but couldn't that be arbitrary? I don't believe Jakarta, and other implementations have this limit -- I just looked and they are using a long. This is a seriously limiting factor and may require us to swap out our underlying servers from Resin (which I really, really don't want to do). The HttpServletRequest.getContentLength() will still return int, but Resin will be able to use a long value internally (in 3.1.3). Ok so this problem will just go away with version 3.1.3 or it will require some special calls somewhere? It depends. If the application code is using HttpServletRequest.getContentLength(), then you will still have a problem. If it's just using getInputStream(), then it will just go away. -- Scott However, you could also use chunked-encoding for your uploads (assuming you have control over your client). That would avoid the 32- bit issue entirely. Let me check with the developer of the client and see what this entails. Thanks, Aaron Freeman ___ 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 gzip compression for javascript downloads from Linux server
On Aug 16, 2007, at 2:13 PM, Michael L. Davis wrote: Hi Everybody, Using Resin Pro 3.0.23, enabling gzip compression works on Windows XP, specifically the large (300K+) amount of javascript we use gets compressed to 25% or so. Very nice. But on Linux, only the HTML is compressed. This we verified using: http://www.websiteoptimization.com/services/analyze/index.html and Firefox's FireBug. Can you look at the headers that the client is sending to Resin? (level=finer will show those) It's possible that the gzip filter isn't properly handling the Accept- Encoding from the client. -- Scott The Linux version is: CentOS release 4.5 (Final) What we have in conf (and we've tried a number of variations) is: web-app id=/ document-directory=/var/www/resin/deploy filter filter-name=gzip filter-class=com.caucho.filters.GzipFilter/ filter-mapping filter-name=gzip url-pattern exclude-pattern*.pdf/exclude- pattern include-pattern/*/include-pattern /url-pattern /filter-mapping /web-app Any suggestions? Anybody? Thanks, Mike. ___ 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 gzip compression for javascript downloads from Linux server
On Aug 23, 2007, at 8:39 PM, Michael L. Davis wrote: Hi, So I touch'ed prototype-compressed.js (to get rid of the 403) and we get: [0] GET /startpage/scripts/prototype-compressed.js HTTP/1.1 [0] Remote-IP: 75.71.75.22:3697 [0] User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 [0] Accept: */* [0] Accept-Language: en-us,en;q=0.5 [0] Accept-Encoding: gzip,deflate [0] Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 [0] Keep-Alive: 300 [0] Connection: keep-alive [0] If-Modified-Since: Wed, 15 Aug 2007 21:22:02 GMT [0] If-None-Match: 831XFs4IZoh [0] Cache-Control: max-age=0 [0] HTTP/1.1 200 OK [0] ETag: 8UCDSWLScH5 [0] Last-Modified: Fri, 24 Aug 2007 01:28:45 GMT [0] Accept-Ranges: bytes [0] Cache-Control: max-age=5 [0] Expires: Fri, 24 Aug 2007 01:28:57 GMT [0] Content-Type: application/x-javascript [0] Content-Length: 52498 [0] write-chunk(16384) Thanks. I've filed a bug at http://bugs.caucho.com/view.php? id=1972.That looks like it should be compressable, but it's not getting compressed. -- Scott AutoCommitWriteBlock[Store[2],2] create db-block remove AutoCommitWriteBlock[Store[2],2] AutoCommitWriteBlock[Store[2],2] create db-block remove AutoCommitWriteBlock[Store[2],2] [0] write-chunk(16384) AutoCommitWriteBlock[Store[2],2] create db-block remove AutoCommitWriteBlock[Store[2],2] AutoCommitWriteBlock[Store[2],2] create db-block remove AutoCommitWriteBlock[Store[2],2] [0] write-chunk(16384) AutoCommitWriteBlock[Store[2],2] create db-block remove AutoCommitWriteBlock[Store[2],2] AutoCommitWriteBlock[Store[2],2] create db-block remove AutoCommitWriteBlock[Store[2],2] AutoCommitWriteBlock[Store[2],2] create db-block remove AutoCommitWriteBlock[Store[2],2] caching: /startpage/scripts/prototype-compressed.js etag=8UCDSWLScH5 length=52498 [0] keepalive [0] keepalive (select) The 'write-chunk(16284)' looks like it is trying to do something - but FireBug and that website that sends HEAD instead of GET both report 53K. If someone can convince me that FireBug is just plain wrong (tho it correctly reports on Windows XP) ... OK. Maybe FireBug et. al. ARE wrong. I opened a fresh FireFox window over dialup and it took 27 seconds (a page refresh then took 2 seconds) , 1/3 the time that the websiteoptimization.com site said it should and 1/2 the time a back-of-the-envelope calculation indicated. And given that the JS is most of the bytes going over the line, I now think that it IS being compressed but incorrectly reported on. So, uh, I will continue to investigate, but I am afraid I have bothered everybody needlessly. Thanks for your help! Mike. ___ 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] Start up problem
On Aug 28, 2007, at 11:01 AM, Leland, Robert wrote: It could be designed so that it becomes a single service, with only one instance of the process running no matter how many instances of resin are running. It does that now. -- Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin / Apache load balancing with customResin server weighting (for data segmentation purposes)
On Jul 25, 2007, at 9:30 AM, Mike Wynholds wrote: well, I did come up with a solution, however it is Resin-specific and requires some client-side code at all login points (ie: there is a customer login implemented in Flex as well as an administrative login implemented in HTML). I set up apache for the web-tier and resin as the app-tier, connected by mod_caucho. I have an idea of the overall systems architecture, but for this discussion we just assume that there is some farm of apache servers that are available under a single URL. Resin offers a way to specify a preferred app-tier server in the cluster by accessing the web-tier and passing in a pre-fab jsessionid, utilizing the Resin-specific algorithm of starting it with an a, b, c, etc. for example, if I wanted the second server listed in the cluster in resin.conf, I request the following: http://www.myserver.com;jsessionid=b I'm finally getting a chance to look at this. Does the project selection occur before you have a session? In other words, would something like the following work? request.setAttribute(caucho.session-server, b); session = request.getSession(true); If the session is new, then it will be assigned an ownership of server b, even if that's a totally different machine than the current server. The next request will be directed to server b, which will be the same as the pinned data. -- Scott now, if there is no current session, mod_caucho will do its best to point the web-tier to the second server in the app-tier cluster. it will still, however, fall back to the other clustered servers if B is down. this is exactly what I want. the downside to this solution is that my client code has to do some work to make this happen. as a user logs in, the client must a) clear the session, and b) figure out the appropriate URL (ie: jsessionid prefix) to use and switcheroo it in as the user logs in, based on the project number entered in to the login form. I actually have a server-side servlet that does the logic, so I just need a way to call it easily. basically, in Flex I just use the standard Flash mx:HTTPService, which is easy, and in HTML I just use AJAX. so it's not too bad, but it would be nice if it was even more behind the scenes. it can't be 100% behind the scenes, tho. I would at least need a convention of putting the project number in the session or in the login URL under a specific name, or something like that, even if I could do custom load balancing login on a hardware load-balancer. anyway, so far so good. any suggestions for improvements would be definitely appreciated! ..mike.. . Michael Wynholds President Carbon Five, Inc. 310 821 7125 x13 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:resin-interest- [EMAIL PROTECTED] On Behalf Of Jay Ballinger Sent: Wednesday, July 25, 2007 8:43 AM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Resin / Apache load balancing with customResin server weighting (for data segmentation purposes) Mike, This sounds like a perfect use for a hardware load-balancer. A hardware load-balancer can create the affinity for a particular server much like you describe - except for the choosing of a server based on your algorithm, that is. Most hardware solutions implement some sort of persistence feature where, once a load-balancing decision has been made by the device, it will try to persist that same 'user' to that same server for a configurable amount of time. We use this to keep a user's access and application log on one server versus having to hunt around all the servers to piece their session together. If you are trying to create logic that says, All project 'A' users go on server 'X', I see that as a big challenge for the chicken-egg scenario you describe - the user already has an affinity to a server before you know the user or the project. However, there are some pretty slick hardware load-balancers out there that can use cookie-driven values. Check out the lineup from F5 - specifically their Big-IP Local Traffic Managers. Of course, you could have a farm of login servers that simply takes the login info and then redirects the user to a different farm of servers based on the project info. Good luck, and let us know what you come up with. + jay On 7/11/07, Mike Wynholds [EMAIL PROTECTED] wrote: I have a somewhat complex load balancing scenario that I wish to accomplish. From my investigation it seems that it's *probably* possible but I haven't gotten it to work yet. Here is the scenario: I have a web app running on Resin 3.1.1 with Apache 2.2 in front of it. I want to have multiple Resin servers in a cluster. I may have multiple Apache servers as well, but I don't think that's important. If I do I will have a hardware load-balancer in
Re: [Resin-interest] Resin / Apache load balancing with customResinserver weighting (for data segmentation purposes)
On Aug 29, 2007, at 3:29 PM, Mike Wynholds wrote: i think that I could solve my issue more elegantly with the code you are suggesting. it would allow me to essentially keep it ALL on the server side, as long as I make sure my session's first hit is light, by which I mean not loading up my caches (which is the main reason I want to segment the data in the first place). the project selection can indeed happen before I have a session. does resin have this capability now, or are you proposing adding it? I'm adding it to 3.1.3. The attribute looks like: request.setAttribute(caucho.session-server-id, app-a); Or request.setAttribute(caucho.session-server-id, new Integer(0)); -- Scott ..mike.. -Original Message- From: [EMAIL PROTECTED] [mailto:resin-interest- [EMAIL PROTECTED] On Behalf Of Scott Ferguson Sent: Wednesday, August 29, 2007 12:07 PM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Resin / Apache load balancing with customResinserver weighting (for data segmentation purposes) On Jul 25, 2007, at 9:30 AM, Mike Wynholds wrote: well, I did come up with a solution, however it is Resin-specific and requires some client-side code at all login points (ie: there is a customer login implemented in Flex as well as an administrative login implemented in HTML). I set up apache for the web-tier and resin as the app-tier, connected by mod_caucho. I have an idea of the overall systems architecture, but for this discussion we just assume that there is some farm of apache servers that are available under a single URL. Resin offers a way to specify a preferred app-tier server in the cluster by accessing the web-tier and passing in a pre-fab jsessionid, utilizing the Resin-specific algorithm of starting it with an a, b, c, etc. for example, if I wanted the second server listed in the cluster in resin.conf, I request the following: http://www.myserver.com;jsessionid=b I'm finally getting a chance to look at this. Does the project selection occur before you have a session? In other words, would something like the following work? request.setAttribute(caucho.session-server, b); session = request.getSession(true); If the session is new, then it will be assigned an ownership of server b, even if that's a totally different machine than the current server. The next request will be directed to server b, which will be the same as the pinned data. -- Scott now, if there is no current session, mod_caucho will do its best to point the web-tier to the second server in the app-tier cluster. it will still, however, fall back to the other clustered servers if B is down. this is exactly what I want. the downside to this solution is that my client code has to do some work to make this happen. as a user logs in, the client must a) clear the session, and b) figure out the appropriate URL (ie: jsessionid prefix) to use and switcheroo it in as the user logs in, based on the project number entered in to the login form. I actually have a server-side servlet that does the logic, so I just need a way to call it easily. basically, in Flex I just use the standard Flash mx:HTTPService, which is easy, and in HTML I just use AJAX. so it's not too bad, but it would be nice if it was even more behind the scenes. it can't be 100% behind the scenes, tho. I would at least need a convention of putting the project number in the session or in the login URL under a specific name, or something like that, even if I could do custom load balancing login on a hardware load-balancer. anyway, so far so good. any suggestions for improvements would be definitely appreciated! ..mike.. . Michael Wynholds President Carbon Five, Inc. 310 821 7125 x13 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:resin-interest- [EMAIL PROTECTED] On Behalf Of Jay Ballinger Sent: Wednesday, July 25, 2007 8:43 AM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Resin / Apache load balancing with customResin server weighting (for data segmentation purposes) Mike, This sounds like a perfect use for a hardware load-balancer. A hardware load-balancer can create the affinity for a particular server much like you describe - except for the choosing of a server based on your algorithm, that is. Most hardware solutions implement some sort of persistence feature where, once a load-balancing decision has been made by the device, it will try to persist that same 'user' to that same server for a configurable amount of time. We use this to keep a user's access and application log on one server versus having to hunt around all the servers to piece their session together. If you are trying to create logic that says, All project 'A' users go on server 'X', I see that as a big challenge for the chicken-egg scenario you describe
Re: [Resin-interest] Resin / Apache load balancing withcustomResinserver weighting (for data segmentation purposes)
On Aug 29, 2007, at 4:35 PM, Mike Wynholds wrote: yeah, I think that will be cool. is there a timeline for 3.1.3 release? We're on week 5 of 8, so approximately the end of Sept. -- Scott ..mike.. -Original Message- From: [EMAIL PROTECTED] [mailto:resin-interest- [EMAIL PROTECTED] On Behalf Of Scott Ferguson Sent: Wednesday, August 29, 2007 4:32 PM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Resin / Apache load balancing withcustomResinserver weighting (for data segmentation purposes) On Aug 29, 2007, at 3:29 PM, Mike Wynholds wrote: i think that I could solve my issue more elegantly with the code you are suggesting. it would allow me to essentially keep it ALL on the server side, as long as I make sure my session's first hit is light, by which I mean not loading up my caches (which is the main reason I want to segment the data in the first place). the project selection can indeed happen before I have a session. does resin have this capability now, or are you proposing adding it? I'm adding it to 3.1.3. The attribute looks like: request.setAttribute(caucho.session-server-id, app-a); Or request.setAttribute(caucho.session-server-id, new Integer(0)); -- Scott ..mike.. -Original Message- From: [EMAIL PROTECTED] [mailto:resin-interest- [EMAIL PROTECTED] On Behalf Of Scott Ferguson Sent: Wednesday, August 29, 2007 12:07 PM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Resin / Apache load balancing with customResinserver weighting (for data segmentation purposes) On Jul 25, 2007, at 9:30 AM, Mike Wynholds wrote: well, I did come up with a solution, however it is Resin-specific and requires some client-side code at all login points (ie: there is a customer login implemented in Flex as well as an administrative login implemented in HTML). I set up apache for the web-tier and resin as the app-tier, connected by mod_caucho. I have an idea of the overall systems architecture, but for this discussion we just assume that there is some farm of apache servers that are available under a single URL. Resin offers a way to specify a preferred app-tier server in the cluster by accessing the web-tier and passing in a pre-fab jsessionid, utilizing the Resin-specific algorithm of starting it with an a, b, c, etc. for example, if I wanted the second server listed in the cluster in resin.conf, I request the following: http://www.myserver.com;jsessionid=b I'm finally getting a chance to look at this. Does the project selection occur before you have a session? In other words, would something like the following work? request.setAttribute(caucho.session-server, b); session = request.getSession(true); If the session is new, then it will be assigned an ownership of server b, even if that's a totally different machine than the current server. The next request will be directed to server b, which will be the same as the pinned data. -- Scott now, if there is no current session, mod_caucho will do its best to point the web-tier to the second server in the app-tier cluster. it will still, however, fall back to the other clustered servers if B is down. this is exactly what I want. the downside to this solution is that my client code has to do some work to make this happen. as a user logs in, the client must a) clear the session, and b) figure out the appropriate URL (ie: jsessionid prefix) to use and switcheroo it in as the user logs in, based on the project number entered in to the login form. I actually have a server-side servlet that does the logic, so I just need a way to call it easily. basically, in Flex I just use the standard Flash mx:HTTPService, which is easy, and in HTML I just use AJAX. so it's not too bad, but it would be nice if it was even more behind the scenes. it can't be 100% behind the scenes, tho. I would at least need a convention of putting the project number in the session or in the login URL under a specific name, or something like that, even if I could do custom load balancing login on a hardware load-balancer. anyway, so far so good. any suggestions for improvements would be definitely appreciated! ..mike.. . Michael Wynholds President Carbon Five, Inc. 310 821 7125 x13 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:resin-interest- [EMAIL PROTECTED] On Behalf Of Jay Ballinger Sent: Wednesday, July 25, 2007 8:43 AM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Resin / Apache load balancing with customResin server weighting (for data segmentation purposes) Mike, This sounds like a perfect use for a hardware load-balancer. A hardware load-balancer can create the affinity for a particular server much like you describe - except for the choosing of a server based on your algorithm
Re: [Resin-interest] Problem when restoring sessions with file-store
On Sep 3, 2007, at 1:46 AM, Daniel López wrote: Hi, I have some objects in a library that I'm using that are usually stored in the session. Up to now, everything worked fine but recently I decided to do some refactoring to update the version to Java 5 and I basically changed a member from being a Hashtable to being a Map (HashMap as implementation). Is it possible that the old persistent data is still based on the pre- refactoring information, e.g. if you had a very long session live time? -- Scott Since then, whenever the session needs to be recovered from file, like when the context is reloaded automatically, I get this error and the session is not recovered: ** java.lang.ClassCastException: cannot assign instance of java.lang.String to field org.leaf.security.ActiveUsersCache.userMap of type ava.util.Map in instance of org.leaf.security.ActiveUsersCache at java.io.ObjectStreamClass$FieldReflector.setObjFieldValues (ObjectStre amClass.java:2032) at java.io.ObjectStreamClass.setObjFieldValues (ObjectStreamClass.java:12 12) at java.io.ObjectInputStream.defaultReadFields (ObjectInputStream.java:19 51) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: 1869) at java.io.ObjectInputStream.readOrdinaryObject (ObjectInputStream.java:1 753) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.defaultReadFields (ObjectInputStream.java:19 45) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: 1869) at java.io.ObjectInputStream.readOrdinaryObject (ObjectInputStream.java:1 753) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) at com.caucho.server.session.SessionImpl.load(SessionImpl.java:962) at com.caucho.server.session.SessionManager.load (SessionManager.java:150 7) at com.caucho.server.cluster.ClusterObject.load(ClusterObject.java: 301) at com.caucho.server.cluster.FileBacking.loadSelf(FileBacking.java: 299) at com.caucho.server.cluster.FileStore.load(FileStore.java:143) at com.caucho.server.cluster.ClusterObject.load(ClusterObject.java: 268) at com.caucho.server.session.SessionImpl.load(SessionImpl.java:741) at com.caucho.server.session.SessionManager.load (SessionManager.java:144 4) at com.caucho.server.session.SessionManager.getSession (SessionManager.ja va:1303) at com.caucho.server.connection.AbstractHttpRequest.createSession (Abstra ctHttpRequest.java:1455) at com.caucho.server.connection.AbstractHttpRequest.getSession (AbstractH ttpRequest.java:1270) at _jsp._index__jsp._jspService(_index__jsp.java:20) ... ** So it seems it is trying to set the field I declared as a Map to a String. I've done some tests and serialised/deserialised instances of this class without problem; I've also checked all the places where this field is used and I have'nt seen anything weird. It could be my fault, as it is suspicious that it's just happening after my changes, but how can I debug the session storage mechanism of Resin to see where the things are going wrong? Any easy way I can check a stored session if the data in there is correct? Any idea? D. PD: Java 1.6.0_02-b05, 32, mixed mode, Cp1252, es, Sun Microsystems Inc. Resin 3.1.1 Windows XP. --- Daniel Lopez Janariz ([EMAIL PROTECTED]) Web Services Centre for Information and Technology Balearic Islands University (SPAIN) --- ___ 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 when restoring sessions with file-store
On Sep 4, 2007, at 10:27 AM, Daniel Lopez wrote: Hi, First thing I did was to clean up all the deployment directory, making sure the WEB-INF/sessions directory was removed, and session lifetime is 30min, so they shouldn't have survived all the weekend in any case :). I tried with Resin 3.1.2, just in case, and the result was the same. I downloaded Resin source and built the resin.jar from scratch adding some debugging info and I ended up at the readObject() call. So it seems for some weird reason that de-serialising that object inside a Session fails. However, I tested the serialise/de-serialise process using the same JVM on the class giving the errors and I had no problem doing it. Weird. Can you try changing the serialization-type to hessian: session-config serialization-type=hessian/ I'm not sure that it will change anything, but it might give a different error message that might help. Is the srun.db file in some kind of format one can easily grasp? Not really. It's a virtual filesystem/database-row structure. There are inodes and fragments, and indirect blocks and all sorts of nasty things. (It does support a JDBC API, though. So if the hessian change doesn't give enough information you could copy it to another directory, and launch a jdbc driver com.caucho.db.jdbc.ConnectionPoolDataSourceImpl with pathfoo/ path. I wouldn't recommend it, but it's possible.) -- Scott I might try to deserialise an instance of such a file to see what's going on. At least I should be able to determine if the problem happens when writing or when reading the object. Thanks! D. S'està citant Scott Ferguson [EMAIL PROTECTED]: On Sep 3, 2007, at 1:46 AM, Daniel López wrote: Hi, I have some objects in a library that I'm using that are usually stored in the session. Up to now, everything worked fine but recently I decided to do some refactoring to update the version to Java 5 and I basically changed a member from being a Hashtable to being a Map (HashMap as implementation). Is it possible that the old persistent data is still based on the pre- refactoring information, e.g. if you had a very long session live time? -- Scott S'està citant Jay Ballinger [EMAIL PROTECTED]: Are you trying to use session objects that are from the past? If these objects were serialized before your change, they will probably be incompatible with your new change. You'll need to clean house of the serialized artifacts first. + jay ___ 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] rewriting...
On Sep 6, 2007, at 12:27 AM, Jan Kriesten wrote:
hi,
i'm coming from apache and want to change to resin completely since
there is no
need for this intermediate any more.
the only thing i haven't figured out yet is how to use resin's
rewrite-dispatch. we use apache's rewrite-rules to use user
friendly url's. we
have this e.g.:
RewriteEngine on
RewriteCond /usr/local/www/services/apache/html%
{REQUEST_FILENAME} !-f
RewriteCond %{QUERY_STRING} .*
RewriteCond %{REQUEST_FILENAME} !.gif$
RewriteCond %{REQUEST_FILENAME} !.jpg$
RewriteCond %{REQUEST_FILENAME} !.js$
RewriteCond %{REQUEST_FILENAME} !.css$
RewriteRule ^(.+)$ $0#%0 [C]
RewriteRule ^([^#]+)#(.*)$ /index.jsp?pathinfo=$1$2
[PT,L]
is there a way to accomplish this with resin's rewrite-dispatch?
Can you translate that into english? :-)
I can't quite see what's it's supposed to do.
-- Scott
best regards, --- jan.
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Loadbalanceservlet
On Sep 7, 2007, at 4:38 AM, Dennie.nl wrote: Hi, I have a question about loadbalacing resin with a jvm per instance (using resin as front-end server). This can be implemented with a LoadBalanceServlet according to the documentation. Resin (and I) can't seem to find it in any jar files included with the bin distribution of Resin. Does anybody know how to obtain this servlet? It's in Resin Pro. Also, 3.1.x has significant enhancements to the load balancing and failover. -- Scott Using resin 3.0.24 open source. Greetings Dencel ___ 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] rewriting...
On Sep 7, 2007, at 12:24 AM, Jan Kriesten wrote: why using an example url when not using it... ;-) suppose the user calls a url like http://www.myservice.com/en/about/company/?page-id=2 the effective request after applying the rules would be /index.jsp?pathinfo=/en/about/company/page-id=2 That's odd. It looks like we're not handling the query string portion. I've just added a bug report at http://bugs.caucho.com/ view.php?id=1997 -- Scott regards, --- jan. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin and transactions (disable autocommit)
On Sep 10, 2007, at 8:43 AM, Sam wrote: Date: Tue, Aug 28, 2007 at 12:52:23PM -0500 Subject: Re: [Resin-interest] Resin and transactions (disable autocommit) ... Long story short I'm trying to run Jasper report server on Resin instead of Tomcat. It seems to work OK except for when it comes to large objects at which point the PostgreSQL driver throws an exception that all LO operations must be performed inside a transaction... Tomcat has an option to turn off auto-commits at the resource definition. Does Resin have anything along these lines? Added a bug report: http://bugs.caucho.com/view.php?id=2001 Except that doesn't really make any sense. disabling auto-commit really means starting a transaction. But if your code isn't really handling the transactions itself, then it will be missing the commit()/rollback(). -- Scott -- 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] MyFaces 1.2.0 and Facelets 1.1.13 on Resin 3.1.2
On Sep 14, 2007, at 9:49 AM, Matt Raible wrote: Yeah, the faces-config.xml files I found had both a DTD and the xmlns. I don't know if it's in the spec, but the other containers seem to ignore this. Validation isn't required by the spec, so that's probably what's happening. I'll either redo the schema to handle this or add a skip- validation tag somewhere. BTW, this issue is Resin-JSF vs Myspaces/JSF-RI, not Resin vs Tomcat/ Jetty. If you delete the jsf-12.jar, you'll bypass Resin-JSF's parsing of the faces-config files. Right, but there's still an error that appears with Facelets. [18:48:36.974] Error Rendering View[/users.xhtml] [18:48:36.974] java.lang.NullPointerException [18:48:36.974] at com.sun.facelets.el.CompositeFunctionMapper.resolveFunction (CompositeFunctionMapper.java:48) Thanks. I've filed it as a bug. There should be a snapshot with a fix sometime next week. -- Scott [18:48:36.974] at com.caucho.el.ELParser.getStaticMethod (ELParser.java:680) [18:48:36.974] at com.caucho.el.ELParser.parseSimpleTerm (ELParser.java:642) [18:48:36.974] at com.caucho.el.ELParser.parseTerm(ELParser.java:427) [18:48:36.974] at com.caucho.el.ELParser.parseExpr(ELParser.java:211) [18:48:36.974] at com.caucho.el.ELParser.parseInterpolate (ELParser.java:174) [18:48:36.974] at com.caucho.el.ELParser.parse(ELParser.java:105) [18:48:36.974] at com.caucho.jsp.el.JspExpressionFactoryImpl.createValueExpression (JspExpressionFactoryImpl.java:120) [18:48:36.974] at com.sun.facelets.el.ELText$ELTextVariable.apply(ELText.java:161) [18:48:36.974] at com.sun.facelets.compiler.TextInstruction.apply (TextInstruction.java:56) [18:48:36.974] at com.sun.facelets.compiler.UIInstructionHandler.apply (UIInstructionHandler.java:85) [18:48:36.974] at com.sun.facelets.tag.CompositeFaceletHandler.apply (CompositeFaceletHandler.java:47) [18:48:36.974] at com.sun.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:109) [18:48:36.974] at com.sun.facelets.tag.CompositeFaceletHandler.apply (CompositeFaceletHandler.java:47) [18:48:36.974] at com.sun.facelets.compiler.NamespaceHandler.apply (NamespaceHandler.java:49) [18:48:36.974] at com.sun.facelets.compiler.EncodingHandler.apply (EncodingHandler.java:25) [18:48:36.974] at com.sun.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:95) [18:48:36.974] at com.sun.facelets.FaceletViewHandler.buildView (FaceletViewHandler.java:509) [18:48:36.974] at com.sun.facelets.FaceletViewHandler.renderView (FaceletViewHandler.java:552) [18:48:36.974] at org.ajax4jsf.framework.ViewHandlerWrapper.renderView (ViewHandlerWrapper.java:101) [18:48:36.974] at org.ajax4jsf.framework.ajax.AjaxViewHandler.renderView (AjaxViewHandler.java:221) [18:48:36.974] at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute (RenderResponseExecutor.java:41) [18:48:36.974] at org.apache.myfaces.lifecycle.LifecycleImpl.render (LifecycleImpl.java:132) [18:48:36.974] at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138) This also happens on Resin 3.1.2, which has no jsf-12.jar in its lib directory. Matt -- Scott Thanks, Matt On 9/14/07, Scott Ferguson [EMAIL PROTECTED] wrote: On Sep 13, 2007, at 4:33 PM, Matt Raible wrote: I'm trying to use MyFaces 1.2.0 and Facelets 1.1.13 on Resin 3.1.2. Everything starts OK, but it seems there's an issue with Facelets. Any ideas? Can you check with the current snapshot? (Or actually wait until tomorrow's snapshot since there's a bug in the sample resin.conf) There are a number of important fixes to the EL handling because of JSF issues. The snapshot does include Resin's new JSF implementation (so it might be necessary to remove the resin/lib/jsf-12.jar if that introduces any problems.) -- Scott [01:29:15.913] Error Rendering View[/users.xhtml] [01:29:15.913] java.lang.NullPointerException [01:29:15.913] at com.sun.facelets.el.CompositeFunctionMapper.resolveFunction (CompositeFunctionMapper.java:48) [01:29:15.913] at com.caucho.el.ELParser.getStaticMethod (ELParser.java:680) [01:29:15.913] at com.caucho.el.ELParser.parseSimpleTerm (ELParser.java:642) [01:29:15.913] at com.caucho.el.ELParser.parseTerm(ELParser.java: 427) [01:29:15.913] at com.caucho.el.ELParser.parseExpr(ELParser.java: 211) [01:29:15.913] at com.caucho.el.ELParser.parseInterpolate (ELParser.java:174) [01:29:15.913] at com.caucho.el.ELParser.parse(ELParser.java:105) [01:29:15.913] at com.caucho.jsp.el.JspExpressionFactoryImpl.createValueExpression (JspExpressionFactoryImpl.java:120) [01:29:15.913] at com.sun.facelets.el.ELText$ELTextVariable.apply(ELText.java:161) [01:29:15.913] at com.sun.facelets.compiler.TextInstruction.apply (TextInstruction.java:56) [01:29:15.913] at com.sun.facelets.compiler.UIInstructionHandler.apply (UIInstructionHandler.java:85) [01:29:15.913
[Resin-interest] Resin Comet
The 3.1.3 snapshot includes a new implementation of Comet for Resin servlets. There's a sketch of an example at http://caucho.com/resin-3.1/examples/servlet-comet/index.xtp Javadocs are at http://caucho.com/resin-javadoc/com/caucho/servlets/comet/package- summary.html The basic model is similar to the normal servlet, except there's a new service() and a resume() call in the AbstractCometServlet. The CometController is the main object that's passed from the servlet to your application comet code. Its main methods are wake(), close (), and setAttribute()/getAttribute(). The CometController is thread-safe. As always, the ServletRequest and ServletResponse and the PrintWriter/ServletOutputStream are *not* thread-safe. You must not store the request/response or output in object or pass them to other threads. The only way other threads in your application can talk to the Comet request is through the CometController. Data is passed through get/setAttribute (which sets request.setAttribute in a thread-safe manner) and the servlet is resumed with wake(). We'll cleanup the example in a bit to make a bit more sense. The 3.1.3 release has been delayed another week (due primarily to Quercus issues), so we're now aiming for the week of October 5. -- Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] server B in cluster validates against server A properties in resin.conf (3.1.2)
On Sep 20, 2007, at 3:34 PM, Mike Wynholds wrote: I have the following config in my resin.conf: I know it’s weird to have one server with ssl enable and one without, but it was really just a development thing. anyway, the resin.conf files are identical among app-a and app-b. but.. when I start up app-b, it errors out because it cannot find the .keystore file, even though that is specific to app-a. this is basically a bug report, and I should probably figure out how to put it directly in to the bug tracker, but laziness takes over once again… I've added it as http://bugs.caucho.com/view.php?id=2020. It looks fairly straightforward. -- Scott ..mike.. ___ 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] PingThread killing Resin?
On Sep 21, 2007, at 1:51 PM, chris monster wrote: our Resin-Pro 3.0.22 deploy is experiencing 'silent' JVM exits. with a bit of code tweaking on our side, we managed to capture the following stack trace: at java.lang.Runtime.halt(Runtime.java:252) at com.caucho.server.admin.PingThread.run(PingThread.java: 361) at java.lang.Thread.run(Thread.java:595) we have not enabled ping in resin.conf. The PingThread should only be created if there's a ping element (or resource with ping). I just skimmed the code and can't see where it would be allocated with no ping. should PingThread be doing this? or might this be a bug? The PingThread thinks Resin is frozen, i.e. either that the ping has failed to get the data or just locked up, e.g. if the JVM has locked. In other words, it thinks the jvm is in a very bad state, which is why it's exiting with no message (because the lockup might be message related, too). The main puzzle, though, it why there's a PingThread. Can you double check the resin.conf and any included files? -- Scott Register today for the Algorithmics Risk Conference 2007, September 24 - 26, Cannes, France. This email and any files transmitted with it are confidential and proprietary to Algorithmics Incorporated and its affiliates (Algorithmics). If received in error, use is prohibited. Please destroy, and notify sender. Sender does not waive confidentiality or privilege. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. Algorithmics does not accept liability for any errors or omissions. Any commitment intended to bind Algorithmics must be reduced to writing and signed by an authorized signatory. ___ 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
