Re: IIS 6 + Apache tomcat 5.5.15 + SQL Server 2000 ? ( Windows 20 03 Server )
We have used both JTDS and JDBC to connect Tomcat to SQL2000. JTDS seems to be more memory efficient. It is also far stricter in how data types are cast. Stored Procedures that worked fine with JDBC sometimes did not properly with JTDS. I think the issue (I am not doing the java work) is that the variable types in preparing the statement must be strictly correct... i.e. JTDS will not truncate a string that is too long for the var type but JDBC will. Justin -Original Message- From: Phil Wilson [mailto:[EMAIL PROTECTED] Sent: Thursday, March 09, 2006 10:32 AM To: Tomcat Users List Subject: Re: IIS 6 + Apache tomcat 5.5.15 + SQL Server 2000 ? ( Windows 2003 Server ) I know ... it's not a good Combo IIS 6 + Apache tomcat 5.5.15 + SQL Server 2000 ? ( Windows 2003 Server ) but... let's crash and burn ;) Hi, I've done this combo before using the jTDS driver from http://jtds.sourceforge.net/ If you notice, all of the examples on the URL you give are very very similar, and off the top of my head I can't remember any massive differences between the SQL Server 2000 config and MySQL, so just try the MySQL config (with the correct driverClassName and JDBC URL of course) and see how far you get. Good luck! Phil Checking in the web site i see that i can install the Apache-Tomcat and that works properly ( First time i work with Windows 2003 ). What i'm not plenty sure ... I'm going to face problems if i want to stablish JDBC conectivity with a SQL Server 2000 Database. I just see , Mysql ,Oracle and PostgreSQL Conectivity. http://tomcat.apache.org/tomcat-5.5-doc/jndi-datasource-exampl es-howto.html Regards and Thx In Advance. Sergio Gonzalez Ramos. - LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Performance tricks with multiple tomcat instances
-Original Message- From: Leon Rosenberg [mailto:[EMAIL PROTECTED] Sent: Thursday, March 09, 2006 10:28 AM To: Tomcat Users List Subject: Re: Performance tricks with multiple tomcat instances On 3/9/06, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote: If I were to add my two cents, I would say the OS scheduler, the bus, memory access all will play their part. ie, I think you will get more juice out of 8 single CPU machines each running a tomcat, than one machine with 8 CPU's, as your 8cpu machine will not have 8 parallel buses, 8 drives, 8 everything etc. Of course, but it also means 8 HE rack space, 16 power cables, 8 switch ports etc. It also means 8 systems to backup, to install and to administrate. We are trying to find a configuration between n-one cpu servers and 1 n-cpu server which is best from the manageability point of view and has optimal tco. Personally I don't believe that anything with more than 2 cpu's will ever pay out, but we have to test it :-) I have never been a big fan of single CPU machines for threaded applications. It it too easy for a single slow thread to botteneck the whole system. Going beyond 2 CPUs however is expensive and I think that it is best reserved for applications that - Cannot easily run across load balanced servers, such as a database - Are written to take advantage threading in a way that will truly benefit from having more than 2 CPUs. (i.e, we have an app where one thread is reading data from the network and populating a queue, a thread pool is parsing the queue data and another thread pool is processing the parsed data so having more CPUs would allow us to increase the size of the thread pools and thus make the app run faster). If these two criteria are not met (and there are probably a few more I am missing) then I think it is better to have more less powerful machines which provided redundancy. I have to say that I am always surpised to read when people are setting application servers (such as Tomcat) to maxthreads of 1000. If I had 1000 processes running at the same time on any of my application servers it would melt never finish any of them. It is more realistic to have 5 - 10 threads processing at any given time and to allow requests to queue (though one must test to find the sweet spot). Just my $.02 Justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Is this tomcat or my app?
Fairly regularly I have a page resquest visible on the 'Server Status' of the Tomcat Manager that never ends. I have tomcat set to timeout sockets after 120 seconds, and have mod_jk set to do the same. It always stalls at 4192K sent (is this a magic number?). I tried increasing the output buffer size and have set JKOptions +FlushPackets on the off chance that it would make a difference but it does not seem to. The stack trace obtained through jconsole is below. Can anyone shed any light on this? Could my application be causing this problem? This page has been running for 10209703ms at the moment and while restarting Apache will cause it to exit, I am getting really tired of restarting apache all the time to resolve these issues. Anyone, anyone... Bueller, Bueller? Thank, Justin Name: TP-Processor24 State: RUNNABLE Total blocked: 3,049 Total waited: 75,144 Stack trace: java.net.SocketOutputStream.socketWrite0(Native Method) java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) java.net.SocketOutputStream.write(SocketOutputStream.java:136) org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:506) org.apache.jk.server.JkCoyoteHandler.doWrite(JkCoyoteHandler.java:260) org.apache.coyote.Response.doWrite(Response.java:551) org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java: 361) org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:403) org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:323) org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:392) org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:381) org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.ja va:76) com.seccas.servlet.GetMessagePartServlet.execute(GetMessagePartServlet.java: 226) com.seccas.servlet.GetMessagePartServlet.doGet(GetMessagePartServlet.java:31 ) javax.servlet.http.HttpServlet.service(HttpServlet.java:689) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:252) org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:173) org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja va:214) org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja va:178) org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126 ) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105 ) org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java :107) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:306) org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385) org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:745) org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:675) org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:868) org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:684) java.lang.Thread.run(Thread.java:595) -- Justin Greene SECCAS, LLC. 212-242-9308 x 101 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Performance tricks with multiple tomcat instances
-Original Message- From: Leon Rosenberg [mailto:[EMAIL PROTECTED] Sent: Thursday, March 09, 2006 3:06 PM To: Tomcat Users List Subject: Re: Performance tricks with multiple tomcat instances On 3/9/06, Justin Greene [EMAIL PROTECTED] wrote: -Original Message- From: Leon Rosenberg [mailto:[EMAIL PROTECTED] Sent: Thursday, March 09, 2006 10:28 AM To: Tomcat Users List Subject: Re: Performance tricks with multiple tomcat instances On 3/9/06, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote: If I were to add my two cents, I would say the OS scheduler, the bus, SNIP I have to say that I am always surpised to read when people are setting application servers (such as Tomcat) to maxthreads of 1000. If I had 1000 processes running at the same time on any of my application servers it would melt never finish any of them. It is more realistic to have 5 - 10 threads processing at any given time and to allow requests to queue (though one must test to find the sweet spot). I would say, you are right, but if you want to support http 1.1 keepalives 1.5 threads per user are blocked simply waiting for incoming requests, so how are you supposed to server 500 users with 75 threads? 500 users != 500 concurrent connections (threads). You can likely handle many users being logged in at the same time with very few threads if you take they do not all click a URL at the same time, and even if they did, you would not want to service them all at the same time as your system could not handle it. We set our keepalives pretty short, only a few seconds. If another request does not come in quickly, then it costs a little overhead to create a new connection. Oh well. Try taking an application that has some load and watching the # of active threads in the 'Manager'. We typically have 20 or 30 clients logged in at a time but only see a single active thread at any given time as it only takes milliseconds to service most requests (if we are writing our code well). Justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Workes.properties socket_timeout clarification
The docs state: socket_timeout default 0 Socket timeout in seconds used for communication channel between JK and remote host. If remote host does not respond inside that timeout the JK will generate an error, and retry again. If set to value zero (default) the JK will wait for infinite on all socket operations. How does this differ from reply_timout? Any feedback would be appreciated. Thanks, Justin -- Justin Greene SECCAS, LLC. 212-242-9308 x 101 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem with mod_jk/apache 1.3.34 Windows
) java.io.DataInputStream.readFully(DataInputStream.java:176) java.io.DataInputStream.readFully(DataInputStream.java:152) net.sourceforge.jtds.jdbc.SharedSocket.readPacket(SharedSocket.java:826) net.sourceforge.jtds.jdbc.SharedSocket.getNetPacket(SharedSocket.java:707) net.sourceforge.jtds.jdbc.ResponseStream.getPacket(ResponseStream.java:466) net.sourceforge.jtds.jdbc.ResponseStream.read(ResponseStream.java:103) net.sourceforge.jtds.jdbc.ResponseStream.peek(ResponseStream.java:88) net.sourceforge.jtds.jdbc.TdsCore.wait(TdsCore.java:3870) net.sourceforge.jtds.jdbc.TdsCore.executeSQL(TdsCore.java:1042) net.sourceforge.jtds.jdbc.JtdsStatement.executeSQL(JtdsStatement.java:478) net.sourceforge.jtds.jdbc.JtdsPreparedStatement.execute(JtdsPreparedStatemen t.java:478) org.apache.tomcat.dbcp.dbcp.DelegatingPreparedStatement.execute(DelegatingPr eparedStatement.java:168) ...SNIP In both cases, restarting apache resolves the issue. Any thoughts that anyone has would be greatly appreciated. I am running out of things to try on the troubleshooting side. We are also pursuing whether our code could somehow be contibuting to this... Some sort of session synchronization issue or something. Thanks, Justin -- Justin Greene SECCAS, LLC. 212-242-9308 x 101 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with mod_jk/apache 1.3.34 Windows
-Original Message- From: Mladen Turk [mailto:[EMAIL PROTECTED] Sent: Monday, March 06, 2006 12:33 PM To: Tomcat Users List Subject: Re: Problem with mod_jk/apache 1.3.34 Windows Justin Greene wrote: SNIP Do not use cachesize with values higher then 1 on Apache 2.x prefork or Apache 1.3.x! I believe that this only applies to Non-Windows installations. (correct me if I am wrong here) Apache 1.3.34 on Windows is multi-threaded and you must set the cachesize = webserver child processes. This change resolved the 'Server Busy Page' issue. I believe that by only having 1 thread essentially causes it to run in Right. cachesize=MaxClients on Windows. On Apache2 it's set by querying the mpm if omitted. It would be nice if the docs reflected this :-) Apache 1.3.x on Windows for production? I must admit, you guys are very brave ;) Been running for years and have found it quite stable, however our use is very specific, static files, mod_jk and mod_[old version of cold fusion]. Very little room for anything to go wrong here. The cold fusion mod (v4.1.something) is not available for apache 2 mod so we are a little stuck on 1.3.34 at the moment. Justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk errors - are these normal?
-Original Message- From: michael thomas [mailto:[EMAIL PROTECTED] Sent: Monday, March 06, 2006 4:42 PM To: Tomcat Users List Subject: TomcatUsers: Re: mod_jk errors - are these normal? --- Sven K�hler [EMAIL PROTECTED] wrote: [Wed Mar 01 20:00:42 2006] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (961): Can't receive the response message from tomcat, network problems or tomcat is down (10.0.0.9:8009), err=-113 [Wed Mar 01 20:00:42 2006] [error] ajp_get_reply::jk_ajp_common.c (1503): Tomcat is down or refused connection. No response has been sent to the client (yet) SNIP 2. It seems like people who have apache and tomcat running on the same server can get away without any errors. We are running on the same server (windows) and get these error contantly... Actually, our read: [Mon Mar 06 16:32:22 2006] [error] jk_ajp_common.c (961): Can't receive the response message from tomcat, network problems or tomcat is down (127.0.0.1:8009), err=-54 [Mon Mar 06 16:32:22 2006] [error] jk_ajp_common.c (1503): Tomcat is down or refused connection. No response has been sent to the client (yet) Which is subely different. Anyone have a reference to what the various 'err=' codes mean? Justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX via SSH tunnel does not work?
We had issues using jconsole remotely a while back (jdk 1.5.0_02) that we were never able to solve. If memory serves, jconsole opens a connection on the specified port to that Java instance. An additional port or two (I can't remember) are then opened and the ports that are used are somewhat random making it very difficult to do this through anything that needs to port forward or needs ports opened. I do not remember if the additional ports are opened by jconsole or the other way, but you can see it by connecting locally and checking netstat for connections to/from the jconsole process. The only solution here is to be able to specify the additional ports, but at the time there was no way to do this. I have not looked into the jconsole or JMX options since so I do not know if this was added. Justin -Original Message- From: Andreas Schildbach [mailto:[EMAIL PROTECTED] Sent: Monday, March 06, 2006 4:57 PM To: users@tomcat.apache.org Subject:Re: JMX via SSH tunnel does not work? Hello Mikolaj, I have set up the JMX server of JDK 1.5.0_06/Tomcat 5.5.15. It works fine locally, I'm testing with jconsole. However, if I tunnel the JMX port over SSH, it does not work. I can connect to the port, but there is no flow of data. jconsole is hanging around for a minute, and then the connect dialog pops up. What is going wrong here? http://forum.java.sun.com/thread.jspa?threadID=565139tstart=30 http://forum.java.sun.com/thread.jspa?threadID=289869messageID=124228 8 I understand the problem, but do not know how to solve it. Can you give an example how the java.rmi.server.hostname and java.rmi.server.useLocalHostname properties on the client and the server should be set in this case? Regards, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
