Re: [Resin-interest] Resin Wildcard SSL Certs?
We use wildcard certs with 3.0.18Pro and 3.1.6Pro (JSSE and 32bit) without problems. If only we could correctly limit the cipher suites. http://bugs.caucho.com/view.php?id=3431 (which is a reopen of) http://bugs.caucho.com/view.php?id=2360 Scott or Emil, either of you had a chance to review my suggested changes, yet? + jay Rob Lockstone wrote: Does anyone know if Resin (Pro 3.1.9 64-bit with OpenSSL) would have any problems handling a wildcard ssl certificate, as opposed to a domain specific cert, e.g. *.blahblah.com vs. poolOne.blahblah.com, poolTwo.blahblah.com, poolThree.blahblah.com. We're considering getting one because a few of our pools require ssl and it's easier to manage, though more expensive, to get just one certificate for all of them rather than deal with multiple different certs for the different pools (i.e. remembering to renew them and make sure they're deployed, etc). We know it works with IIS, but have never tried a wildcard cert with Resin and OpenSSL. I wouldn't anticipate there being a problem, but obviously we'd rather not spend the money only to find out it won't work for some reason. Anyone know? 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] CipherSuites for Jsse in resin 3.1.6
Thanks for adding the notes to issue 3431. I was hoping that Scott and Emil could chime in where I think the changes need to happen. We're wanting to implement 3.1.6 (up to 3.1.9) in our production environments, and this change is key to that development. If this is a logical place to start, we may implement 3.1.6x until 3.1.10 is available. ;) Have you guys had a chance to take a quick look, yet? + jay Scott Ferguson wrote: On May 1, 2009, at 4:33 PM, Jay Ballinger wrote: Howdy, Please refer to: http://bugs.caucho.com/view.php?id=3431 (which is a reopen of) http://bugs.caucho.com/view.php?id=2360 I've added this information as a note to 3431. Now that we've released 4.0.0, we can start clearing out the old, stalled bug reports. -- Scott We're using Resin Pro 3.1.6 and trying to limit the cipher suites for JSSE. I couldn't find the documentation, but through trial and error was able to discover that http stanza allows this syntax for setting ciphers... host port=443 host=some.host jsse-ssl cipher-suitesSSL_RSA_WITH_RC4_128_MD5,[more]/cipher-suites key-store-type... key-store-file... password... /jsse-ssl /host But running THCSSLCheck didn't show any change to the ciphers. I dove down in to com.caucho.vfs.JsseSSLFactory and had to make the following changes... 1) in the public QServerSocket create(InetAddress host, int port) method, there is a check for _cipherSuites != null. That if stmt includes the following line: sslContext.createSSLEngine().setEnabledCipherSuites(_cipherSuites); While this appears to do what I need, it doesn't appear to really affect anything. I'm not sure where the new SSLEngine is used. The SSLServerSocketFactory is established in the same if block, but nothing new is set there. 2) there is some commented code below that method that looks like it was setting protocols - pretty close to ciphers. I added the following just before the return stmt: sslServerSocket.setEnabledCipherSuites( _cipherSuites ); And now I see a difference with THCSSLCheck. Scott, I haven't looked any further than JsseSSLFactory and Port, so I don't know if this was supposed to be handled somewhere else. And I'm not sure if this is still an issue with 3.1.9, or the 3.2/4 code. I think we're in the minority running JSSE, but it works well enough for us. We upgraded to 3.1.6 because this was reported as fixed on this version, but obviously this isn't. Maybe there might be confusion with the https.cipherSuites system property/java-args usage versus the socket cipher suites - which would be my bad for not asking for the right thing. If I understand the https.cipherSuites properly (now), that is when you run as a client versus the server. To set server ciphers you need to interact with the API directly - like the SSLServerSocketFactory does. This may be why 3431 was opened. Is this a reasonable fix if we were to run 3.1.6mine? Has this been fixed in newer revisions? Are there others running JSSE with an interest in limiting the cipher suites and possibly the protocols? + 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] CipherSuites for Jsse in resin 3.1.6
Howdy, Please refer to: http://bugs.caucho.com/view.php?id=3431 (which is a reopen of) http://bugs.caucho.com/view.php?id=2360 We're using Resin Pro 3.1.6 and trying to limit the cipher suites for JSSE. I couldn't find the documentation, but through trial and error was able to discover that http stanza allows this syntax for setting ciphers... host port=443 host=some.host jsse-ssl cipher-suitesSSL_RSA_WITH_RC4_128_MD5,[more]/cipher-suites key-store-type... key-store-file... password... /jsse-ssl /host But running THCSSLCheck didn't show any change to the ciphers. I dove down in to com.caucho.vfs.JsseSSLFactory and had to make the following changes... 1) in the public QServerSocket create(InetAddress host, int port) method, there is a check for _cipherSuites != null. That if stmt includes the following line: sslContext.createSSLEngine().setEnabledCipherSuites(_cipherSuites); While this appears to do what I need, it doesn't appear to really affect anything. I'm not sure where the new SSLEngine is used. The SSLServerSocketFactory is established in the same if block, but nothing new is set there. 2) there is some commented code below that method that looks like it was setting protocols - pretty close to ciphers. I added the following just before the return stmt: sslServerSocket.setEnabledCipherSuites( _cipherSuites ); And now I see a difference with THCSSLCheck. Scott, I haven't looked any further than JsseSSLFactory and Port, so I don't know if this was supposed to be handled somewhere else. And I'm not sure if this is still an issue with 3.1.9, or the 3.2/4 code. I think we're in the minority running JSSE, but it works well enough for us. We upgraded to 3.1.6 because this was reported as fixed on this version, but obviously this isn't. Maybe there might be confusion with the https.cipherSuites system property/java-args usage versus the socket cipher suites - which would be my bad for not asking for the right thing. If I understand the https.cipherSuites properly (now), that is when you run as a client versus the server. To set server ciphers you need to interact with the API directly - like the SSLServerSocketFactory does. This may be why 3431 was opened. Is this a reasonable fix if we were to run 3.1.6mine? Has this been fixed in newer revisions? Are there others running JSSE with an interest in limiting the cipher suites and possibly the protocols? + jay ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] implicit stack memory size?
Thanks much, guys, for the replies. We've arrived at the same conclusion that Scott suggests - a GB for the heap and the other GB for the product (roughly) of the threads and the stack size in our windows 32-bit environment. Now it's an exercise in testing the actual -Xss size that we want to run with - which is proving to be a bit elusive. Understanding that local primitives and heap-object addresses are stored on the stack, I can't envision a need for a stack size anywhere bigger than 1MB (for our app, YMMV). Even 1MB is probably way over doing it. There's a few of us here at work who have been lurkers on this list for a long time - or at least a couple of years anyway. We've always found this list valuable and appreciate everyone's involvement. Thanks again. + jay Scott Ferguson wrote: On Jan 8, 2009, at 5:23 PM, Rob Lockstone wrote: On Jan 8, 2009, at 13:52, Jay Ballinger wrote: Hi everyone, We're running Resin 3.0.18 Pro on a Windows 32-bit system and we're looking to understand/tune our memory settings a bit. According to http://www.caucho.com/resin-3.0/performance/jvm-tuning.xtp the stack size is set to 2048k unless set otherwise. Is this true? In using JConsole we can't see where any explicit -Xss setting is passed and we can't readily determine what the current stack size is set to. Try -verbose when starting. Since the -Xss is a command line option, it should be reported. Also, JConsole should be able to see the command line options on one of the system beans. I think Caucho tends to err on the side of caution in this regard, and is also (understandably) more *nix-central than Windows. So take that 2048K as being appropriate for most situations with a grain of salt because situations can vary wildly. Basically. There's no way for us to know if your application needs more stack or more threads. So I assumed 1G heap, leaving 1G for other stuff, and then figured the default should support 1000 threads, giving 1m as a default, which should be enough stack unless you have massively recursive applications, and enough threads for most apps. You know your own requirements best, of course. I believe Linux is the most finicky about the stack allocation, so it was the OS we needed to solve (and it was the OS which exposed the issue first.) I'm really looking forward for the 64-bit transition to complete so we can use as much VM as possible. -- Scott So, here's a short list of questions. And thanks for your help. - If JConsole doesn't show -Xss, is it really there for resin? Whether it's explicitly set or not, there IS a stack size, which would end up being the default stack size of the operating system if the JVM itself doesn't set it (I do not think it does, but could be wrong and don't feel like looking it up now). - How was 2048k is an appropriate value for most situations. determined? See above. - Can resin/jvm/jconsole report the current stack memory setting? I don't know if there's a way to query a running JVM for this information. It's best if you explicitly set the stack size using the JVM option -Xss (but see below). (general sun jvm on windows questions) - What is the default stack memory size? That's too general of a question. It depends on the OS, and (perhaps) the version of the OS. - When a thread is created, does it grab all of the stack memory, or can the stack memory start small and grow to the default or -Xss size? Again, might depend on the operating system. Contrary to what Knut said, and to the best of my knowledge and in the testing that I did (it's been a while), all of the memory for the stack is pre-allocated (at least from the perspective of the JVM itself). But it's easy enough to write a program to check this. Thread stacks, at least on Windows, are more complicated than just a single memory allocation (down at the Windows API level) because you've got both reserved and committed memory allocations, and one always has to be = the other (I forget which), and there's a 64K granularity in sizing, and you're dealing with physical and virtual memory, and this is all set in the linker and therefore configurable, but can also be set programmatically on a per-thread basis. In other words, it's quite involved. See this page as an example of how complex this kind of memory management is when you go into how the underlying OS is actually managing all of this http://msdn.microsoft.com/en-us/library/ms686774(VS.85).aspx . Remember, thread allocation/destruction as well as context switching and just about everything else is managed by the operating system, not Java (unless you're running green threads, which I don't think is even around anymore?). This is why the memory used by the thread's stack is not part of the Java heap. On a 32-bit machine, the maximum addressable space for an individual java program is 2G. So, for example, if you run java
[Resin-interest] implicit stack memory size?
Hi everyone, We're running Resin 3.0.18 Pro on a Windows 32-bit system and we're looking to understand/tune our memory settings a bit. According to http://www.caucho.com/resin-3.0/performance/jvm-tuning.xtp the stack size is set to 2048k unless set otherwise. Is this true? In using JConsole we can't see where any explicit -Xss setting is passed and we can't readily determine what the current stack size is set to. So, here's a short list of questions. And thanks for your help. - If JConsole doesn't show -Xss, is it really there for resin? - How was 2048k is an appropriate value for most situations. determined? - Can resin/jvm/jconsole report the current stack memory setting? (general sun jvm on windows questions) - What is the default stack memory size? - When a thread is created, does it grab all of the stack memory, or can the stack memory start small and grow to the default or -Xss size? Thanks, everyone. + jay ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] implicit stack memory size?
Knut, Thanks for the info. Just a check on the math - if Win32 has a 2GB max addressable space, that includes heap and stack and misc. overhead, right? If we set resin heap to 1GB and allow each thread to use the 'default' of 2048k, and we see the number of threads running at about 700, then we have the potential of 2.4GB total memory usage [ 1024MB + (700*2MB) ]. This exceeds the 2GB limit. However, if, as you suggest, each thread only uses a fraction of the 2MB available to each thread, we could see the total memory somewhere between 1GB and 2GB. So, my question is if we use -Xss1024k, each thread is really using between 0 and 1024k depending on what that thread really needs? + jay Knut Forkalsrud wrote: On Thu, Jan 8, 2009 at 1:52 PM, Jay Ballinger jay.ballin...@gmail.com wrote: - When a thread is created, does it grab all of the stack memory, or can the stack memory start small and grow to the default or -Xss size? If I'm not mistaken the memory is allocated, but it is virtual memory, so unless it is actually used there is no penalty. The only problem with allocating too much stack space is that you can run out of address space on a 32 bit JVM. With typically 2GB max addressable for the app and 10 MBytes per stack you are limited to 200 threads. -Knut ___ resin-interest mailing list resin-interest@caucho.com 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] HTTPS load balancing - need help/suggestions
Mitch, We're using a hardware load balancer in front of our Resin servers. To try and find a way to uniquely identify each browser in an SSL and NAT world, we're utilizing the session ID on the SSL handshake. Since NAT routers will consolidate IP addys, and cookies may be hidden behind the SSL encryption, the SSL Session ID is in the clear and appears in the headers before the SSL encrypted package. Now, I'm not sure of Resin has an easy way to get at this value, but it can serve to identify unique SSL visitors. + jay Mitch Wallace wrote: Our current environment has multiple physical servers behind a load balancer. Each server is running resin 3.1.1 where a java servlet handles requests. We have tested two different load balancer configurations with session stickiness, but encountered the following results: Config 1 - IP hash, session stickiness This ends up routing a huge portion of the traffic to a single server due to NAT'ed IP addresses. Not going to work long term as we will eventually hit server capacity. Configuration 2 - Round Robin, session stickiness Initially, this appeared to work. However, after some more detailed testing, we found that certain parts of the session were floating across servers. More detailed investigation showed that even though requests were being sent from the same browser window, they were actually viewed as separate sessions on the server side. As an example, an initial page may be loaded that includes javascript that posts additional requests to the server to return detail records or to call a search function. These requests include a close connection. Since our application caches user/profile info in memory (no user data is stored on the server), we require server affinity by user session. Once a user logs in, we would like all requests to go to a single server in the pool until that person logs out or the session times out. Upon next login, it should load balance to whatever server is next in the load balanced pool. One option considered is to use an SSL load balancer with SSL acceleration that we can configure in cookie insert mode. However, my concern is that because the additional posts include a close connection, we may end up with the same problem encountered in Configuration 2 above. Questions - - Can anyone suggest a way to configure resin to handle this type of load balancing? Remember, the key is to load balance by user session. - Does anyone have a similar configuration and if so, how did you solve the problem? - This may be a stupid question, but more for short term testing, is it possible to configure a web tier and app tier using the same servers? For example, server A, server B, and server C. A and B are clustered as a web tier, balancing traffic to A,B, and C as the app tier. Any suggestions are welcome and thanks in advance for any help. Mitch ___ resin-interest mailing list resin-interest@caucho.com 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
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 On 9/3/07, Daniel López [EMAIL PROTECTED] 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). 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] Resin / Apache load balancing with custom Resin 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 front of that. I want to achieve both failover and server scalability with my systems architecture. I think I can utilize a clustering solution to handle this. I will need to cluster both Resin sessions as well as a number of memory/disk caches using the distributed mode of EhCache (or possible JBossCache). So far the Resin session clustering is working fine. However, for efficiency I really also want to segment my data between users, in order to reduce either a) the amount of cache replication (if I use cache replication) or b) the amount of cache misses (if I use cache invalidation) in EhCache. When people come to the site, they are given a login page immediately. There are two entry points: one is HTML-based and one is Flash/Flex-based. Either way the user is prompted to log in with a username, password and a project number. I want to pin all users logged in to a particular project to the same backend server so that the EhCache can be used as efficiently as possible. But while I say I want to pin specific users to specific backend servers, I really also want the failover capability built in to load-balancers. So what I *really* want is a way to suggest to the load balancer which server to prefer, but allow it to fall back in the case of a server being down. My algorithm for choosing a server to suggest is simple: I just hash the project number, mod by the amount of servers, and choose that one. Not smart, but for now that's fine. I feel like I will want to use the Resin load balancing features (although I am open to other suggestions). From the docs it seems like there may be a way to do it. I have spent a few hours on this and am not seeing a very clear solution. My main theoretical issue is that when the user hits the login page a session is created. There is no way to know which project number the user will then enter, and therefore which server to try to pin him too. But then if he enters a project number, Resin already has him pinned to a server by the jssesionid. Is there a way to tell Resin to keep the session but now house it on a different server? I think the logic of project number à server needs to be in the app somewhere (ideally the server side, not the Flash side). Can I set a cookie or something that can be sniffed by Resin's load balancing capabilities that will determine the suggested server to pin to? I can kind of see the light at the end of the tunnel but haven't been able to come up with even a best theoretical approach to this problem. There is just too much about Resin load balancing, mod_caucho, hardware load balancers and the such that I am not intimately familiar with, and I don't want to reinvent anything that already exists and works well. Thanks for any suggestions. ..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
Re: [Resin-interest] Wild card SSL Certs
We use JSSE successfully and haven't really noticed any performance problems or slowdowns. http address=* port=443 jsse-ssl key-store-typepkcs12/key-store-type key-store-file/some/path/to/file.p12/key-store-file passwordsecret/password /jsse-ssl /http We used OpenSSL to bundle the wildcard cert, the intermediate certs, and the root cert into one .p12 file - including the password. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] SSL, mod_caucho for Apache 2.2
We're using SSL (via JSSE) on Resin 3.1 just fine. + jay On 4/5/07, Jean-Francois Lamy [EMAIL PROTECTED] wrote: My understanding is that SSL support is only available for Resin Pro, and client won't shell out 1000$ for running on a dual-core PC. So plan B is to install Apache. Looking at my 3.0.21 download, I only see mod_caucho for Apache 2.0. So my understanding is that I need to run legacy Apache 2.0.59 to get SSL support, or has Apache 2.2 support been added since ? Is this correct ? 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
[Resin-interest] Non-alpha characters in config variable names
I had some fun and frustration this morning configuring a new server environment. I mistakenly tried to use variable names like foo.bar and foo-bar in some resin:set / statements. Those didn't work. Instead, resin:set var=foo_bar value=baz / does work. Was this a convention I should have known? It occurs to me now that these statements feel a lot like EL, and perhaps the foo.bar was trying to call a foo.getBar(), and foo-bar might be evaluated as a mathematical expression. resin_documentation_flame If there are restrictions to how variables can be named, it would be very helpful to find those spelled out in the documentation. Additionally, I found resin documentation with typos related to the set xml structure (interesting variable declarations, missing '/', and no explanation of 'value' versus 'default'). /resin_documentation_flame Overall we do enjoy using resin. It's these hidden gems of frustration that keep us on our toes. + jay ___ 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?
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
Re: [Resin-interest] ssl on windows
Riccardo, We have been running 3.0.18Pro with openssl on windows successfully for a while now. We take our certificates - from the root cert, all the intermediate certs, down to our wildcard cert - and bundle them into a pkcs12 file (a .p12 file). You can review the openssl documentation to learn how to do that. We then simply have this stanza in our resin config... http host=1.2.3.4 port=443 jsse-ssl key-store-typepkcs12/key-store-type key-store-file/some/path/to/certs.p12/key-store-file passwordsecret/password /jsse-ssl /http Bonne chance, Jay On 3/15/07, Riccardo Cohen [EMAIL PROTECTED] wrote: Hi, I've been looking at all list archive 2007/2006 available and could not find any answer : I try to run resin 3.0.18 on windows xp sp2 with ssl. I created a crt/key with cygwin and put it in resin.conf and $RESIN_HOME/keys as docs says. I downloaded openssl from the win32 web site as docs says. I first had a link error, because the libeay.dll used was the mswindows one, that I renamed... After that, I had the following error in log : # # An unexpected error has been detected by HotSpot Virtual Machine: # # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x07c1e800, pid=1584, tid=1404 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode) # Problematic frame: # C 0x07c1e800 # # An error report file with more information is saved as hs_err_pid1584.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # One mail of Scott said that it was because the crt/key files where not found. But really I don't know why, because my files are 1) correct (I tried a openssl x509 -in test.crt -text to show the crt content), 2) at specified place $RESIN_HOME/keys/ (I tried to put full path in resin.conf with no success, I tried to change the directory, and place it in resin_home with no success) Did someone succeeded in doing this with 3.0.18 ? Where can I go to solve that ? Thanks -- 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
[Resin-interest] Reconnect to lost java archives
Hi everyone, We're having a problem with apparent disconnection of a shared drive containing the JVM and the JAR files. From time-to-time our application will report ClassDefNotFound exceptions for classes that are truly there. As a result we'll get some missing JSP .class files presumbaly because Resin is deleting them. When we discover the problem, we can see the shared drives, we can see the 'missing' class, and we can see that the JSP's .class file is missing. This feels like the old jdk1.4 bug - fixed in _08 I think - where the JVM couldn't reestablish connection to an archive after it was unavailable for whatever reason. We're running Java5 now, so the JVM shouldn't be an issue, but we're not ruling anything out. Do we know how Resin is designed to react to such a situation? What would Resin do if, for some reason, late into the night, for the briefest of moments, a drive with the JVM and the JARs didn't answer quickly enough? Does Resin give up on seeing that archvie forever (until Resin restart), or can it reconnect to an archive on the fly? + jay ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
