RE: Problem building Tomcat connector
See inline. De bedste hilsner/ Best regards Casper Wandahl Schmidt | ExpandIT Mobile ApS Udviklingskonsulent c...@expandit.com | T: +45 70 26 86 19 | M: +45 50 44 46 33 www.expandit.com | Nyhedsbrev | Se katalog -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: 18. september 2013 16:05 To: Tomcat Users List Subject: Re: Problem building Tomcat connector -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Casper, On 9/17/13 3:01 PM, Casper Wandahl Schmidt wrote: > After being away from this list for some time I’m now back for help. I > recently upgraded my home server to Ubuntu 12.04.2 LTS with Apache > 2.2.22. I’m now trying to build the tomcat connector to get tomcat > (not installed yet, but think I will go for newest Tomcat 8 when time > comes) and apache to communicate. Should be no problem to get these set up. > I have downloaded the source and unpacked it. You are talking about the "Tomcat Connector", mod_jk, right? CWS: Yes, sorry, thought it was clear from the subject line :) > I then do cd native/ and tried ./configure > –with-apxs=/usr/bin/apxs2 but the command fails saying: “configure: > error: C++ preprocessor ‘/lib/cpp’ fails sanity check”. > > > Config.log has the following to say: > > [snip] > > gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) > > [snip] > > configure:5036: checking for g++ > > configure:5065: result: no > > configure:5036: checking for c++ > > configure:5065: result: no > > configure:5036: checking for gpp > > configure:5065: result: no > > configure:5036: checking for aCC > > configure:5065: result: no > > configure:5036: checking for CC > > configure:5065: result: no > > configure:5036: checking for cxx > > configure:5065: result: no > > configure:5036: checking for cc++ > > configure:5065: result: no > > configure:5036: checking for cl > > configure:5065: result: no > > configure:5036: checking for FCC > > configure:5065: result: no > > configure:5036: checking for KCC > > configure:5065: result: no > > configure:5036: checking for RCC > > configure:5065: result: no > > configure:5036: checking for xlC_r > > configure:5065: result: no > > configure:5036: checking for xlC > > configure:5065: result: no > > configure:5078: checking for C++ compiler version > > configure:5081: g++ --version &5 Boy, for knowing that g++ doesn't exist, configure sure seems to want to interrogate the hell out of it... > configure:5666: error: C++ preprocessor "/lib/cpp" fails sanity check > > See `config.log' for more details. Although it does not explicitly state it anywhere in the documentation, you'll need to have a C++ compiler installed. You'll need to install the 'g++' package on Debian/Ubuntu in order to compile mod_jk. I'm not sure why a c++ compiler is required. It does not appear to be a requirement for httpd. CWS: "sudo apt-get install g++" did fix the problem and mod_jk.so is now compiled :) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSObL4AAoJEBzwKT+lPKRY58AQAJAFOrCalyibTfOnoAdEBRfZ P6zpWShxA/TnsU31QB11K9dbsJ3i7Xv9yOOYCJryNOBP5fETEzdDUqnbc2kFeGNu tZh5wNTLNMlWaXgnbOgYqjDmmz53XpQ2saIGBel8PnEhix5qsXWHr9HJSOs7jwJk 5yUSMRm8/3l92vW4bxFnVs0eperlfZFEeMAk8Yh2v9ciXmiHAz38iHqJZWpiBr4o SV9iNKgOfZYkGtf2AYt7IR7XF52gR7goSf18tJy0e8imFJXTfGhcsiuu/I289ed+ 5lu0CEaSLHPLDbKpmALNOVV2hWidVDmZ/0m8Zuv287Mdulkbp1u3G5INbdb4A/4I v6aYIOJhw3ZY2HbeOM7ERRo8n0331RVOYKyOC+IycD6NE6MFC4MGb3t4uWFnQOdG VOcPHbsayqu5Ph0RGkDeUsWTevWLUXAIkbeTIf/ymLhN1c6BraYHyDR3497Wa0uQ guQS+9U2Bf1sGs3/0hqReyE6DS5KnrTWXhnuCFCDYL74CoyY60JLhnaitFfvGI+J uBRKVj7wWQG1/fl/LZCClNkQ3o93isZe/yjYhWfcFlOZuHYix/PAjGRaerCPKvzf LNzFQnW0Cw3jWvvKhLe0qOLeGHulLcZUrxMdyt2mUcqteM1D1ncqixESVyQYfmnN COBqVzC3iigb6FJwnP+w =gH3d -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat classes from previous run remains
Dear All, I am running an j2ee application which uses spring, hibernate, jsf, etc. the application also uses ha-jdbc to make the databases highly available. when the application is deployed for the first time, the app runs smoothly, but when it is un-deployed and deployed back, tomcat gives the following error: The following web applications were stopped (reloaded, undeployed), but their classes from previous runs are still loaded in memory, thus causing a memory leak (use a profiler to confirm): I am wondering how to get rid of this problem. One Solution is restarting the server. Please let me know the solution with out restarting the server if any. Thanking You!! *Best Regards,* *Saurabh Sarasvat*
RSocket Error
Hi Folks, We are getting below random error while sending request from one web application to another. It is messing up the live application only for some of the requests. java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read(BufferedInputStream.java:237) at org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78) at org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106) at org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1116) at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.readLine(MultiThreadedHttpConnectionManager.java:1413) at org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1973) at org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1735) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1098) at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398) at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323) at com.btsl.flares.apps.mmoney.communicator.HTTPCommunicator.sendHTTPMessage(HTTPCommunicator.java:240) at com.btsl.flares.apps.mmoney.acceptor.handler.OneShotRequestHandler.processResponse(OneShotRequestHandler.java:81) at com.btsl.flares.apps.mmoney.utils.MessageProcessor.run(MessageProcessor.java:96) Please suggest what could be possible reason and fixes for the above issue. TXN = jdk1.6.0_33 OS: Linux on Solaris Regards, Divya This e-mail and all material transmitted with it are for the use of the intended recipient(s) ONLY and contains confidential and/or privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken pursuant to the contents of the present e-mail is strictly prohibited and is unlawful. The recipient acknowledges that Comviva Technologies Limited or its management or directors, are unable to exercise control or ensure the integrity over /of the contents of the information contained in e-mail. Any views expressed herein are those of the individual sender only and no binding nature of the contents shall be implied or assumed unless the sender does so expressly with due authority of Comviva Technologies Limited. E-mail and any contents transmitted with it are prone to viruses and related defects despite all efforts to avoid such by Comviva Technologies Limited.
Re: Problems with Clustering / Session Replication
alternatively try an explicit address in the Receiver configuration instead of address="auto" try address="192.168.1.43" this should alter the log displayed at start-up and I would be very interested if you still had a problem. On Thu, Sep 19, 2013 at 10:35 AM, Vince Stewart wrote: > Hi Nicholas, > > I'm am a bit of a novice but I did have a very similar problem when I > started using the clustering modules. > My Tomcat output was referring to localhost (10.x.x.x) addresses while my > netstat was reporting LISTEN on network addresses (192.x.x.x:400?). > You have the same disparity. My system operated to expectation after I > registered my machine's network IP address in linux folder /etc/hosts. > Once I did that tomcat clustering logs started reporting membership with > network addresses instead of localhost addresses. > > > > > > On Thu, Sep 19, 2013 at 2:37 AM, Mark Eggers wrote: > >> On 9/18/2013 6:00 AM, Nicholas Violi wrote: >> >>> Thanks Daniel. >>> >>> On Tue, Sep 17, 2013 at 5:30 PM, Daniel Mikusa >> >wrote: >>> Tried a quick two node setup on my Mac w/out HTTPD and it worked OK. Go to one Tomcat instance's port in chrome, it increments the counter in my app. Refresh a few times. Open a second tab, go to the second Tomcat instance's port. The counter picks up where it left off and continues incrementing. Flipping back and forth between tabs / servers works fine. Here's the cluster config that I used in case it helps. >>> className="org.apache.**catalina.ha.tcp.**SimpleTcpCluster"> >>> className="org.apache.**catalina.ha.session.**DeltaManager" expireSessionsOnShutdown="**false" notifyListenersOnReplication="**true"/> >>> className="org.apache.**catalina.tribes.group.**GroupChannel"> >>> className="org.apache.**catalina.tribes.membership.**McastService" dropTime="3000" frequency="500" port="45564"/> >>>autoBind="100" className="org.apache.**catalina.tribes.transport.nio.**NioReceiver" maxThreads="6" port="4000" selectorTimeout="5000"/> >>> className="org.apache.**catalina.tribes.transport.** ReplicationTransmitter"> >>> className="org.apache.**catalina.tribes.transport.nio.** PooledParallelSender"/> >>> className="org.apache.**catalina.tribes.group.**interceptors.** TcpFailureDetector"/> >>> className="org.apache.**catalina.tribes.group.**interceptors.** MessageDispatch15Interceptor"/**> >>> className="org.apache.**catalina.ha.tcp.**ReplicationValve" filter=""/> >>> className="org.apache.**catalina.ha.session.**JvmRouteBinderValve"/> >>> className="org.apache.**catalina.ha.session.** JvmRouteSessionIDBinderListene**r"/> >>> className="org.apache.**catalina.ha.session.**ClusterSessionListener"/> >>> Just tried this with the same results. My test that replication is >>> behaving >>> is accessing my webapp on the two ports and monitoring the session >>> counter >>> and list in the tomcat manager, and as I said before, I can only see the >>> sessions created on the server attached to the manager instance. Is that >>> a >>> reasonable test? With the clustering config pretty well ruled out as the >>> culprit, maybe my webapp is not dealing with sessions appropriately? >>> Would >>> you mind sending me your counter test app? >>> >>> Beyond that, have you tried increasing the log levels? >>> >>> >>> I found conflicting information about enabling logging. What I had >>> previously was >>> >>> org.apache.catalina.tribes.**level = FINE >>> org.apache.catalina.tribes.**MESSAGES = FINE >>> >>> in logging.properties, which was reporting the FINE log statements in my >>> original post. I just added some more: >>> >>> org.apache.catalina.ha.level = FINE >>> org.apache.catalina.ha.**session.level = FINE >>> org.apache.catalina.ha.**session.DeltaManager.level = FINE >>> org.apache.catalina.ha.tcp.**level = FINE >>> org.apache.catalina.ha.tcp.**level = FINE >>> org.apache.catalina.ha.tcp.**ReplicationValve.level = FINE >>> org.apache.catalina.ha.**session.**ClusterSessionListener.level = FINE >>> org.apache.catalina.ha.**session.**JvmRouteSessionIDBinterListene**r.level >>> = FINE >>> >>> And I still don't see any messages when interacting with the webapp in >>> the >>> browser. Are there a
Re: Problems with Clustering / Session Replication
Hi Nicholas, I'm am a bit of a novice but I did have a very similar problem when I started using the clustering modules. My Tomcat output was referring to localhost (10.x.x.x) addresses while my netstat was reporting LISTEN on network addresses (192.x.x.x:400?). You have the same disparity. My system operated to expectation after I registered my machine's network IP address in linux folder /etc/hosts. Once I did that tomcat clustering logs started reporting membership with network addresses instead of localhost addresses. On Thu, Sep 19, 2013 at 2:37 AM, Mark Eggers wrote: > On 9/18/2013 6:00 AM, Nicholas Violi wrote: > >> Thanks Daniel. >> >> On Tue, Sep 17, 2013 at 5:30 PM, Daniel Mikusa > >wrote: >> >>> >>> Tried a quick two node setup on my Mac w/out HTTPD and it worked OK. Go >>> to one Tomcat instance's port in chrome, it increments the counter in my >>> app. Refresh a few times. Open a second tab, go to the second Tomcat >>> instance's port. The counter picks up where it left off and continues >>> incrementing. Flipping back and forth between tabs / servers works >>> fine. >>> >>> Here's the cluster config that I used in case it helps. >>> >>> >> >>> className="org.apache.**catalina.ha.tcp.**SimpleTcpCluster"> >>> >> className="org.apache.**catalina.ha.session.**DeltaManager" >>> expireSessionsOnShutdown="**false" >>> notifyListenersOnReplication="**true"/> >>> >> className="org.apache.**catalina.tribes.group.**GroupChannel"> >>> >> >>> className="org.apache.**catalina.tribes.membership.**McastService" >>> dropTime="3000" >>> frequency="500" >>> port="45564"/> >>> >>autoBind="100" >>> >>> className="org.apache.**catalina.tribes.transport.nio.**NioReceiver" >>>maxThreads="6" >>>port="4000" >>>selectorTimeout="5000"/> >>> >> className="org.apache.**catalina.tribes.transport.** >>> ReplicationTransmitter"> >>> >> className="org.apache.**catalina.tribes.transport.nio.** >>> PooledParallelSender"/> >>> >>> >> className="org.apache.**catalina.tribes.group.**interceptors.** >>> TcpFailureDetector"/> >>> >> className="org.apache.**catalina.tribes.group.**interceptors.** >>> MessageDispatch15Interceptor"/**> >>> >>> >> className="org.apache.**catalina.ha.tcp.**ReplicationValve" >>> filter=""/> >>> >> className="org.apache.**catalina.ha.session.**JvmRouteBinderValve"/> >>> >> className="org.apache.**catalina.ha.session.** >>> JvmRouteSessionIDBinderListene**r"/> >>> >> className="org.apache.**catalina.ha.session.**ClusterSessionListener"/> >>> >>> >>> >> Just tried this with the same results. My test that replication is >> behaving >> is accessing my webapp on the two ports and monitoring the session counter >> and list in the tomcat manager, and as I said before, I can only see the >> sessions created on the server attached to the manager instance. Is that a >> reasonable test? With the clustering config pretty well ruled out as the >> culprit, maybe my webapp is not dealing with sessions appropriately? Would >> you mind sending me your counter test app? >> >> Beyond that, have you tried increasing the log levels? >> >> >> I found conflicting information about enabling logging. What I had >> previously was >> >> org.apache.catalina.tribes.**level = FINE >> org.apache.catalina.tribes.**MESSAGES = FINE >> >> in logging.properties, which was reporting the FINE log statements in my >> original post. I just added some more: >> >> org.apache.catalina.ha.level = FINE >> org.apache.catalina.ha.**session.level = FINE >> org.apache.catalina.ha.**session.DeltaManager.level = FINE >> org.apache.catalina.ha.tcp.**level = FINE >> org.apache.catalina.ha.tcp.**level = FINE >> org.apache.catalina.ha.tcp.**ReplicationValve.level = FINE >> org.apache.catalina.ha.**session.**ClusterSessionListener.level = FINE >> org.apache.catalina.ha.**session.**JvmRouteSessionIDBinterListene**r.level >> = FINE >> >> And I still don't see any messages when interacting with the webapp in the >> browser. Are there any other classes I should be logging? >> >> Thanks, >> Nick >> >> > Copy-pasted from a message I sent to the mailing list about 3 weeks ago: > > It's been a while since I've played with this, so your mileage may vary. > > # wrapped for easier reading > # added one additional handler > > handlers = 1catalina.org.apache.juli.**FileHandler, >2localhost.org.apache.juli.**FileHandler, >3manager.org.apache.ju
[OT] (Non-ASF) Tomcat meet-up next week in San Francisco
I'm speaking at JavaOne next week [1] on building WebSocket support on top of Servlet 3.1 and the challenges with doing that. $work has taken advantage of the fact that I am in town to schedule one of their 'Pivotal Open Source Hub' events [2] on 'Everything Tomcat' where I'll be talking about Tomcat 8 and anything else Tomcat related folks want to discuss. There are still places available so do sign up if you are near San Francisco next week and would like to come along. Mark [1] https://oracleus.activeevents.com/2013/connect/sessionDetail.ww?SESSION_ID=3651 [2] http://www.meetup.com/Pivotal-Open-Source-Hub/events/136113432/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Tomcat-7.0.42/JmxRemoteLifecycleListener] rmiBindAddress vs localhost
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Marcin, On 9/18/13 8:58 AM, Marcin Domański wrote: > 2013/9/12 >> On 9/11/13 2:29 PM, Marcin Domański wrote: >>> Hi there! I am trying to setup a Tomcat instance using only >>> specific address for all communications. This is convenient for >>> us from the point of IPsec. I was able to succeed in http, >>> https, ajp, etc. but for JMX I still cannot get it right. For >>> this example, let's assume, my desired address is 127.2.0.1. >>> Currently my configuration is as follows: >>> >>> - >> className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener" >>> >>> rmiRegistryPortPlatform="9012" rmiServerPortPlatform="9013" >>> useLocalPorts="true" /> >>> >>> >>> Which allows to connect to the server at >>> "service:jmx:rmi:///jndi/rmi:// 127.2.0.1:9012/jmxrmi but also >>> localhost (means I cannot run second instance with different >>> IP) >> >> Hmm. I would have expected "useLocalPorts" to bind only to >> 127.0.0.1 (i.e. localhost). What does netstat tell you under this >> configuration? > > I see open ports to 127.2.0.1:9012 whenever I have rmiBindAddress > set and applied patch in JmxRemoteLifecycleListener to use > rmiBindAddress instead of localhost around line 304, otherwise I > get exception whenever I use rmiBindAddress=127.2.0.1 and no ports > are open. What patch did you apply? > Netstat with patch and rmiBindAddress=127.0.2.1 and > useLocalPorts=false: TCP 127.0.2.1:9012 XXX:0 > LISTENING TCP 127.0.2.1:9013 XXX:0 > LISTENING > > Netstat with patch and rmiBindAddress=127.0.2.1 and > useLocalPorts=true: > > TCP 127.0.2.1:9012 XXX:0LISTENING TCP > 127.0.2.1:9013 XXX:0LISTENING That certainly looks like useLocalPorts is not doing anything in your configuration. I suppose it depends upon whatever patch you applied. I don't think you should require a patch... just don't use useLocalPorts=true and let rmiBindAddresss do its job. Isn't the above what you wanted? To bind on the VPN interface? > Seems that it connects differently because I see it using localhost > for connections to port 9013 and 127.0.2.1 for 9012 (remote > address in netstat) The above look identical to me (both ports are are for 127.0.2.1). Am I missing something? >>> On Windows machine I get a network error basically saying there >>> is no server configured at localhost in >>> JmxRemoteLifecycleListener:304. >> >> You get this on startup? Post the full stack trace, please. >> > > Yes, it is a startup of Tomcat itself, not my J2EE application. You > can try it yourself. Stack is as follows: > > java.io.IOException: Cannot bind to URL > [rmi://localhost:9012/jmxrmi]: > javax.naming.ServiceUnavailableException [Root exception is > java.rmi.ConnectException: Connection refused to host: localhost; > nested exception is: java.net.ConnectException: Connection refused: > connect] I think it's important for you to tell us what your patch does. Nobody knows what you've done in there. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSOesRAAoJEBzwKT+lPKRY6BMQALWgjldYM/1JGZ0Vhs5ge5bz rV90oDZb8k+iLPQIU2X1Rf7/znWz8DauAFvAwS5ghvgljdKBtZuoA6VDVZIzb+BV eERg8Cbe07XY38Jw65chW5YKdxxy2+bMPdAvb5xkO3LjTTJfIkB5ZL8EigvTTaKY zlrk2SreRzSyZiYNvqSjKoUpRMfnVL4EhvXwDauXFSnLnINE4T0CTwJ5lm0Wy3lS 5SDFuAZKRHQ6phEPnRxy0b0CekW3Pucw7m+um/07P2yI3ygkSGRH1hgZPIudDH2E 98I2ei5HdRtgNEMYUbPqpSioaz309nQjb6cVmjnfdInLN0TApw9QTbQG3Yryg8Kx YSwaiMwid2TCvj+KNine4pvmRZ9ddFyslpBO7aqVR/G4Voqgg+ToxRbkqH3pdBqy 32qv3/gLJA7Mame9+0j/X9/+MbsyJqnuHcW+290ERXe5C2gXUXxnWhuLRBqRkKyl +Kr5zh6X5fgO7OX884PjXtvvpZfibGJO66OFTNZDMma02mCjJDnWuNX37I+FXMva PhLqpv7kgB5KbtwG+kliyyxRY9ygfQ/xDudL6d5WCxVjzq7OOxbr+lwxvEHKYfb6 Rz8JVPcgfqmuJ7QshT7vCkUOlGgTsJGxNnXC2n2KgdqeJhhO8TrDgG+QXtChR4SW DaE8PEM0m/u3XpKsUoBs =a8eK -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
tomcat7-maven-plugin enable auto deployment under webapps
Hello fellow tomcat7-maven-plugin users, Is there a way to configure the embedded tomcat launched via the tomcat7-maven-plugin in such a way that the ${project.build.directory}/tomcat/webapps folder will be monitored for automatic deployments like it is with a standard tomcat bundle? I dug around in the source of tomcat7-maven-plugin and even experimented with my own modified version of the plugin where I added a HostConfig() object to the embedded tomcat instance. This seems to get the scanning of "webapps" folder working again but when it goes to hot-deploy any webapps out there, it quickly runs into ClassNotFound exceptions because the WebappClassLoader for the thread that is hot-deploy my new webapp doesn't have the right parent classloader. I see where the tomcat7-maven-plugin is creating the WebappClassLoader for all of the configured contexts via the config section for the maven plugin. But I'm not sure how to get the WebappClassLoaders that are created by the HostConfig.deployDirectory() to do the same. Any clues? Appreciate the help anyone can give. -- Greg Amerson Liferay Developer Tools Liferay, Inc. www.liferay.com
Re: Problems with Clustering / Session Replication
On 9/18/2013 6:00 AM, Nicholas Violi wrote: Thanks Daniel. On Tue, Sep 17, 2013 at 5:30 PM, Daniel Mikusa wrote: Tried a quick two node setup on my Mac w/out HTTPD and it worked OK. Go to one Tomcat instance's port in chrome, it increments the counter in my app. Refresh a few times. Open a second tab, go to the second Tomcat instance's port. The counter picks up where it left off and continues incrementing. Flipping back and forth between tabs / servers works fine. Here's the cluster config that I used in case it helps. Just tried this with the same results. My test that replication is behaving is accessing my webapp on the two ports and monitoring the session counter and list in the tomcat manager, and as I said before, I can only see the sessions created on the server attached to the manager instance. Is that a reasonable test? With the clustering config pretty well ruled out as the culprit, maybe my webapp is not dealing with sessions appropriately? Would you mind sending me your counter test app? Beyond that, have you tried increasing the log levels? I found conflicting information about enabling logging. What I had previously was org.apache.catalina.tribes.level = FINE org.apache.catalina.tribes.MESSAGES = FINE in logging.properties, which was reporting the FINE log statements in my original post. I just added some more: org.apache.catalina.ha.level = FINE org.apache.catalina.ha.session.level = FINE org.apache.catalina.ha.session.DeltaManager.level = FINE org.apache.catalina.ha.tcp.level = FINE org.apache.catalina.ha.tcp.level = FINE org.apache.catalina.ha.tcp.ReplicationValve.level = FINE org.apache.catalina.ha.session.ClusterSessionListener.level = FINE org.apache.catalina.ha.session.JvmRouteSessionIDBinterListener.level = FINE And I still don't see any messages when interacting with the webapp in the browser. Are there any other classes I should be logging? Thanks, Nick Copy-pasted from a message I sent to the mailing list about 3 weeks ago: It's been a while since I've played with this, so your mileage may vary. # wrapped for easier reading # added one additional handler handlers = 1catalina.org.apache.juli.FileHandler, 2localhost.org.apache.juli.FileHandler, 3manager.org.apache.juli.FileHandler, 4host-manager.or.apache.juli.FileHandler, java.util.logging.ConsoleHandler, 5cluster.org.apache.juli.FileHandler # just the new cluster log handler - all others are stock # logging.properties # beware of the wrapping 5cluster.org.apache.juli.FileHandler.level = FINER 5cluster.org.apache.juli.FileHandler.directory = ${catalina.base}/logs 5cluster.org.apache.juli.FileHandler.prefix = cluster. # just the clustering logs - all others are stock logging.properties org.apache.catalina.tribes.MESSAGES.level = FINE org.apache.catalina.tribes.MESSAGES.handlers = 5cluster.org.apache.juli.FileHandler org.apache.catalina.tribes.level = FINE org.apache.catalina.tribes.handlers = 5cluster.org.apache.juli.FileHandler org.apache.catalina.ha.level = FINE org.apache.catalina.ha.handlers = 5cluster.org.apache.juli.FileHander org.apache.catalina.ha.deploy.level = INFO org.apache.catalina.ha.deploy.handlers = 5cluster.org.apache.juli.FileHandler Set logging at the desired level. I think I've posted this to the mailing list before . . . /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem building Tomcat connector
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Casper, On 9/17/13 3:01 PM, Casper Wandahl Schmidt wrote: > After being away from this list for some time I’m now back for > help. I recently upgraded my home server to Ubuntu 12.04.2 LTS with > Apache 2.2.22. I’m now trying to build the tomcat connector to get > tomcat (not installed yet, but think I will go for newest Tomcat 8 > when time comes) and apache to communicate. Should be no problem to get these set up. > I have downloaded the source and unpacked it. You are talking about the "Tomcat Connector", mod_jk, right? > I then do cd native/ and tried ./configure > –with-apxs=/usr/bin/apxs2 but the command fails saying: “configure: > error: C++ preprocessor ‘/lib/cpp’ fails sanity check”. > > > Config.log has the following to say: > > [snip] > > gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) > > [snip] > > configure:5036: checking for g++ > > configure:5065: result: no > > configure:5036: checking for c++ > > configure:5065: result: no > > configure:5036: checking for gpp > > configure:5065: result: no > > configure:5036: checking for aCC > > configure:5065: result: no > > configure:5036: checking for CC > > configure:5065: result: no > > configure:5036: checking for cxx > > configure:5065: result: no > > configure:5036: checking for cc++ > > configure:5065: result: no > > configure:5036: checking for cl > > configure:5065: result: no > > configure:5036: checking for FCC > > configure:5065: result: no > > configure:5036: checking for KCC > > configure:5065: result: no > > configure:5036: checking for RCC > > configure:5065: result: no > > configure:5036: checking for xlC_r > > configure:5065: result: no > > configure:5036: checking for xlC > > configure:5065: result: no > > configure:5078: checking for C++ compiler version > > configure:5081: g++ --version &5 Boy, for knowing that g++ doesn't exist, configure sure seems to want to interrogate the hell out of it... > configure:5666: error: C++ preprocessor "/lib/cpp" fails sanity > check > > See `config.log' for more details. Although it does not explicitly state it anywhere in the documentation, you'll need to have a C++ compiler installed. You'll need to install the 'g++' package on Debian/Ubuntu in order to compile mod_jk. I'm not sure why a c++ compiler is required. It does not appear to be a requirement for httpd. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSObL4AAoJEBzwKT+lPKRY58AQAJAFOrCalyibTfOnoAdEBRfZ P6zpWShxA/TnsU31QB11K9dbsJ3i7Xv9yOOYCJryNOBP5fETEzdDUqnbc2kFeGNu tZh5wNTLNMlWaXgnbOgYqjDmmz53XpQ2saIGBel8PnEhix5qsXWHr9HJSOs7jwJk 5yUSMRm8/3l92vW4bxFnVs0eperlfZFEeMAk8Yh2v9ciXmiHAz38iHqJZWpiBr4o SV9iNKgOfZYkGtf2AYt7IR7XF52gR7goSf18tJy0e8imFJXTfGhcsiuu/I289ed+ 5lu0CEaSLHPLDbKpmALNOVV2hWidVDmZ/0m8Zuv287Mdulkbp1u3G5INbdb4A/4I v6aYIOJhw3ZY2HbeOM7ERRo8n0331RVOYKyOC+IycD6NE6MFC4MGb3t4uWFnQOdG VOcPHbsayqu5Ph0RGkDeUsWTevWLUXAIkbeTIf/ymLhN1c6BraYHyDR3497Wa0uQ guQS+9U2Bf1sGs3/0hqReyE6DS5KnrTWXhnuCFCDYL74CoyY60JLhnaitFfvGI+J uBRKVj7wWQG1/fl/LZCClNkQ3o93isZe/yjYhWfcFlOZuHYix/PAjGRaerCPKvzf LNzFQnW0Cw3jWvvKhLe0qOLeGHulLcZUrxMdyt2mUcqteM1D1ncqixESVyQYfmnN COBqVzC3iigb6FJwnP+w =gH3d -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Audit Exceptions on Apache
On Sep 18, 2013, at 9:00 AM, Obba Joy wrote: > Hello Team, Please don't post the same message to the list twice. This list is made up of volunteers who will respond to your request as they have time. If you need a faster response or more hand holding, please consider purchasing a support contract from one of the many companies that offer this service. > Some security issues were raised by our audit team and these > issues were forwarded to secur...@apache.org. > We got a response from Mark Thomas from the Security team > Theses issues are listed below: > > 1. Banner Disclosure > We observed that the GTApplication web server disclosed the > Apache Coyote version in its HTTP response. The extracted version > is: Apache-Coyote/1.1 > Risk > This information might help an attacker gain a greater understanding of > the systems in use and potentially develop further attacks targeted at the > specific version of Apache. > > Response > > Not a vulnerability in Apache Tomcat. Every currently supported version of > Apache Tomcat includes that information in the header. All it tells an > attacker is that you are running Apache Tomcat. If you really want to change > it, a configuration option to do that is available on the connector. Have you looked at the connector docs? https://tomcat.apache.org/tomcat-7.0-doc/config/http.html HINT: Search for the "server" attribute. > 2. The Character Set was not set. > The Character set (Charset) was not explicitly set by the > server. > Risk > There is a risk that characters in content are incorrectly > interpreted by the server. Lack of charset can cause the browser > to guess the encoding type and this could lead to Cross-site > Scripting by encoding the payload in > encoding types like UTF-7. > > Response > > Not a vulnerability in Apache Tomcat. RFC2616 requires clients to treat > responses without a character encoding as being encoding with ISO-8859-1. > Clients that try to guess the charset are in breach of RFC2616. Further that > they might do so in an unsafe manner is a security vulnerability in those > clients and should be reported to the appropriate vendor. If the vendor(s) of > the vulnerable client(s) are unwilling to fix this vulnerability there are > multiple ways that it could be mitigated. For example, with a filter that > always sets the character set. Again, docs are your friend. https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#Add_Default_Character_Set_Filter Dan > > Kindly send documents that will assist us in resolving these vulnerabilities > > Kind Regards - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Audit Exceptions on Apache
Hello David, Kindly assist with the documentation I need to use Regards From: David kerber To: Tomcat Users List Sent: Wednesday, September 18, 2013 2:09 PM Subject: Re: Audit Exceptions on Apache On 9/18/2013 5:04 AM, Joy Obba wrote: > Hello Team, > > Some security issues were raised by our audit team and these issues were > forwarded to secur...@apache.org. > We got a response from Mark Thomas from the Security team > Theses issues are listed below: > > 1. Banner Disclosure > We observed that the GTApplication web server disclosed the Apache > Coyote version in its HTTP response. The extracted version is: > Apache-Coyote/1.1 > *Risk * > This information might help an attacker gain a greater > understanding of the systems in use and potentially develop further > attacks targeted at the specific version of Apache. > > ***Response * > > Not a vulnerability in Apache Tomcat. Every currently supported version > of Apache Tomcat includes that information in the header. All it tells > an attacker is that you are running Apache Tomcat. > > If you really want to change it, a configuration option to do that is > available on the connector. > > 2. The Character Set was not set. > The Character set (Charset) was not explicitly set by the server. > * Risk* > There is a risk that characters in content are incorrectly > interpreted by the server. Lack of charset can cause the browser to > guess the encoding type and this could lead to Cross-site Scripting by > encoding the payload in > encoding types like UTF-7. > > * Response* > > Not a vulnerability in Apache Tomcat. RFC2616 requires clients to treat > responses without a character encoding as being encoding with > ISO-8859-1. Clients that try to guess the charset are in breach of > RFC2616. Further that they might do so in an unsafe manner is a security > vulnerability in those clients and should be reported to the appropriate > vendor. > > If the vendor(s) of the vulnerable client(s) are unwilling to fix this > vulnerability there are multiple ways that it could be mitigated. For > example, with a filter that always sets the character set. > > > Kindly send documents that will assist us in resolving these > vulnerabilities I think Mark's responses above tell you what you need to know in order to resolve these. Just look in the documentation for the implementation details. D - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Audit Exceptions on Apache
On 9/18/2013 5:04 AM, Joy Obba wrote: Hello Team, Some security issues were raised by our audit team and these issues were forwarded to secur...@apache.org. We got a response from Mark Thomas from the Security team Theses issues are listed below: 1. Banner Disclosure We observed that the GTApplication web server disclosed the Apache Coyote version in its HTTP response. The extracted version is: Apache-Coyote/1.1 *Risk * This information might help an attacker gain a greater understanding of the systems in use and potentially develop further attacks targeted at the specific version of Apache. ***Response * Not a vulnerability in Apache Tomcat. Every currently supported version of Apache Tomcat includes that information in the header. All it tells an attacker is that you are running Apache Tomcat. If you really want to change it, a configuration option to do that is available on the connector. 2. The Character Set was not set. The Character set (Charset) was not explicitly set by the server. * Risk* There is a risk that characters in content are incorrectly interpreted by the server. Lack of charset can cause the browser to guess the encoding type and this could lead to Cross-site Scripting by encoding the payload in encoding types like UTF-7. * Response* Not a vulnerability in Apache Tomcat. RFC2616 requires clients to treat responses without a character encoding as being encoding with ISO-8859-1. Clients that try to guess the charset are in breach of RFC2616. Further that they might do so in an unsafe manner is a security vulnerability in those clients and should be reported to the appropriate vendor. If the vendor(s) of the vulnerable client(s) are unwilling to fix this vulnerability there are multiple ways that it could be mitigated. For example, with a filter that always sets the character set. Kindly send documents that will assist us in resolving these vulnerabilities I think Mark's responses above tell you what you need to know in order to resolve these. Just look in the documentation for the implementation details. D - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Audit Exceptions on Apache
Hello Team, Some security issues were raised by our audit team and these issues were forwarded to secur...@apache.org. We got a response from Mark Thomas from the Security team Theses issues are listed below: 1. Banner Disclosure We observed that the GTApplication web server disclosed the Apache Coyote version in its HTTP response. The extracted version is: Apache-Coyote/1.1 Risk This information might help an attacker gain a greater understanding of the systems in use and potentially develop further attacks targeted at the specific version of Apache. Response Not a vulnerability in Apache Tomcat. Every currently supported version of Apache Tomcat includes that information in the header. All it tells an attacker is that you are running Apache Tomcat. If you really want to change it, a configuration option to do that is available on the connector. 2. The Character Set was not set. The Character set (Charset) was not explicitly set by the server. Risk There is a risk that characters in content are incorrectly interpreted by the server. Lack of charset can cause the browser to guess the encoding type and this could lead to Cross-site Scripting by encoding the payload in encoding types like UTF-7. Response Not a vulnerability in Apache Tomcat. RFC2616 requires clients to treat responses without a character encoding as being encoding with ISO-8859-1. Clients that try to guess the charset are in breach of RFC2616. Further that they might do so in an unsafe manner is a security vulnerability in those clients and should be reported to the appropriate vendor. If the vendor(s) of the vulnerable client(s) are unwilling to fix this vulnerability there are multiple ways that it could be mitigated. For example, with a filter that always sets the character set. Kindly send documents that will assist us in resolving these vulnerabilities Kind Regards
Re: Problems with Clustering / Session Replication
Thanks Daniel. On Tue, Sep 17, 2013 at 5:30 PM, Daniel Mikusa wrote: > > Tried a quick two node setup on my Mac w/out HTTPD and it worked OK. Go > to one Tomcat instance's port in chrome, it increments the counter in my > app. Refresh a few times. Open a second tab, go to the second Tomcat > instance's port. The counter picks up where it left off and continues > incrementing. Flipping back and forth between tabs / servers works fine. > > Here's the cluster config that I used in case it helps. > > > className="org.apache.catalina.ha.tcp.SimpleTcpCluster"> > className="org.apache.catalina.ha.session.DeltaManager" > expireSessionsOnShutdown="false" > notifyListenersOnReplication="true"/> > className="org.apache.catalina.tribes.group.GroupChannel"> > > className="org.apache.catalina.tribes.membership.McastService" > dropTime="3000" > frequency="500" > port="45564"/> >autoBind="100" > > className="org.apache.catalina.tribes.transport.nio.NioReceiver" > maxThreads="6" > port="4000" > selectorTimeout="5000"/> > className="org.apache.catalina.tribes.transport.ReplicationTransmitter"> > className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/> > > className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/> > className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/> > > className="org.apache.catalina.ha.tcp.ReplicationValve" >filter=""/> > className="org.apache.catalina.ha.session.JvmRouteBinderValve"/> > className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/> > className="org.apache.catalina.ha.session.ClusterSessionListener"/> > > Just tried this with the same results. My test that replication is behaving is accessing my webapp on the two ports and monitoring the session counter and list in the tomcat manager, and as I said before, I can only see the sessions created on the server attached to the manager instance. Is that a reasonable test? With the clustering config pretty well ruled out as the culprit, maybe my webapp is not dealing with sessions appropriately? Would you mind sending me your counter test app? Beyond that, have you tried increasing the log levels? I found conflicting information about enabling logging. What I had previously was org.apache.catalina.tribes.level = FINE org.apache.catalina.tribes.MESSAGES = FINE in logging.properties, which was reporting the FINE log statements in my original post. I just added some more: org.apache.catalina.ha.level = FINE org.apache.catalina.ha.session.level = FINE org.apache.catalina.ha.session.DeltaManager.level = FINE org.apache.catalina.ha.tcp.level = FINE org.apache.catalina.ha.tcp.level = FINE org.apache.catalina.ha.tcp.ReplicationValve.level = FINE org.apache.catalina.ha.session.ClusterSessionListener.level = FINE org.apache.catalina.ha.session.JvmRouteSessionIDBinterListener.level = FINE And I still don't see any messages when interacting with the webapp in the browser. Are there any other classes I should be logging? Thanks, Nick
Re: [Tomcat-7.0.42/JmxRemoteLifecycleListener] rmiBindAddress vs localhost
Chris, 2013/9/12 > > > Marcin, > > On 9/11/13 2:29 PM, Marcin Domański wrote: > > Hi there! I am trying to setup a Tomcat instance using only > > specific address for all communications. This is convenient for us > > from the point of IPsec. I was able to succeed in http, https, ajp, > > etc. but for JMX I still cannot get it right. For this example, > > let's assume, my desired address is 127.2.0.1. Currently my > > configuration is as follows: > > > > - > className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener" > > rmiRegistryPortPlatform="9012" rmiServerPortPlatform="9013" > > useLocalPorts="true" /> > > > > > > Which allows to connect to the server at > > "service:jmx:rmi:///jndi/rmi:// 127.2.0.1:9012/jmxrmi but also > > localhost (means I cannot run second instance with different IP) > > Hmm. I would have expected "useLocalPorts" to bind only to 127.0.0.1 > (i.e. localhost). What does netstat tell you under this configuration? > I see open ports to 127.2.0.1:9012 whenever I have rmiBindAddress set and applied patch in JmxRemoteLifecycleListener to use rmiBindAddress instead of localhost around line 304, otherwise I get exception whenever I use rmiBindAddress=127.2.0.1 and no ports are open. Netstat with patch and rmiBindAddress=127.0.2.1 and useLocalPorts=false: TCP 127.0.2.1:9012 XXX:0LISTENING TCP 127.0.2.1:9013 XXX:0LISTENING Netstat with patch and rmiBindAddress=127.0.2.1 and useLocalPorts=true: TCP 127.0.2.1:9012 XXX:0LISTENING TCP 127.0.2.1:9013 XXX:0LISTENING Seems that it connects differently because I see it using localhost for connections to port 9013 and 127.0.2.1 for 9012 (remote address in netstat) > > On the other hand,when I try following: > > > > - > className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener" > > rmiRegistryPortPlatform="9012" rmiServerPortPlatform="9013" > > useLocalPorts="true" rmiBindAddress="127.2.0.1"/> > > > > On Windows machine I get a network error basically saying there is > > no server configured at localhost in > > JmxRemoteLifecycleListener:304. > > You get this on startup? Post the full stack trace, please. > Yes, it is a startup of Tomcat itself, not my J2EE application. You can try it yourself. Stack is as follows: java.io.IOException: Cannot bind to URL [rmi://localhost:9012/jmxrmi]: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: localhost; nested exception is: java.net.ConnectException: Connection refused: connect] at javax.management.remote.rmi.RMIConnectorServer.newIOException(RMIConnectorServer.java:827) at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:432) at org.apache.catalina.mbeans.JmxRemoteLifecycleListener.createServer(JmxRemoteLifecycleListener.java:304) at org.apache.catalina.mbeans.JmxRemoteLifecycleListener.lifecycleEvent(JmxRemoteLifecycleListener.java:258) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:402) at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:347) at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:725) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.startup.Catalina.start(Catalina.java:691) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:322) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:456) Caused by: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: localhost; nested exception is: java.net.ConnectException: Connection refused: connect] at com.sun.jndi.rmi.registry.RegistryContext.bind(RegistryContext.java:143) at com.sun.jndi.toolkit.url.GenericURLContext.bind(GenericURLContext.java:226) at javax.naming.InitialContext.bind(InitialContext.java:419) at javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:644) at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:427) ... 15 more Caused by: java.rmi.ConnectException: Connection refused to host: localhost; nested exception is: java.net.ConnectException: Connection refused: connect at sun.rmi.transport.tcp.TCPEndpo
Re: Apache Tomcat 8.0.0-RC2
On 18/09/2013 09:05, Mark Thomas wrote: > On 18/09/2013 01:42, jieryn wrote: >> I'm trying out the new Apache Tomcat 8.0.0-RC2 with some existing web >> applications that work fine under Apache Tomcat 8.0.0-RC1. >> >> I am now seeing literally thousands of warning messages at start up time: >> >> 17-Sep-2013 20:19:40.346 WARNING [hostname-startStop-1] >> org.apache.catalina.webresources.Cache.getResource Unable to add the >> resource at [{0}] to the cache because there was insufficient free >> space available after evicting expired cache entries - consider >> increasing the maximum size of the cache >> >> (Note that the [{0}] is the actual text, which suggests a secondary problem.) > > I'll fix that. > >> Are these messages the result of the Context configuration elements >> cacheMaxSize, cacheObjectsMaxSize, cacheTTL, and cachingAllowed? > > Yes. > >> Would it be better to not omit these messages at catalina start up if they >> are for static resources which have been requested by clients? > > No. The cache is used for any web application resource. I suspect the > problem is that it is currently caching things that shouldn't be cached > such as class files. I'll take a look. I've just tried 8.0.0-RC2 with Jira (as an example of a fairly large app that I know should work without any external plumbing). I've fixed the broken message and fixed a TODO for excluding some resources from the cache. Anything loaded by the class loader is now excluded as the class loader has its own cache (which itself excludes classes). Those fixes will be in the next RC that hopefully will be out rather sooner than RC2 was but that depends on the problems folks find and how long they take to fix. > Note that apart from filling the logs, there shouldn't be any problem. I didn't see anything to change this assessment. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot access webapp outside the server box using a public domain name
> How exactly does it fail ? Sorry, it failed with error message stating that it cannot connect to the myweb.com:80; > nslookup disregards the local "hosts" file > What's with the other nodes' local "hosts" file ? These lines gave me a brain jolt. It's my mistake, as i mapped myweb.com to 127.0.0.1 locally on my laptop, which is why it doesnt use dns to get the public ip. Now that i commented the local mapping in my etc/hosts, everything works great ! Thank you so much for your help ! Warm regards from Jakarta, Albert Kam On Wed, Sep 18, 2013 at 4:50 PM, André Warnier wrote: > Albert Kam wrote: > >> I have a case where accessing the webapp within the server box is fine, >> but accessing the webapp from outside the server box using the domain name >> is problematic, but not so using the public ip address, which is >> accessible. >> >> The content of the webapp is just a single index.html, so no JSPs, no >> classes are involved. >> >> - On my web server, which is set for the public domain myweb.com, >> curl http://myweb.com works >> curl http:// also works >> note : i registered the domain from the domain robot >> >> - On external nodes (not on the web server), i tried to access >> curl http://myweb.com fails >> > > How exactly does it fail ? Doesn't curl have some "verbose" option to > give you the exact failure reason ? > > >But : curl http:// works >> >> - Both on the web server and external nodes, >> nslookup myweb.com works, and returns the public ip address correctly >> > > Just for info : nslookup disregards the local "hosts" file.. > > > >> - I have even disabled ipv6 in my /etc/hosts and domain mapping >> So my current host file is very simple : >> 127.0.0.1 localhost >> > > Yes, but this concerns only your local host, which was already working > fine, as per your indications above. > What's with the other nodes' local "hosts" file ? > > On the Tomcat host, can you run the following command and paste the output > here ? > > ifconfig -a > > > > > > > >> - Here my output of version.sh >> Using CATALINA_BASE: /usr/share/tomcat7 >> Using CATALINA_HOME: /usr/share/tomcat7 >> Using CATALINA_TMPDIR: /usr/share/tomcat7/temp >> Using JRE_HOME:/usr/lib/jvm/java-7-oracle >> Using CLASSPATH: >> /usr/share/tomcat7/bin/**bootstrap.jar:/usr/share/** >> tomcat7/bin/tomcat-juli.jar >> Server version: Apache Tomcat/7.0.28 >> Server built: Dec 8 2012 06:51:43 >> Server number: 7.0.28.0 >> OS Name:Linux >> OS Version: 3.2.0-4-amd64 >> Architecture: amd64 >> JVM Version:1.7.0_25-b15 >> JVM Vendor: Oracle Corporation >> >> - Here's my server.xml >> >> >> >> >> > className="org.apache.**catalina.core.**JreMemoryLeakPreventionListene**r" >> /> >> > className="org.apache.**catalina.mbeans.**GlobalResourcesLifecycleListen* >> *er" /> >> > className="org.apache.**catalina.core.**ThreadLocalLeakPreventionListe**ner" >> /> >> >> >> >connectionTimeout="2" >>URIEncoding="UTF-8" >>redirectPort="8443" address="" /> >> >> >> > unpackWARs="true" autoDeploy="true"> >> myweb.com >> > directory="logs" >>prefix="localhost_access_log." suffix=".txt" >>pattern="%h %l %u %t "%r" %s %b" /> >> >> >> >> >> >> - Here's my ifconfig : >> root@Debian-70-wheezy-64-**minimal:/home/moonblade# ifconfig >> eth0 Link encap:Ethernet HWaddr d4:3d:7e:d8:ba:27 >> inet addr: Bcast: >> Mask:255.255.255.224 >> inet6 addr: /64 Scope:Link >> inet6 addr: **/64 Scope:Global >> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >> RX packets:290094 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:169056 errors:0 dropped:0 overruns:0 carrier:0 >> collisions:0 txqueuelen:1000 >> RX bytes:241176295 (230.0 MiB) TX bytes:27580533 (26.3 MiB) >> Interrupt:43 Base address:0x6000 >> >> loLink encap:Local Loopback >> inet addr:127.0.0.1 Mask:255.0.0.0 >> inet6 addr: ::1/128 Scope:Host >> UP LOOPBACK RUNNING MTU:16436 Metric:1 >> RX packets:192 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:192 errors:0 dropped:0 overruns:0 carrier:0 >> collisions:0 txqueuelen:0 >> RX bytes:26625 (26.0 KiB) TX bytes:26625 (26.0 KiB) >> >> - no firewall, as the iptables are still empty : >> root@Debian-70-wheezy-64-**minimal:/home/moonblade# iptables -L -n >> Chain INPUT (policy ACCEPT) >> target prot opt source destination >> >> Chain FORWARD (policy ACCEPT) >> target prot opt source destination >> >> Chain OUTPUT (policy ACCEPT) >> target prot opt source destination >> >> - my system >> Linux Debian-70-wheezy-64-minimal 3.2.0-4-amd64 #1 SMP Debian >> 3.2.46-1+deb7u1 x86_64 GNU/Linux >> >> Am i missing something in my server.xml ? >> >> >> > > --**-
Re: Cannot access webapp outside the server box using a public domain name
Albert Kam wrote: I have a case where accessing the webapp within the server box is fine, but accessing the webapp from outside the server box using the domain name is problematic, but not so using the public ip address, which is accessible. The content of the webapp is just a single index.html, so no JSPs, no classes are involved. - On my web server, which is set for the public domain myweb.com, curl http://myweb.com works curl http:// also works note : i registered the domain from the domain robot - On external nodes (not on the web server), i tried to access curl http://myweb.com fails How exactly does it fail ? Doesn't curl have some "verbose" option to give you the exact failure reason ? But : curl http:// works - Both on the web server and external nodes, nslookup myweb.com works, and returns the public ip address correctly Just for info : nslookup disregards the local "hosts" file.. - I have even disabled ipv6 in my /etc/hosts and domain mapping So my current host file is very simple : 127.0.0.1 localhost Yes, but this concerns only your local host, which was already working fine, as per your indications above. What's with the other nodes' local "hosts" file ? On the Tomcat host, can you run the following command and paste the output here ? ifconfig -a - Here my output of version.sh Using CATALINA_BASE: /usr/share/tomcat7 Using CATALINA_HOME: /usr/share/tomcat7 Using CATALINA_TMPDIR: /usr/share/tomcat7/temp Using JRE_HOME:/usr/lib/jvm/java-7-oracle Using CLASSPATH: /usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-juli.jar Server version: Apache Tomcat/7.0.28 Server built: Dec 8 2012 06:51:43 Server number: 7.0.28.0 OS Name:Linux OS Version: 3.2.0-4-amd64 Architecture: amd64 JVM Version:1.7.0_25-b15 JVM Vendor: Oracle Corporation - Here's my server.xml myweb.com - Here's my ifconfig : root@Debian-70-wheezy-64-minimal:/home/moonblade# ifconfig eth0 Link encap:Ethernet HWaddr d4:3d:7e:d8:ba:27 inet addr: Bcast: Mask:255.255.255.224 inet6 addr: /64 Scope:Link inet6 addr: /64 Scope:Global UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:290094 errors:0 dropped:0 overruns:0 frame:0 TX packets:169056 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:241176295 (230.0 MiB) TX bytes:27580533 (26.3 MiB) Interrupt:43 Base address:0x6000 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:192 errors:0 dropped:0 overruns:0 frame:0 TX packets:192 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:26625 (26.0 KiB) TX bytes:26625 (26.0 KiB) - no firewall, as the iptables are still empty : root@Debian-70-wheezy-64-minimal:/home/moonblade# iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination - my system Linux Debian-70-wheezy-64-minimal 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1+deb7u1 x86_64 GNU/Linux Am i missing something in my server.xml ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: WebSocket message size limits
On 18/09/2013 06:19, Igor Urisman wrote: > Dear All, > > I am looking for help in understanding why the size of the inbound > WebSocket message is limited to 125 bytes. It isn't, at least not by Tomcat. > I realize that this may not > even be the right place for my question, but am still hoping for a clue. > > From looking at the RFC 6455, Sec. 5.2 Base Framing Protocol, I am making > two conclusions: > > 1. There's nothing in it to suggest a payload length asymmetry between > inbound and outbound messages. Yet, although I am able to send very large > messages to the browser, an attempt to send anything over 125 bytes results > in error and a connection shutdown. (I tried FF and Chrome on a Mac). > > 2. It's easy to see from the wire protocol why 125 is the simplest payload > length but other sizes up to unsigned 64 bit int are supported. So, > browser's failure to transmit more than 125 bits indicates both, the most > restrictive payload size AND lack of support for fragmented messages. > > The error that FF gives reads "The decoded text message was too big for the > output buffer and the endpoint does not support partial messages" which to > me reads like they are saying that Tomcat did not indicate during handshake > that it accepts multi-part messages. True? False. There is nothing in the handshake that allows one end not to support multi-part messages nor to limit the maximum message length. That looks like a client side issue to me. Maybe you need to make the client side output buffer bigger. Tomcat's web socket support (client and server) has been tested with the Autobahn testsuite that includes tests with significantly larger messages than 125 bytes both as single frames and as multiple frames. > > I can't speak for others, but for my project 125 bytes is unacceptably > small. So, fundamentally what I need to know is this: do I need to > implement my own fragmenting or am I missing something? You are missing something. No idea what since you haven't provided any details of your client side implementation. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache Tomcat 8.0.0-RC2
On 18/09/2013 01:42, jieryn wrote: > I'm trying out the new Apache Tomcat 8.0.0-RC2 with some existing web > applications that work fine under Apache Tomcat 8.0.0-RC1. > > I am now seeing literally thousands of warning messages at start up time: > > 17-Sep-2013 20:19:40.346 WARNING [hostname-startStop-1] > org.apache.catalina.webresources.Cache.getResource Unable to add the > resource at [{0}] to the cache because there was insufficient free > space available after evicting expired cache entries - consider > increasing the maximum size of the cache > > (Note that the [{0}] is the actual text, which suggests a secondary problem.) I'll fix that. > Are these messages the result of the Context configuration elements > cacheMaxSize, cacheObjectsMaxSize, cacheTTL, and cachingAllowed? Yes. > Would it be better to not omit these messages at catalina start up if they > are for static resources which have been requested by clients? No. The cache is used for any web application resource. I suspect the problem is that it is currently caching things that shouldn't be cached such as class files. I'll take a look. Note that apart from filling the logs, there shouldn't be any problem. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Cannot access webapp outside the server box using a public domain name
I have a case where accessing the webapp within the server box is fine, but accessing the webapp from outside the server box using the domain name is problematic, but not so using the public ip address, which is accessible. The content of the webapp is just a single index.html, so no JSPs, no classes are involved. - On my web server, which is set for the public domain myweb.com, curl http://myweb.com works curl http:// also works note : i registered the domain from the domain robot - On external nodes (not on the web server), i tried to access curl http://myweb.com fails But : curl http:// works - Both on the web server and external nodes, nslookup myweb.com works, and returns the public ip address correctly - I have even disabled ipv6 in my /etc/hosts and domain mapping So my current host file is very simple : 127.0.0.1 localhost - Here my output of version.sh Using CATALINA_BASE: /usr/share/tomcat7 Using CATALINA_HOME: /usr/share/tomcat7 Using CATALINA_TMPDIR: /usr/share/tomcat7/temp Using JRE_HOME:/usr/lib/jvm/java-7-oracle Using CLASSPATH: /usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-juli.jar Server version: Apache Tomcat/7.0.28 Server built: Dec 8 2012 06:51:43 Server number: 7.0.28.0 OS Name:Linux OS Version: 3.2.0-4-amd64 Architecture: amd64 JVM Version:1.7.0_25-b15 JVM Vendor: Oracle Corporation - Here's my server.xml myweb.com - Here's my ifconfig : root@Debian-70-wheezy-64-minimal:/home/moonblade# ifconfig eth0 Link encap:Ethernet HWaddr d4:3d:7e:d8:ba:27 inet addr: Bcast: Mask:255.255.255.224 inet6 addr: /64 Scope:Link inet6 addr: /64 Scope:Global UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:290094 errors:0 dropped:0 overruns:0 frame:0 TX packets:169056 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:241176295 (230.0 MiB) TX bytes:27580533 (26.3 MiB) Interrupt:43 Base address:0x6000 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:192 errors:0 dropped:0 overruns:0 frame:0 TX packets:192 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:26625 (26.0 KiB) TX bytes:26625 (26.0 KiB) - no firewall, as the iptables are still empty : root@Debian-70-wheezy-64-minimal:/home/moonblade# iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination - my system Linux Debian-70-wheezy-64-minimal 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1+deb7u1 x86_64 GNU/Linux Am i missing something in my server.xml ? -- Do not pursue the past. Do not lose yourself in the future. The past no longer is. The future has not yet come. Looking deeply at life as it is in the very here and now, the practitioner dwells in stability and freedom. (Thich Nhat Hanh)