Re: [Resin-interest] Conditionalizing rewrite rules based on file/directory?
On this link there is resin:IfFileExists tag, but I am thinking what you want to do is more simple than that, if you want to elaborate: http://caucho.com/resin-4.0/admin/http-rewrite.xtp Aaron On 3/21/2010 3:03 PM, Rick Mann wrote: With my WordPress installation, I need to redirect some kinds of posts to /index.php. I currently have these two rules: forward regexp=[0-9]+/.* target=/index.php/ forward regexp=^/about/? target=/index.php/ The first redirects URIs that match /year/month/post-name The second redirects the one and only page I have currently, the about page. Under Apache, the rewrite rules can be conditionalized to say, redirect according to this rule only if the resource pointed to by they URI is not an actual file or directory. Is there any way to do that in Resin? TIA, ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Classpath Question
The command line arguments for starting Resin 4.0.x only applied to the
watchdog and NOT the actual resin process itself. JVM command line
arguments are specified in resin.xml. For example, in the command above,
$JAVA_MX and $JAVA_MS applies to the watchdog only. I wouldn't increase the
default 32m max heap size of the watchdog since it does need much memory.
Bill
On Fri, Mar 19, 2010 at 5:53 PM, Aaron Freeman aaron.free...@layerz.comwrote:
It's working now. For completeness and to help others moving from 3.0.x
to 3.1.x or 4.0.x you should change your startup script from this style
(which relies on a wrapper.pl):
$RESIN_HOME/bin/httpd.sh -verbose \
-J-server \
-J-Xmx$JAVA_MX \
-J-Xms$JAVA_MS \
-J-verbose:gc \
-J-XX:MaxGCPauseMillis=5000 \
-J-XX:GCTimeRatio=19 \
-J-XX:+PrintGCTimeStamps \
-J-Djava.security.egd=/dev/urandom \
-J-cp=/opt/server/java/test.jar \
-server-root $SERVER_ROOT \
-Dresin.home=/opt/resin-pro-3.1.9 \
-conf /opt/server/conf/resin.xml \
$1
To something like this:
$JAVA_HOME/bin/java \
-server \
-Xmx$JAVA_MX \
-Xms$JAVA_MS \
-Djava.util.logging.manager=com.caucho.log.LogManagerImpl \
-Djava.security.egd=/dev/urandom \
-Dresin.home=${RESIN_HOME} \
-jar ${RESIN_HOME}/lib/resin.jar \
-conf ${SERVER_ROOT}/conf/resin.xml \
$*
And by the way that magically fixed my resin:type problem as well.
___
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 make this simplest CanDI work ?
smallufo wrote:
I can now pinpoint the error ,
It's because I declare the PersistenceContextType
to PersistenceContextType.EXTENDED !!!
I don't know why resin cannot initialize EXTENDED PersistenceContext
Because extended is only allowed when it's integrated with a stateful
session bean and we haven't finished that part of EJB yet.
(I've never been certain that extended is a good idea. With connection
pooling, the normal transaction should be equivalent.)
-- Scott
Maybe caucho should look into the PersistenceContextGenerator.java ,
create() method
try {
if (PersistenceContextType.EXTENDED.equals(_type)) {
_manager = create(EntityManager.class,
new AnnotationLiteralJpaPersistenceContext() {
public String value() { return _unitName; }
public boolean extended() { return true; }
});
}
2010/3/22 smallufo small...@gmail.com mailto:small...@gmail.com
After a whole day work (but in vain) , I modified my code :
I take off all hibernate-related settings/libraries from
persistence.xml and maven dependencies , I just want to first use
resin's Amber to test whether CanDI works...
This is database settings in resin-web.xml :
database jndi-name=jdbc/mining
driver type=com.mysql.jdbc.Driver
urljdbc:mysql://db/mining?useUnicode=trueamp;characterEncoding=UTF8/url
useradm/user
passwordpwd/password
/driver
max-connections100/max-connections
/database
This is persistence.xml :
persistence xmlns=http://java.sun.com/xml/ns/persistence;
version=1.0
persistence-unit name=mining transaction-type=RESOURCE_LOCAL
non-jta-data-sourcejdbc/mining/non-jta-data-source
classfoo.Person/class
/properties
/persistence-unit
/persistence
When resin inits , I can see Amber successfully get the connection
, and build the connection pool (ManagedPoolItem) .
But I still cannot get PersonDao's implementation , it seems resin
cannot successfully create the PersistenceContext , here is the
FINER log dump :
WebApp[http://test.smallufo.com/testapp-1] map (uri:/hello - hello)
Dispatch '/hello' to
AccessLogFilterChain[http://test.smallufo.com/testapp-1,
next=WebAppFilterChain[http://test.smallufo.com/testapp-1,
next=ServletFilterChain[hello]]]
com.caucho.config.ConfigException: foo.HelloServlet.personDao:
foo.PersonDaoImpl.entityManager java.lang.NullPointerException
at
com.caucho.config.ConfigException.create(ConfigException.java:99)
at
com.caucho.config.ConfigException.create(ConfigException.java:125)
at
com.caucho.config.inject.InjectionTargetImpl$FieldInjectProgram.inject(InjectionTargetImpl.java:811)
at
com.caucho.config.inject.InjectionTargetImpl.inject(InjectionTargetImpl.java:266)
at
com.caucho.server.dispatch.ServletConfigImpl.createServletImpl(ServletConfigImpl.java:1260)
at
com.caucho.server.dispatch.ServletConfigImpl.createServlet(ServletConfigImpl.java:1142)
at
com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:98)
at
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:183)
at
com.caucho.server.webapp.AccessLogFilterChain.doFilter(AccessLogFilterChain.java:103)
at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:286)
at
com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:775)
at
com.caucho.server.connection.TcpConnection.dispatchRequest(TcpConnection.java:600)
at
com.caucho.server.connection.TcpConnection.handleRequestsImpl(TcpConnection.java:566)
at
com.caucho.server.connection.TcpConnection.handleRequests(TcpConnection.java:519)
at
com.caucho.server.connection.TcpConnection$AcceptTask.doTask(TcpConnection.java:1100)
at
com.caucho.server.connection.TcpConnection$ConnectionReadTask.runThread(TcpConnection.java:1037)
at
com.caucho.server.connection.TcpConnection$AcceptTask.run(TcpConnection.java:1068)
at
com.caucho.util.ThreadPool$PoolThread.runTasks(ThreadPool.java:901)
at
com.caucho.util.ThreadPool$PoolThread.run(ThreadPool.java:866)
Caused by: com.caucho.config.ConfigException:
foo.PersonDaoImpl.entityManager java.lang.NullPointerException
at
com.caucho.config.ConfigException.create(ConfigException.java:102)
at
com.caucho.config.j2ee.PersistenceContextGenerator.create(PersistenceContextGenerator.java:121)
at
Re: [Resin-interest] Classpath Question
Ah excellent catch. I just copied those from my 3.0 startup script and
what you said makes complete sense. I will revisit each parameter
carefully.
Thanks,
Aaron
On 3/22/2010 10:20 AM, Bill Au wrote:
The command line arguments for starting Resin 4.0.x only applied to
the watchdog and NOT the actual resin process itself. JVM command
line arguments are specified in resin.xml. For example, in the
command above, $JAVA_MX and $JAVA_MS applies to the watchdog only. I
wouldn't increase the default 32m max heap size of the watchdog since
it does need much memory.
Bill
On Fri, Mar 19, 2010 at 5:53 PM, Aaron Freeman
aaron.free...@layerz.com mailto:aaron.free...@layerz.com wrote:
It's working now. For completeness and to help others moving from
3.0.x
to 3.1.x or 4.0.x you should change your startup script from this
style
(which relies on a wrapper.pl http://wrapper.pl):
$RESIN_HOME/bin/httpd.sh -verbose \
-J-server \
-J-Xmx$JAVA_MX \
-J-Xms$JAVA_MS \
-J-verbose:gc \
-J-XX:MaxGCPauseMillis=5000 \
-J-XX:GCTimeRatio=19 \
-J-XX:+PrintGCTimeStamps \
-J-Djava.security.egd=/dev/urandom \
-J-cp=/opt/server/java/test.jar \
-server-root $SERVER_ROOT \
-Dresin.home=/opt/resin-pro-3.1.9 \
-conf /opt/server/conf/resin.xml \
$1
To something like this:
$JAVA_HOME/bin/java \
-server \
-Xmx$JAVA_MX \
-Xms$JAVA_MS \
-Djava.util.logging.manager=com.caucho.log.LogManagerImpl \
-Djava.security.egd=/dev/urandom \
-Dresin.home=${RESIN_HOME} \
-jar ${RESIN_HOME}/lib/resin.jar \
-conf ${SERVER_ROOT}/conf/resin.xml \
$*
And by the way that magically fixed my resin:type problem as well.
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Resin 4.0.5 production/stable?
I just noticed that resin-pro-3.1.10 no longer says latest stable, or whatever it used to say. Is 4.0.5 now considered stable and production ready? Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4.0.5 production/stable?
I'm sure having a lot of problems with 4.0.5 that I don't have with 4.0.4 (which has different problems). I haven't been able to determine if I'm just doing something wrong, but it seems flaky, at best. On Mar 22, 2010, at 11:59:33, Aaron Freeman wrote: I just noticed that resin-pro-3.1.10 no longer says latest stable, or whatever it used to say. Is 4.0.5 now considered stable and production ready? Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Bug in Resin 4.0.x (and 3.1.x)?
On 3/22/2010 1:11 PM, Scott Ferguson wrote:
Aaron Freeman wrote:
This page says that I can obfuscate a password in the resin.xml file,
but doesn't appear to work. It works in 3.0.23, but stopped working in
3.1.x and 4.0.x. We use this feature, not to protect the password on
the server, but to make sure it isn't accidentally transmitted in
clear-text by mistake when sharing our resin.xml files with consultants,
via email, etc:
http://www.caucho.com/resin/admin/database-pool-config.xtp#Protecting%20the%20database%20password
Here is the error I am getting. I have tried in resin-pro-4.0.2,.4, and
.5, and resin-pro-3.1.9:
/opt/server/conf/resin.xml:44: resin:type=com.encryption.Password is
an unexpected attribute inpassword.
42:key-store-typejks/key-store-type
43:key-store-file/opt/sendthisfile/server/ssl.kdb/key-store-file
44:password resin:type=com.encryption.Passwordabcdefg/password
45:/jsse-ssl
46:/http
Any thoughts?
Thanks. That's a documentation issue.
The resin:type has been replaced by a more general CanDI syntax, which
looks like:
password xmlns:encryption=urn:java:com.encryption
encryption:Passwordabcdefg/encryption:password
/password
In other words, the custom class now has its own XML tag instead of the
resin:type syntax.
(Unfortunately, it was not possible for us to keep the old resin:type
for backwards compatibility, because that would have complicated the key
underlying configuration too much.
Ok, so I thought what you were saying is that this:
password xmlns:encryption=urn:java:com.encryption
encryption:Passwordabcdefg/encryption:password
/password
is a drop-in replacement for this:
password resin:type=com.encryption.Passwordabcdefg/password
but apparently I think you are trying to tell me that we need to change
our Java source code somehow, based on getting this when trying to start
Resin:
/opt/server/conf/resin.xml:47: unable to create attribute
SetterAttribute[public void
com.caucho.vfs.JsseSSLFactory.setPassword(java.lang.String)] for
com.caucho.vfs.jssesslfact...@6779e6 and
QName[{http://caucho.com/ns/resin}password]
So is there a link that you can point me to in order to give me a clue
in what I need to do to modify our source to handle this new syntax?
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4.0.5 production/stable?
I noticed that, which was another reason I thought I should ask before going nuts on 4.0.5. Aaron On 3/22/2010 2:08 PM, Rick Mann wrote: I'm sure having a lot of problems with 4.0.5 that I don't have with 4.0.4 (which has different problems). I haven't been able to determine if I'm just doing something wrong, but it seems flaky, at best. On Mar 22, 2010, at 11:59:33, Aaron Freeman wrote: I just noticed that resin-pro-3.1.10 no longer says latest stable, or whatever it used to say. Is 4.0.5 now considered stable and production ready? Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] 4.0.0 on osx deploy problem
Jeff Schnitzer wrote: FWIW, Resin on OSX seems to work fine despite the error messages. My understanding is that this is a known issue with the Apple JDK, but it doesn't hurt anything. -- Scott Jeff On Sat, Mar 20, 2010 at 6:12 AM, Jon Stevens latch...@gmail.com wrote: Yes, I can't remember what the solution was. =( Sorry! jon On Sat, Mar 20, 2010 at 2:16 AM, Rick Mann rm...@latencyzero.com wrote: John, did you ever find an answer to this? I'm getting it, too. On Jun 29, 2009, at 22:50:52, Jon Stevens wrote: Here is another problem. When deploying subetha on osx using the apple jdk 6, I get the stack trace below. When deplying subetha on osx using the landon fuller soylatte jdk, things work fine. I get a different set of errors using jdk5 which relate to the resin servlets apparently being compiled with jdk6. [16][ ~/checkout/resin-4.0.0 ]% ./bin/resin.sh Intentionally suppressing recursive invocation exception! java.lang.IllegalStateException: recursive invocation at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1394) at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1377) at sun.security.jca.ProviderConfig$1.run(ProviderConfig.java:64) at java.security.AccessController.doPrivileged(Native Method) at sun.security.jca.ProviderConfig.getLock(ProviderConfig.java:62) at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:187) at sun.security.jca.ProviderList.getProvider(ProviderList.java:215) at sun.security.jca.ProviderList.getService(ProviderList.java:313) at sun.security.jca.GetInstance.getInstance(GetInstance.java:140) at java.security.cert.CertificateFactory.getInstance(CertificateFactory.java:148) at sun.security.pkcs.PKCS7.parseSignedData(PKCS7.java:244) at sun.security.pkcs.PKCS7.parse(PKCS7.java:141) at sun.security.pkcs.PKCS7.parse(PKCS7.java:110) at sun.security.pkcs.PKCS7.init(PKCS7.java:92) at sun.security.util.SignatureFileVerifier.init(SignatureFileVerifier.java:80) at java.util.jar.JarVerifier.processEntry(JarVerifier.java:256) at java.util.jar.JarVerifier.update(JarVerifier.java:188) at java.util.jar.JarFile.initializeVerifier(JarFile.java:321) at java.util.jar.JarFile.getInputStream(JarFile.java:386) at sun.misc.JarIndex.getJarIndex(JarIndex.java:99) at sun.misc.URLClassPath$JarLoader$1.run(URLClassPath.java:606) at java.security.AccessController.doPrivileged(Native Method) at sun.misc.URLClassPath$JarLoader.ensureOpen(URLClassPath.java:597) at sun.misc.URLClassPath$JarLoader.init(URLClassPath.java:581) at sun.misc.URLClassPath$3.run(URLClassPath.java:331) at java.security.AccessController.doPrivileged(Native Method) at sun.misc.URLClassPath.getLoader(URLClassPath.java:320) at sun.misc.URLClassPath.getLoader(URLClassPath.java:297) at sun.misc.URLClassPath.getResource(URLClassPath.java:167) at java.net.URLClassLoader$1.run(URLClassLoader.java:192) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at sun.misc.Launcher$ExtClassLoader.findClass(Launcher.java:244) at java.lang.ClassLoader.loadClass(ClassLoader.java:319) at java.lang.ClassLoader.loadClass(ClassLoader.java:309) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:330) at java.lang.ClassLoader.loadClass(ClassLoader.java:254) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:402) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:247) at java.lang.SystemClassLoaderAction.run(ClassLoader.java:2150) at java.security.AccessController.doPrivileged(Native Method) at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1407) at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1377) Intentionally suppressing recursive invocation exception! java.lang.IllegalStateException: recursive invocation at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1394) at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1377) at sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:231) at java.security.AccessController.doPrivileged(Native Method) at sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:225) at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:205) at sun.security.jca.ProviderList.getProvider(ProviderList.java:215) at sun.security.jca.ProviderList.getService(ProviderList.java:313) at sun.security.jca.GetInstance.getInstance(GetInstance.java:140) at java.security.cert.CertificateFactory.getInstance(CertificateFactory.java:148) at
Re: [Resin-interest] Bug in Resin 4.0.x (and 3.1.x)?
Aaron Freeman wrote:
Ok, so I thought what you were saying is that this:
password xmlns:encryption=urn:java:com.encryption
encryption:Passwordabcdefg/encryption:password
/password
is a drop-in replacement for this:
password resin:type=com.encryption.Passwordabcdefg/password
Yes, it should be a direct replacement. (The internal implementation is
a bit tricky, though.)
but apparently I think you are trying to tell me that we need to change
our Java source code somehow, based on getting this when trying to start
Resin:
/opt/server/conf/resin.xml:47: unable to create attribute
SetterAttribute[public void
com.caucho.vfs.JsseSSLFactory.setPassword(java.lang.String)] for
com.caucho.vfs.jssesslfact...@6779e6 and
QName[{http://caucho.com/ns/resin}password]
So is there a link that you can point me to in order to give me a clue
in what I need to do to modify our source to handle this new syntax?
Let me check. I tested the replacement against database. I'll see why
it's causing trouble with jsse.
-- Scott
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Bug in Resin 4.0.x (and 3.1.x)?
On 3/22/2010 2:29 PM, Scott Ferguson wrote:
Aaron Freeman wrote:
Ok, so I thought what you were saying is that this:
password xmlns:encryption=urn:java:com.encryption
encryption:Passwordabcdefg/encryption:password
/password
is a drop-in replacement for this:
password resin:type=com.encryption.Passwordabcdefg/password
Yes, it should be a direct replacement. (The internal implementation is
a bit tricky, though.)
but apparently I think you are trying to tell me that we need to change
our Java source code somehow, based on getting this when trying to start
Resin:
/opt/server/conf/resin.xml:47: unable to create attribute
SetterAttribute[public void
com.caucho.vfs.JsseSSLFactory.setPassword(java.lang.String)] for
com.caucho.vfs.jssesslfact...@6779e6 and
QName[{http://caucho.com/ns/resin}password]
So is there a link that you can point me to in order to give me a clue
in what I need to do to modify our source to handle this new syntax?
Let me check. I tested the replacement againstdatabase. I'll see why
it's causing trouble with jsse.
Ok, here is the full http block I am using, in case its out of date for
some reason (I am using the block directly from our working 3.0.23
implementation verbatim, with your recommended tweak):
http address=* port=443
jsse-ssl
key-store-typejks/key-store-type
key-store-file/opt/server/security/ssl.kdb/key-store-file
password xmlns:encryption=urn:java:com.encryption
encryption:Passwordabcdefg/encryption:Password
/password
/jsse-ssl
/http
- Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] JSP Tag and PHP Issues, Resin 4.0.4 vs 4.0.5
So, I have conflicting results with 4.0.4 and 4.0.5: 4.0.4 - JSP Tags don't work: http://bugs.caucho.com/view.php?id=3956 PHP errors parsing certain PHP constructs Seems to run reliably (however, can't stop server reliably, need to kill it) 4.0.5 - JSP Tags work correctly PHP parsing error still in place WordPress 2.9.2 post titles don't appear anywhere (admin or blog) Very unreliable, stops responding after short period (also can't stop it reliably) Right now, the most critical thing for me will be to get the JSP tag issue resolved, but obviously not at the expense of a reliable server. I might have to write Java-based implementations of those tags to get them to work under 4.0.4. Any additional help on tracking down the stability and WordPress title issues in 4.0.5 would be much appreciated, and I'm happy to pay (within my budget) for this support. Thanks! -- Rick ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Bug in Resin 4.0.x (and 3.1.x)?
Aaron Freeman wrote: Ok, here is the full http block I am using, in case its out of date for some reason (I am using the block directly from our working 3.0.23 implementation verbatim, with your recommended tweak): http address=* port=443 jsse-ssl key-store-typejks/key-store-type key-store-file/opt/server/security/ssl.kdb/key-store-file password xmlns:encryption=urn:java:com.encryption encryption:Passwordabcdefg/encryption:Password /password /jsse-ssl /http What I've found is that if the XML namespace for encryption:* isn't right, i.e. not urn:java:..., you'll get that cryptic error message. If it's right, it's working for me. I'm working on first getting a better error message, and second seeing if there are other failure cases. -- Scott - Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Bug in Resin 4.0.x (and 3.1.x)?
On 3/22/2010 3:44 PM, Scott Ferguson wrote: Aaron Freeman wrote: Ok, here is the full http block I am using, in case its out of date for some reason (I am using the block directly from our working 3.0.23 implementation verbatim, with your recommended tweak): http address=* port=443 jsse-ssl key-store-typejks/key-store-type key-store-file/opt/server/security/ssl.kdb/key-store-file password xmlns:encryption=urn:java:com.encryption encryption:Passwordabcdefg/encryption:Password /password /jsse-ssl /http What I've found is that if the XML namespace forencryption:* isn't right, i.e. not urn:java:..., you'll get that cryptic error message. If it's right, it's working for me. I'm working on first getting a better error message, and second seeing if there are other failure cases. Man, I don't see how I am blowing it then. Does this look right: password xmlns:encryption=urn:java:[full package, not including the class] encryption:[class name]abcdefg/encryption:[class name] /password Where the [full package, not including the class] would be something like java.util and the class name would be something like Hashmap with an uppercase first character like classes normally are capitalized? If so, I am a bit baffled. Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] New 4.0.5 install constantly dropping connections on unloaded server
Scott, I've opened a bug for my 4.0.5 woes, including the config file and logs from my much more modern Open Solaris machine: http://bugs.caucho.com/view.php?id=3960 On Mar 19, 2010, at 13:13:34, Rick Mann wrote: On Mar 19, 2010, at 12:40:23, Scott Ferguson wrote: Rick Mann wrote: Some additional information: I tried installing 4.0.5 on my better server (Resin-4.0.0, Nexenta/Open Solaris, recent, lots of RAM, faster CPUs), and got similar behavior. I got it up and running, noticed some oddness at first (java link errors running my app, slow page loads the first few times), then it seemed to get normal. Then about 5 minutes later, it stopped responding. I didn't investigate, but rather just switched back to using resin-4.0.0. No idea if it was the same issue. In the logs, I saw it restarting, but it never came back. Thanks for the update. Just to review the symptoms: 1. Both JVMs are around and responds to kill -QUIT (there have been cases where the JVM has been so frozen it doesn't respond to anything.) 2. Resin is not responding to connect() for either of two ports. 3. The thread dump shows active threads in the nativeAccept() of both ports. 4. Netstat looks normal (i.e. it's not showing lots of connections in strange states.) My stress testing isn't showing anything like this kind of behavior yet, but any further details would help narrow the tests. Scott, I finally just moved my webapps to my Open Solaris machine, which is much more modern, and has a lot more RAM available. (It is currently running resin-4.0.0, warts and all.) This will allow me to update the older machine at my leisure. The problem I'm facing now is twofold, and the first of these might be related. 1) Attempts to upgrade to resin-4.0.5 have failed. Resin seems to run fine, but then stops after an hour or two. Because this machine is more critical (it hosts the data for my iPhone app), I just switch back to resin-4.0.0, which has problems but is stable. More details about how I installed it below. 2) On both 4.0.0 and 4.0.5, I have problems with Quercus and WordPress. In 4.0.0, I get a StackOverflowError. In 4.0.5, I get a PHP report of a database connection error (and I believe that comes with a 500 response). Installation Details The configuration for both is exactly the same, as much as I can remember and glean from my history. I put the individual resin released in /usr/local/resin/versions(/resin-4.0.0, resin-4.0.5, etc.), and symlink one of those to /usr/local/resin/current. When I installed 4.0.0, I believe I set that up first, then ran ./configure --prefix=/usr/local/resin/current, then make, sudo make install. For 4.0.5, I put it in place, but left the symlink pointing to 4.0.0, and did configure --prefix=/usr/local/resin/versions/resin-4.0.5, make, make install (not sudo). This complains that it couldn't install /etc/resin/ stuff, but I already had that from the previous build. Now, when I switch between versions, I change the symlink, and blow away all the WEB-INF/work directories (I'm posting a separate question about that), sometimes I stop and restart the server via the resin.sh script I have (which is just a wrapper around: java -jar /usr/local/resin/current/lib/resin.jar -verbose -root-directory /var/www -conf /etc/resin/resin.xml $* But usually it restarts itself (because of the symlink change, I presume). When I get some time, I'll try with resin-4.0.4, but I'm supposed to be doing real work for my employer today. -- Rick ___ 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
