Pid, Thanks for the response, I have contacted the developers of our web site to separate the documentRoot directories. Also, I have tested the SSL with httpd turned off, and I don't seem to have the same luck. I received the following error: Error code: ssl_error_rx_record_too_long. I believe this was because Apache did not find the ssl.conf setting to enable SSL (I commented it out for testing). Once I re-enabled it the error went away, but I was wondering if this could mean that some configuration setting is missing or incorrect with Tomcat. I have researched the error, but haven't found anything that may help. Here is the snippet from server.xml that specifies the SSL settings:
<!-- Define a SSL HTTP/1.1 Connector on port 8443 --> <Connector port="443" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="/usr/local/ssl/private/fun.macneillgroup.com.keystore" keypass="nottherealkeypass" truststoreFile="/usr/local/ssl/cert/fun.macneillgroup.com.crt" truststorePass="nottherealkeypass" /> Also, you mentioned a bad mod_jk. The httpd.conf calls mod_proxy, which currently doesn't have any specific settings. I tried to manipulate the entry to point to our site:443 but the page didn't display. Sorry for explosion of thoughts. I want to make know (if my rambling hasn't already), I am very new to Apache/Tomcat. Is there a resource that I can use to identify "good practices" to manage this web server. Please note that this server was setup by a consulting company which created the page, I have been recently tasked to manage it and configure the SSL. Thanks again. Miguel Ortiz Network Engineer x4818 wk: 954-331-4818 bbry: 954-649-1863 miguel.or...@macneillgroup.com -----Original Message----- From: Pid [mailto:p...@pidster.com] Sent: Tuesday, September 29, 2009 5:12 AM To: Tomcat Users List Subject: Re: How to check if the client dropped the connection On 29/09/2009 09:47, aaime74 wrote: > > > Markus Meyer wrote: >> >> I'm not saying you should store the whole map all at once. My approach >> was to dynamically cache requests that the client may want to make in >> advance. An easy example would be if a client makes a request for the >> city center, you create the map for the city center plus the suburbs >> around it and store it somewhere, then return the city center. If the >> user then moves around a bit to see the suburbs, you already have the >> whole map cached and just need to return it, no need to do any further >> calculation. >> > > Sorry, I've lost you there. How is drawing a bigger image going to solve > the problem, which in the end is both a CPU waste but also an OOM > due to too many images being generated at the same time because > of the user zooming in and out fast (most of them are actually not > wanted anymore by the client which in the meantime will drop the > connection). ... because for future requests, the data already exists and the work is already done. The consequences of a dropped connection are therefore reduced because you're not doing the work for every single request, and any work you are doing isn't completely wasted. Take for example the situation where a user zooms in one direction, changes their mind & goes back (say to check a point of origin), then *again* reverses direction to proceed as before. If you've cached the responses to the first motion then you don't need to do the work again when the third motion occurs - and the work done the first time isn't wasted. Queuing the requests for generating images would allow you to limit how much work was being done and reduce the chances of an OOM. It might simply be that you can't achieve what you want without lots of RAM and more processing power than you currently have. You may find that you must either queue the generator requests to manage the load on the server - at the price of making clients wait for data, or you that you must add more processing power & RAM. (It sounds like your current setup can't cope with a single users' peak load.) Caching stuff mitigates some of the problems you have but it won't solve the overall problem (which is not that connections are dropped - it's that the work done is both wasted and too much for the server to handle). p > If anything your suggestion seems to make the client wait longer and > the server OOM faster. > Markus Meyer wrote: >> >> If you then also compress the image on the fly while you are reading it >> from disk (or from some memory cache), you will start writing to the >> output stream very soon (also detecting the dropped connection very >> soon) and the servlet will not need much RAM. Of course this does not >> work if you just use Java's built-in PNG encoder. >> >> Obviously, caching always comes with the price that you will have the >> occassional cache miss :-) That is, this does not work for every request >> but may decrease load and RAM usage a lot for typical use cases. >> > > WMS and tile systems are related, but they don't work the same way, > I cited tiling because it's the thing people know the most given the > Google maps popularity. > > A desktop WMS client won't use any pre-defined tile structure, each > request will be different in terms of layer requested, zoom level, > and area. The potential for caching is very, very low. > > The tile system are on the other side setup to make caching possible > and efficient by imposing structure on the requests, but what I'm dealing > with here is pure WMS. > > What I'm talking about here are the industry standard solutions for > WMS map rendering. We can discuss this at lenght and we could come > out with some interesting new way that was not tried before in the > field. But in the meatime I would really appreciate if anybody could > answer my first question: how does one detect the client connection > has been dropped? Is there any way? Does anybody know? > > > Markus Meyer wrote: >> >> In your OP you write: "Unfortunately in the meantime the older requests >> are still running, drawing a map takes time and a lot of memory, for >> example the above request, which is a small one btw, allocates a >> BufferedImage of 700KB." This indicates that you (1) seem to not use any >> caching ("drawing a map takes time" - with caching the map would already >> have been drawn) and (2) you use BufferedImage which of course does not >> allow you to PNG-encode on the fly. Both problems would be solved with >> the above suggestion. >> > > The rendering subsystem actually takes a Graphics2D. If you can suggest > ways to draw lines, points and polygons on a raster image that is not > memory bound (like a buffered image) and has no "sewing" effects > (like tiles, that do break labelling, long story, don't get me started on > this) > I'm all ears. > > Cheers > Andrea --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.112/2390 - Release Date: 09/28/09 17:53:00 This email and any files transmitted with it are the confidential property of Focus Holdings, LLC and its subsidiaries, and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
