RE: Re[2]: JRUN Stability- reply
When running from the command line, I get the following two errors appear when I first run it, The strange thing is, that the 51003 port is not active prior to starting JRUN, and when I do run this command, it does activate it. ~ Jon 04/14 14:50:01 error Exception thrown in operation start [1]java.net.BindException: Port in use by another service or process: 51003 at jrun.servlet.network.NetworkService.bindToSocket(NetworkService.java:341) at jrun.servlet.network.NetworkService.start(NetworkService.java:202) at jrun.servlet.jrpp.JRunProxyService.start(JRunProxyService.java:77) at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at jrunx.kernel.ServiceAdapter.invokeMethod(ServiceAdapter.java:705) at jrunx.kernel.JRunServiceDeployer.invokeOnServices(JRunServiceDeployer.java:4 60) at jrunx.kernel.JRunServiceDeployer.startServices(JRunServiceDeployer.java:312) at jrunx.kernel.JRunServiceDeployer.startLifecycle(JRunServiceDeployer.java:260 ) at jrunx.kernel.JRunServiceDeployer.deployServices(JRunServiceDeployer.java:87) at jrunx.kernel.DeploymentService.loadServices(DeploymentService.java:46) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at jrunx.kernel.JRun.startServer(JRun.java:558) at jrunx.kernel.JRun.init(JRun.java:476) at jrunx.kernel.JRun$1.run(JRun.java:329) at java.security.AccessController.doPrivileged(Native Method) at jrunx.kernel.JRun.start(JRun.java:326) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at jrunx.kernel.JRun.invoke(JRun.java:180) at jrunx.kernel.JRun.main(JRun.java:168) [0]javax.management.MBeanException: Exception thrown in operation start at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1644) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at jrunx.kernel.ServiceAdapter.invokeMethod(ServiceAdapter.java:705) at jrunx.kernel.JRunServiceDeployer.invokeOnServices(JRunServiceDeployer.java:4 60) at jrunx.kernel.JRunServiceDeployer.startServices(JRunServiceDeployer.java:312) at jrunx.kernel.JRunServiceDeployer.startLifecycle(JRunServiceDeployer.java:260 ) at jrunx.kernel.JRunServiceDeployer.deployServices(JRunServiceDeployer.java:87) at jrunx.kernel.DeploymentService.loadServices(DeploymentService.java:46) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at jrunx.kernel.JRun.startServer(JRun.java:558) at jrunx.kernel.JRun.init(JRun.java:476) at jrunx.kernel.JRun$1.run(JRun.java:329) at java.security.AccessController.doPrivileged(Native Method) at jrunx.kernel.JRun.start(JRun.java:326) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at jrunx.kernel.JRun.invoke(JRun.java:180) at jrunx.kernel.JRun.main(JRun.java:168) [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: JRUN Stability- reply 2
Kathy, we run primarily on windows.I have done some tests on linux, but not to this extent. Our app uses keepalive connections that remain open, so we need a very high level of concurrency.In production we run at 750 concurrent connections (users) per node.The JRun server doesn't seem to pre-allocate the threads, so they remain upper limits.We also run with a non-sanctioned patch provided by macromedia folks, because regular JRun will get stuck at 1000 activeHandlerThreads.They gave me the patch, but in followup email have been quiet to answer my request for info on when the change would be incorporated into the base code.I was working with someone by the name of Stephen Dupre last August; he was most helpful. Using the patch we have tested just beyond 1800 in our lab with the IBM jvm and 1700 with the sun jvm, before we run into memory management problems.We use the following jvm args now with sun 1.4: -Xms128m -Xmx128m -Xss64k In order to use such high settinmgs you also need to adjust your web server because by default they don't permit such high levels of concurrency either - I assume as a precaution against DOS attacks.So you have to adjust your Apache or IIS settings. If I recall my experiments properly, the jvm on windows is limited to 2048 threads, so to get beyond that on a single machine you need to have multiple vm's.So, I put several JRun servers under IIS, but then I started to run up against some upper limits of IIS.I never got further than 4000 concurrent connections for a single win2k box with 1 cpu, and that was with three JRun servers under IIS. Hope that helps, BenG. [EMAIL PROTECTED] wrote: Ben, How is the stability and performance of JRun server after you set activeHandlerThreads to 2000? Usually the number of the maxHandlerThreads should be bigger than activeHandlerThreads? As I understand, JRun would not perform well if the number of activeHandlerThreads is too big. Could you share your experience here? How busy would the traffic be on your site and is your site running in UNIX box? Thanks. Kathy --- Ben Groeneveld [EMAIL PROTECTED] wrote: This is true; to achieve high levels of concurrency we run with attribute name=activeHandlerThreads2000/attribute attribute name=maxHandlerThreads2000/attribute Hope that helps, BenG. [EMAIL PROTECTED] wrote: Thanks for the advice!.. I have Metrics turned on currently, monitoring every 20 seconds, and I get 0/0, 0 Sessions.. It does specifically say Web-Threads so, I looked for an additional setting for the proxy, (as we're using the JRUN connector via IIS on another server) but that was the only metrics option in the jrun.xml file. ~ Jon -Original Message- From: Kathy Vance [mailto:[EMAIL PROTECTED] Jon, I have the same problem while I did loading testing on JRun 4. We spent $500 for macromedia tech support in order to solve the issue. Please check your jrun.xml. There is a service called ProxyService. You need to increase the value of the attribute named activeHandlerThreads to a number based on how busy your app is. I remember the default value is 15. Also, You can turn on Metrics logging to decide how many threads you need. Sometimes you could get the same error mentioned while using jsp forward tag. But I believe that Updater 3 may solve forwarding issue on JRun 4. for your info, Kathy --- Jon Austin [EMAIL PROTECTED] wrote: Thanks to all for their input on this topic, I am getting more resource directed to this in the next day or, so, and will be running through some of the troubleshooting tips given here. I understand that many of you are running successfully, with many concurrent users, the question now, I have for those people, is what kind of scope is your application? Are we simply talking glorified web-sites with a little processing behind them, or are we talking full hard-code business applications. Our application falls heavily on the latter, and before I base conclusions on other peoples abilities to produce results under this environment, I want to be sure that we're in the same ballpark. One error which a user did capture during a server-halt the other day, was : Too many concurrent requests, jcp.endpoint.main.max.threads exceeded. I found documents on how to resolve this on JRUN3.. but none of the files that are referenced in that document, exist on my JRUN4 implimenation.Does anyone know where I can find the new settings fro JRUN4. Thanks ~ Jon [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: JRUN Stability- reply 2
Hi Ben, You have to admit we were in some unexplored territory with that hotfix patch.(it's still being discussed). I don't think this applies to the general server hung issue Jon originally posted which is best handled by some of the debugging techniques mentioned by others (stack trace, etc) without changing the environment (JVMs, etc). Your app is very unique.It actually can have 750 concurrent, ACTIVE/RUNNING threads which doesn't resemble the typical web app of 10-20 possible request threads with maybe 5-10 active at any one time and constantly changing.I'm frankly amazed that you were able to tune it so well with JRun and find all those outer limitations of JVMs, etc that you mention. Stephen Dupre Macromedia QA -Original Message- From: Ben Groeneveld [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 1:12 PM To: JRun-Talk Subject: Re: JRUN Stability- reply 2 Kathy, we run primarily on windows.I have done some tests on linux, but not to this extent. Our app uses keepalive connections that remain open, so we need a very high level of concurrency.In production we run at 750 concurrent connections (users) per node.The JRun server doesn't seem to pre-allocate the threads, so they remain upper limits.We also run with a non-sanctioned patch provided by macromedia folks, because regular JRun will get stuck at 1000 activeHandlerThreads.They gave me the patch, but in followup email have been quiet to answer my request for info on when the change would be incorporated into the base code.I was working with someone by the name of Stephen Dupre last August; he was most helpful. Using the patch we have tested just beyond 1800 in our lab with the IBM jvm and 1700 with the sun jvm, before we run into memory management problems.We use the following jvm args now with sun 1.4: -Xms128m -Xmx128m -Xss64k In order to use such high settinmgs you also need to adjust your web server because by default they don't permit such high levels of concurrency either - I assume as a precaution against DOS attacks.So you have to adjust your Apache or IIS settings. If I recall my experiments properly, the jvm on windows is limited to 2048 threads, so to get beyond that on a single machine you need to have multiple vm's.So, I put several JRun servers under IIS, but then I started to run up against some upper limits of IIS.I never got further than 4000 concurrent connections for a single win2k box with 1 cpu, and that was with three JRun servers under IIS. Hope that helps, BenG. [EMAIL PROTECTED] wrote: Ben, How is the stability and performance of JRun server after you set activeHandlerThreads to 2000? Usually the number of the maxHandlerThreads should be bigger than activeHandlerThreads? As I understand, JRun would not perform well if the number of activeHandlerThreads is too big. Could you share your experience here? How busy would the traffic be on your site and is your site running in UNIX box? Thanks. Kathy --- Ben Groeneveld [EMAIL PROTECTED] wrote: This is true; to achieve high levels of concurrency we run with attribute name=activeHandlerThreads2000/attribute attribute name=maxHandlerThreads2000/attribute Hope that helps, BenG. [EMAIL PROTECTED] wrote: Thanks for the advice!.. I have Metrics turned on currently, monitoring every 20 seconds, and I get 0/0, 0 Sessions.. It does specifically say Web-Threads so, I looked for an additional setting for the proxy, (as we're using the JRUN connector via IIS on another server) but that was the only metrics option in the jrun.xml file. ~ Jon -Original Message- From: Kathy Vance [mailto:[EMAIL PROTECTED] Jon, I have the same problem while I did loading testing on JRun 4. We spent $500 for macromedia tech support in order to solve the issue. Please check your jrun.xml. There is a service called ProxyService. You need to increase the value of the attribute named activeHandlerThreads to a number based on how busy your app is. I remember the default value is 15. Also, You can turn on Metrics logging to decide how many threads you need. Sometimes you could get the same error mentioned while using jsp forward tag. But I believe that Updater 3 may solve forwarding issue on JRun 4. for your info, Kathy --- Jon Austin [EMAIL PROTECTED] wrote: Thanks to all for their input on this topic, I am getting more resource directed to this in the next day or, so, and will be running through some of the troubleshooting tips given here. I understand that many of you are running successfully, with many concurrent users, the question now, I have for those people, is what kind of scope is your application? Are we simply talking glorified web-sites with a little processing behind them, or are we
Re: JRUN Stability- reply 2
[EMAIL PROTECTED] wrote: Hi Ben, You have to admit we were in some unexplored territory with that hotfix patch.(it's still being discussed). I don't think this applies to the general server hung issue Jon originally posted which is best handled by some of the debugging techniques mentioned by others (stack trace, etc) without changing the environment (JVMs, etc). Your app is very unique.It actually can have 750 concurrent, ACTIVE/RUNNING threads which doesn't resemble the typical web app of 10-20 possible request threads with maybe 5-10 active at any one time and constantly changing.I'm frankly amazed that you were able to tune it so well with JRun and find all those outer limitations of JVMs, etc that you mention. Well of course that is the beauty of our profession - we are all writing unique apps.I hope you didn't find this email on a negative note.I am most appreciative of your help.It's just the absense of a response that puzzled me.Thanks, BenG. Stephen Dupre Macromedia QA -Original Message- From: Ben Groeneveld [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 1:12 PM To: JRun-Talk Subject: Re: JRUN Stability- reply 2 Kathy, we run primarily on windows.I have done some tests on linux, but not to this extent. Our app uses keepalive connections that remain open, so we need a very high level of concurrency.In production we run at 750 concurrent connections (users) per node.The JRun server doesn't seem to pre-allocate the threads, so they remain upper limits.We also run with a non-sanctioned patch provided by macromedia folks, because regular JRun will get stuck at 1000 activeHandlerThreads.They gave me the patch, but in followup email have been quiet to answer my request for info on when the change would be incorporated into the base code.I was working with someone by the name of Stephen Dupre last August; he was most helpful. Using the patch we have tested just beyond 1800 in our lab with the IBM jvm and 1700 with the sun jvm, before we run into memory management problems.We use the following jvm args now with sun 1.4: -Xms128m -Xmx128m -Xss64k In order to use such high settinmgs you also need to adjust your web server because by default they don't permit such high levels of concurrency either - I assume as a precaution against DOS attacks.So you have to adjust your Apache or IIS settings. If I recall my experiments properly, the jvm on windows is limited to 2048 threads, so to get beyond that on a single machine you need to have multiple vm's.So, I put several JRun servers under IIS, but then I started to run up against some upper limits of IIS.I never got further than 4000 concurrent connections for a single win2k box with 1 cpu, and that was with three JRun servers under IIS. Hope that helps, BenG. [EMAIL PROTECTED] wrote: Ben, How is the stability and performance of JRun server after you set activeHandlerThreads to 2000? Usually the number of the maxHandlerThreads should be bigger than activeHandlerThreads? As I understand, JRun would not perform well if the number of activeHandlerThreads is too big. Could you share your experience here? How busy would the traffic be on your site and is your site running in UNIX box? Thanks. Kathy --- Ben Groeneveld [EMAIL PROTECTED] wrote: This is true; to achieve high levels of concurrency we run with attribute name=activeHandlerThreads2000/attribute attribute name=maxHandlerThreads2000/attribute Hope that helps, BenG. [EMAIL PROTECTED] wrote: Thanks for the advice!.. I have Metrics turned on currently, monitoring every 20 seconds, and I get 0/0, 0 Sessions.. It does specifically say Web-Threads so, I looked for an additional setting for the proxy, (as we're using the JRUN connector via IIS on another server) but that was the only metrics option in the jrun.xml file. ~ Jon -Original Message- From: Kathy Vance [mailto:[EMAIL PROTECTED] Jon, I have the same problem while I did loading testing on JRun 4. We spent $500 for macromedia tech support in order to solve the issue. Please check your jrun.xml. There is a service called ProxyService. You need to increase the value of the attribute named activeHandlerThreads to a number based on how busy your app is. I remember the default value is 15. Also, You can turn on Metrics logging to decide how many threads you need. Sometimes you could get the same error mentioned while using jsp forward tag. But I believe that Updater 3 may solve forwarding issue on JRun 4. for your info, Kathy --- Jon Austin [EMAIL PROTECTED] wrote: Thanks to all for their input on this topic, I am getting more resource directed to this in the next day or, so
RE: Re[2]: JRUN Stability- reply
As is always the case, my timeframe for load-testing the server was diverted in favor of rising priorities, and so I have yet to get this going properly. I have had the metrics running overnight, but I'm still getting Zero for Zero, with Zero sessions.There are generally 3-5 people on most of the day, so I'm at a loss as to why no metrics are showing..And the other question, is if the box is really doing nothing, why does it crash? ;-) I've restarted the JRUN service from the command line, and I'm logging to out.txt, but it appears only STDOUT is going there, STDERR appears to be echoing on the console, so where will I need to capture the stack trace, when needed? Thanks, ~ Jon -Original Message- Thanks for the advice!.. I have Metrics turned on currently, monitoring every 20 seconds, and I get 0/0, 0 Sessions.. It does specifically say Web-Threads so, I looked for an additional setting for the proxy, (as we're using the JRUN connector via IIS on another server) but that was the only metrics option in the jrun.xml file. ~ Jon [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: JRUN Stability- reply 2
Sorry.No, actually, I'd just plain forgotten. This thread was a good reminder to me that we have to revisit this for possible checkin. I know who will be knocking when that happens..Keep in touch. Stephen Dupre Macromedia QA -Original Message- From: Ben Groeneveld [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 2:04 PM To: JRun-Talk Subject: Re: JRUN Stability- reply 2 [EMAIL PROTECTED] wrote: Hi Ben, You have to admit we were in some unexplored territory with that hotfix patch.(it's still being discussed). I don't think this applies to the general server hung issue Jon originally posted which is best handled by some of the debugging techniques mentioned by others (stack trace, etc) without changing the environment (JVMs, etc). Your app is very unique.It actually can have 750 concurrent, ACTIVE/RUNNING threads which doesn't resemble the typical web app of 10-20 possible request threads with maybe 5-10 active at any one time and constantly changing.I'm frankly amazed that you were able to tune it so well with JRun and find all those outer limitations of JVMs, etc that you mention. Well of course that is the beauty of our profession - we are all writing unique apps.I hope you didn't find this email on a negative note.I am most appreciative of your help.It's just the absense of a response that puzzled me.Thanks, BenG. Stephen Dupre Macromedia QA -Original Message- From: Ben Groeneveld [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 1:12 PM To: JRun-Talk Subject: Re: JRUN Stability- reply 2 Kathy, we run primarily on windows.I have done some tests on linux, but not to this extent. Our app uses keepalive connections that remain open, so we need a very high level of concurrency.In production we run at 750 concurrent connections (users) per node.The JRun server doesn't seem to pre-allocate the threads, so they remain upper limits.We also run with a non-sanctioned patch provided by macromedia folks, because regular JRun will get stuck at 1000 activeHandlerThreads.They gave me the patch, but in followup email have been quiet to answer my request for info on when the change would be incorporated into the base code.I was working with someone by the name of Stephen Dupre last August; he was most helpful. Using the patch we have tested just beyond 1800 in our lab with the IBM jvm and 1700 with the sun jvm, before we run into memory management problems.We use the following jvm args now with sun 1.4: -Xms128m -Xmx128m -Xss64k In order to use such high settinmgs you also need to adjust your web server because by default they don't permit such high levels of concurrency either - I assume as a precaution against DOS attacks.So you have to adjust your Apache or IIS settings. If I recall my experiments properly, the jvm on windows is limited to 2048 threads, so to get beyond that on a single machine you need to have multiple vm's.So, I put several JRun servers under IIS, but then I started to run up against some upper limits of IIS.I never got further than 4000 concurrent connections for a single win2k box with 1 cpu, and that was with three JRun servers under IIS. Hope that helps, BenG. [EMAIL PROTECTED] wrote: Ben, How is the stability and performance of JRun server after you set activeHandlerThreads to 2000? Usually the number of the maxHandlerThreads should be bigger than activeHandlerThreads? As I understand, JRun would not perform well if the number of activeHandlerThreads is too big. Could you share your experience here? How busy would the traffic be on your site and is your site running in UNIX box? Thanks. Kathy --- Ben Groeneveld [EMAIL PROTECTED] wrote: This is true; to achieve high levels of concurrency we run with attribute name=activeHandlerThreads2000/attribute attribute name=maxHandlerThreads2000/attribute Hope that helps, BenG. [EMAIL PROTECTED] wrote: Thanks for the advice!.. I have Metrics turned on currently, monitoring every 20 seconds, and I get 0/0, 0 Sessions.. It does specifically say Web-Threads so, I looked for an additional setting for the proxy, (as we're using the JRUN connector via IIS on another server) but that was the only metrics option in the jrun.xml file. ~ Jon -Original Message- From: Kathy Vance [mailto:[EMAIL PROTECTED] Jon, I have the same problem while I did loading testing on JRun 4. We spent $500 for macromedia tech support in order to solve the issue. Please check your jrun.xml. There is a service called ProxyService. You need to increase the value of the attribute named activeHandlerThreads to a number based on how busy your app is. I remember the default value is 15. Also, You can turn on Metrics logging to decide how many threads you
RE: Re[2]: JRUN Stability- reply
Jon, I have the same problem while I did loading testing on JRun 4. We spent $500 for macromedia tech support in order to solve the issue. Please check your jrun.xml. There is a service called ProxyService. You need to increase the value of the attribute named activeHandlerThreads to a number based on how busy your app is. I remember the default value is 15. Also, You can turn on Metrics logging to decide how many threads you need. Sometimes you could get the same error mentioned while using jsp forward tag. But I believe that Updater 3 may solve forwarding issue on JRun 4. for your info, Kathy --- Jon Austin [EMAIL PROTECTED] wrote: Thanks to all for their input on this topic, I am getting more resource directed to this in the next day or, so, and will be running through some of the troubleshooting tips given here. I understand that many of you are running successfully, with many concurrent users, the question now, I have for those people, is what kind of scope is your application? Are we simply talking glorified web-sites with a little processing behind them, or are we talking full hard-code business applications. Our application falls heavily on the latter, and before I base conclusions on other peoples abilities to produce results under this environment, I want to be sure that we're in the same ballpark. One error which a user did capture during a server-halt the other day, was : Too many concurrent requests, jcp.endpoint.main.max.threads exceeded. I found documents on how to resolve this on JRUN3.. but none of the files that are referenced in that document, exist on my JRUN4 implimenation.Does anyone know where I can find the new settings fro JRUN4. Thanks ~ Jon [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Re[2]: JRUN Stability- reply
Thanks for the advice!.. I have Metrics turned on currently, monitoring every 20 seconds, and I get 0/0, 0 Sessions.. It does specifically say Web-Threads so, I looked for an additional setting for the proxy, (as we're using the JRUN connector via IIS on another server) but that was the only metrics option in the jrun.xml file. ~ Jon -Original Message- From: Kathy Vance [mailto:[EMAIL PROTECTED] Jon, I have the same problem while I did loading testing on JRun 4. We spent $500 for macromedia tech support in order to solve the issue. Please check your jrun.xml. There is a service called ProxyService. You need to increase the value of the attribute named activeHandlerThreads to a number based on how busy your app is. I remember the default value is 15. Also, You can turn on Metrics logging to decide how many threads you need. Sometimes you could get the same error mentioned while using jsp forward tag. But I believe that Updater 3 may solve forwarding issue on JRun 4. for your info, Kathy --- Jon Austin [EMAIL PROTECTED] wrote: Thanks to all for their input on this topic, I am getting more resource directed to this in the next day or, so, and will be running through some of the troubleshooting tips given here. I understand that many of you are running successfully, with many concurrent users, the question now, I have for those people, is what kind of scope is your application? Are we simply talking glorified web-sites with a little processing behind them, or are we talking full hard-code business applications. Our application falls heavily on the latter, and before I base conclusions on other peoples abilities to produce results under this environment, I want to be sure that we're in the same ballpark. One error which a user did capture during a server-halt the other day, was : Too many concurrent requests, jcp.endpoint.main.max.threads exceeded. I found documents on how to resolve this on JRUN3.. but none of the files that are referenced in that document, exist on my JRUN4 implimenation.Does anyone know where I can find the new settings fro JRUN4. Thanks ~ Jon [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: JRUN Stability- reply
This is true; to achieve high levels of concurrency we run with attribute name=activeHandlerThreads2000/attribute attribute name=maxHandlerThreads2000/attribute Hope that helps, BenG. [EMAIL PROTECTED] wrote: Thanks for the advice!.. I have Metrics turned on currently, monitoring every 20 seconds, and I get 0/0, 0 Sessions.. It does specifically say Web-Threads so, I looked for an additional setting for the proxy, (as we're using the JRUN connector via IIS on another server) but that was the only metrics option in the jrun.xml file. ~ Jon -Original Message- From: Kathy Vance [mailto:[EMAIL PROTECTED] Jon, I have the same problem while I did loading testing on JRun 4. We spent $500 for macromedia tech support in order to solve the issue. Please check your jrun.xml. There is a service called ProxyService. You need to increase the value of the attribute named activeHandlerThreads to a number based on how busy your app is. I remember the default value is 15. Also, You can turn on Metrics logging to decide how many threads you need. Sometimes you could get the same error mentioned while using jsp forward tag. But I believe that Updater 3 may solve forwarding issue on JRun 4. for your info, Kathy --- Jon Austin [EMAIL PROTECTED] wrote: Thanks to all for their input on this topic, I am getting more resource directed to this in the next day or, so, and will be running through some of the troubleshooting tips given here. I understand that many of you are running successfully, with many concurrent users, the question now, I have for those people, is what kind of scope is your application? Are we simply talking glorified web-sites with a little processing behind them, or are we talking full hard-code business applications. Our application falls heavily on the latter, and before I base conclusions on other peoples abilities to produce results under this environment, I want to be sure that we're in the same ballpark. One error which a user did capture during a server-halt the other day, was : Too many concurrent requests, jcp.endpoint.main.max.threads exceeded. I found documents on how to resolve this on JRUN3.. but none of the files that are referenced in that document, exist on my JRUN4 implimenation.Does anyone know where I can find the new settings fro JRUN4. Thanks ~ Jon [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: JRUN Stability- reply 2
Ben, How is the stability and performance of JRun server after you set activeHandlerThreads to 2000? Usually the number of the maxHandlerThreads should be bigger than activeHandlerThreads? As I understand, JRun would not perform well if the number of activeHandlerThreads is too big. Could you share your experience here? How busy would the traffic be on your site and is your site running in UNIX box? Thanks. Kathy --- Ben Groeneveld [EMAIL PROTECTED] wrote: This is true; to achieve high levels of concurrency we run with attribute name=activeHandlerThreads2000/attribute attribute name=maxHandlerThreads2000/attribute Hope that helps, BenG. [EMAIL PROTECTED] wrote: Thanks for the advice!.. I have Metrics turned on currently, monitoring every 20 seconds, and I get 0/0, 0 Sessions.. It does specifically say Web-Threads so, I looked for an additional setting for the proxy, (as we're using the JRUN connector via IIS on another server) but that was the only metrics option in the jrun.xml file. ~ Jon -Original Message- From: Kathy Vance [mailto:[EMAIL PROTECTED] Jon, I have the same problem while I did loading testing on JRun 4. We spent $500 for macromedia tech support in order to solve the issue. Please check your jrun.xml. There is a service called ProxyService. You need to increase the value of the attribute named activeHandlerThreads to a number based on how busy your app is. I remember the default value is 15. Also, You can turn on Metrics logging to decide how many threads you need. Sometimes you could get the same error mentioned while using jsp forward tag. But I believe that Updater 3 may solve forwarding issue on JRun 4. for your info, Kathy --- Jon Austin [EMAIL PROTECTED] wrote: Thanks to all for their input on this topic, I am getting more resource directed to this in the next day or, so, and will be running through some of the troubleshooting tips given here. I understand that many of you are running successfully, with many concurrent users, the question now, I have for those people, is what kind of scope is your application? Are we simply talking glorified web-sites with a little processing behind them, or are we talking full hard-code business applications. Our application falls heavily on the latter, and before I base conclusions on other peoples abilities to produce results under this environment, I want to be sure that we're in the same ballpark. One error which a user did capture during a server-halt the other day, was : Too many concurrent requests, jcp.endpoint.main.max.threads exceeded. I found documents on how to resolve this on JRUN3.. but none of the files that are referenced in that document, exist on my JRUN4 implimenation.Does anyone know where I can find the new settings fro JRUN4. Thanks ~ Jon [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
