Re: compiling tomcat6020 from source on modern amd64-bit linux

2009-12-12 Thread Zacheusz Siedlecki
Don't compile jar files.  If you prefer, you may compile native connectors.
Regards,
Zacheusz

On Sun, Dec 13, 2009 at 3:54 AM, Caldarale, Charles R
 wrote:
>> From: lux-integ [mailto:lux-in...@btconnect.com]
>> Subject: compiling tomcat6020 from source on modern amd64-bit linux
>>
>> I am attempting to compile tomcat-6.0.20 on a linux-box
>
> Why?  Tomcat is pure Java, so it will run on any platform with a JVM.  
> Recompilation is only needed if you're applying local patches.
>
>> I would be grateful for some advce on the above and/or on
>> the  amount of memory required to compile tomcat-6.0.20 on
>> a modern linux machine.
>
> Very strange - I have no problem compiling Tomcat 6.0.20 on a 64-bit system 
> using the default heap settings (it's Windows, not Linux, but that shouldn't 
> make a difference for the heap).  Monitoring the build with JConsole shows 
> that the heap never grows over 250 MB, even though the default max is ~850 MB.
>
> Perhaps you don't have enough RAM plus swap space for the total space 
> required by all processes on the machine.
>
>  - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
> MATERIAL and is thus for use only by the intended recipient. If you received 
> this in error, please contact the sender and delete the e-mail and its 
> attachments from all computers.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



RE: compiling tomcat6020 from source on modern amd64-bit linux

2009-12-12 Thread Caldarale, Charles R
> From: lux-integ [mailto:lux-in...@btconnect.com]
> Subject: compiling tomcat6020 from source on modern amd64-bit linux
> 
> I am attempting to compile tomcat-6.0.20 on a linux-box

Why?  Tomcat is pure Java, so it will run on any platform with a JVM.  
Recompilation is only needed if you're applying local patches.

> I would be grateful for some advce on the above and/or on 
> the  amount of memory required to compile tomcat-6.0.20 on
> a modern linux machine.

Very strange - I have no problem compiling Tomcat 6.0.20 on a 64-bit system 
using the default heap settings (it's Windows, not Linux, but that shouldn't 
make a difference for the heap).  Monitoring the build with JConsole shows that 
the heap never grows over 250 MB, even though the default max is ~850 MB.

Perhaps you don't have enough RAM plus swap space for the total space required 
by all processes on the machine.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



compiling tomcat6020 from source on modern amd64-bit linux

2009-12-12 Thread lux-integ
Greetings 

I am new to this list.  I last played with tomcat ~7 years ago(version 3).  
I am attempting to compile tomcat-6.0.20 on a linux-box 
 (it runs pure-(AMD64) 64-bit CLFS linux  (kernel 2.6.31.6, gcc4.4.2, 
glibc2.10.2)  The box has  an AMD Sempron CPU  and 2 Gbytes of RAM,   
ant-1.7.1 and java-binary downloaded from sun (jdk-6u17-linux-x64.bin)  The 
first part of the build is successful then I get an "out of memory error"  as 
shown below

###
compile:
[javac] Compiling 1052 source files 
to 
/home/forker/tomcat-test/sources-tomcat-test/apache-tomcat-6.0.20-src/output/classes

   
[javac] 
 
[javac] 
 
[javac] The system is out of resources. 
 
[javac] Consult the following stack trace for details.  
 
[javac] java.lang.OutOfMemoryError: Java heap space 
 
[javac] at 
java.util.jar.Manifest$FastInputStream.(Manifest.java:315)
  
[javac] at 
java.util.jar.Manifest$FastInputStream.(Manifest.java:310)
  
[javac] at java.util.jar.Manifest.read(Manifest.java:178)   
 
[javac] at java.util.jar.Manifest.(Manifest.java:52)  
 
[javac] at 
java.util.jar.JarFile.getManifestFromReference(JarFile.java:165)
  
[javac] at java.util.jar.JarFile.getManifest(JarFile.java:146)  
 
[javac] at 
sun.misc.URLClassPath$JarLoader$2.getManifest(URLClassPath.java:693)
  
[javac] at 
java.net.URLClassLoader.defineClass(URLClassLoader.java:221)
  
[javac] at java.net.URLClassLoader.access$000(URLClassLoader.java:56)   
 
[javac] at java.net.URLClassLoader$1.run(URLClassLoader.java:195)   
 
[javac] at java.security.AccessController.doPrivileged(Native Method)   
 
[javac] at java.net.URLClassLoader.findClass(URLClassLoader.java:188)   
 
[javac] at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
 
[javac] at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
 
[javac] at 
java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)   
  
[javac] at 
com.sun.tools.javac.comp.Attr.isStaticEnumField(Attr.java:2223) 
  
[javac] at 
com.sun.tools.javac.comp.Attr.checkEnumInitializer(Attr.java:2198)  
  
[javac] at com.sun.tools.javac.comp.Attr.checkInit(Attr.java:2173)  
 
[javac] at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:1852)
 
[javac] at 
com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1522)  
  
[javac] at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:360)  
 
[javac] at com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:377)  
 
[javac] at   
com.sun.tools.javac.comp.Annotate.enterAttributeValue(Annotate.java:228)
  
[javac] at 
com.sun.tools.javac.comp.Annotate.enterAttributeValue(Annotate.java:219)
  
[javac] at 
com.sun.tools.javac.comp.Annotate.enterAnnotation(Annotate.java:167)
[javac] at 
com.sun.tools.javac.comp.MemberEnter.enterAnnotations(MemberEnter.java:743)
[javac] at com.sun.tools.javac.comp.MemberEnter.access$300
(MemberEnter.java:42)
[javac] at 
com.sun.tools.javac.comp.MemberEnter$5.enterAnnotation(MemberEnter.java:711)
[javac] at com.sun.tools.javac.comp.Annotate.flush(Annotate.java:95)
[javac] at 
com.sun.tools.javac.comp.Annotate.enterDone(Annotate.java:87)
[javac] at com.sun.tools.javac.comp.Enter.complete(Enter.java:472)
[javac] at com.sun.tools.javac.comp.Enter.main(Enter.java:429)

BUILD FAILED


##

I would be grateful   for some advce on the above and/or on the  amount of 
memory required to compile tomcat-6.0.20 on a modern linux machine.

yours sincerely
lux-integ

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



How to JSF 2.0 (Mojarra-2.0.2) with Facelets on Tomcat?

2009-12-12 Thread Zacheusz Siedlecki
Can I use JSF 2.0 (Mojarra-2.0.2) with Facelets on Tomcat? With Jetty
and Glassfish Mojarra works fine. With Tomcat I get facelets
exception. For example java.io.FileNotFoundException: /welcome.xhtml
Not Found in ExternalContext as a Resource

com.sun.faces.facelets.impl.DefaultFaceletFactory.resolveURL(DefaultFaceletFactory.java:187)
Does anybody use Mojarra 2 with Tomcat?
Regards,
   Zacheusz

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Minor Doc Bug on website

2009-12-12 Thread Mark Thomas
On 11/12/2009 22:54, Dan Armbrust wrote:
> On the page: http://tomcat.apache.org/tomcat-6.0-doc/jasper-howto.html
> 
> It talks about:
> 
> "genStringAsCharArray - Should text strings be generated as char
> arrays, to improve performance in some cases? Default false."
> 
> In the web.xml of Tomcat 6.0.20, the parameter name is:
> 
> "genStrAsCharArray   Should text strings be generated as char arrays,
> to improve performance in some cases?  [false]  "
> 
> Perhaps it accepts either parameter name?

Internally genStringAsCharArray  is used. However, the servlet init
parameter is genStrAsCharArray.

I've made it consistent for Tomcat 7 and I'll fix the docs for 6.0.x and
5.5.x. You won't see the changes in the docs until after the next
release of each.

Mark



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: New to Tomcat -- SSL

2009-12-12 Thread Adria Stembridge
Success.

iptables -save &  iptables-save weren't saving the changes.  Issuing *service
itptables save* did the trick.Tomcat is now running over ports 80 & 443.

Thanks for everyone's assistance.

a


On Sat, Dec 12, 2009 at 1:36 PM, Caldarale, Charles R <
chuck.caldar...@unisys.com> wrote:

> > From: Adria Stembridge [mailto:adrya.stembri...@gmail.com]
> > Subject: Re: New to Tomcat -- SSL
> >
> > Tomcat works under 8080 and 8443 currently.
> >
> > Isn't there a way to forward 8443 to 443 with iptables?
>
> Yes, that's frequently done.  From the Tomcat FAQ:
>
> - Another way is to use Iptables to redirect Port 80 and 443 to user ports
> (>1024)
> * /sbin/iptables -A FORWARD -p tcp --destination-port 443 -j ACCEPT
> * /sbin/iptables -t nat -A PREROUTING -j REDIRECT -p tcp --destination-port
> 443 --to-ports 8443
> * /sbin/iptables -A FORWARD -p tcp --destination-port 80 -j ACCEPT
> * /sbin/iptables -t nat -A PREROUTING -j REDIRECT -p tcp --destination-port
> 80 --to-ports 8080
> /sbin/iptables-save or /etc/init.d/iptables save
>
> Consult the iptables man pages for details.
>
>  - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you received
> this in error, please contact the sender and delete the e-mail and its
> attachments from all computers.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


RE: New to Tomcat -- SSL

2009-12-12 Thread Caldarale, Charles R
> From: Adria Stembridge [mailto:adrya.stembri...@gmail.com]
> Subject: Re: New to Tomcat -- SSL
> 
> I compiled jsvc per tomcat 5.5 documentation.
> 
> [Linux] service tomcat5 stop
> [Linux] ./bin/jsvc -Djava.endorsed.dirs=./common/endorsed -cp
> ./bin/bootstrap.jar -outfile ./logs/catalina.out -errfile
> ./logs/catalina.err org.apache.catalina.startup.Bootstrap

Looks like you didn't start jsvc under the root userid.  Also note this from 
the instructions:

"jsvc has other useful parameters, such as -user which causes it to switch to 
another user after the daemon initialization is complete. This allows, for 
example, running Tomcat as a non privileged user while still being able to use 
privileged ports."

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



RE: New to Tomcat -- SSL

2009-12-12 Thread Caldarale, Charles R
> From: Adria Stembridge [mailto:adrya.stembri...@gmail.com]
> Subject: Re: New to Tomcat -- SSL
> 
> Tomcat works under 8080 and 8443 currently.
> 
> Isn't there a way to forward 8443 to 443 with iptables?

Yes, that's frequently done.  From the Tomcat FAQ:

- Another way is to use Iptables to redirect Port 80 and 443 to user ports 
(>1024)
* /sbin/iptables -A FORWARD -p tcp --destination-port 443 -j ACCEPT
* /sbin/iptables -t nat -A PREROUTING -j REDIRECT -p tcp --destination-port 443 
--to-ports 8443
* /sbin/iptables -A FORWARD -p tcp --destination-port 80 -j ACCEPT
* /sbin/iptables -t nat -A PREROUTING -j REDIRECT -p tcp --destination-port 80 
--to-ports 8080
/sbin/iptables-save or /etc/init.d/iptables save

Consult the iptables man pages for details.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: New to Tomcat -- SSL

2009-12-12 Thread Adria Stembridge
I've been at this for two days.   Learning a lot, but this is production and
needs to get back to service.   Is there another way, other than
revoking/requesting a new SSL certificate and using apache mod_jk?

Tomcat works under 8080 and 8443 currently.

Isn't there a way to forward 8443 to 443 with iptables?


Re: New to Tomcat -- SSL

2009-12-12 Thread Adria Stembridge
> Linux/UNIX systems do not allow unprivileged userids to access ports <
> 1024.  Although you can run Tomcat under the root userid, this is not
> recommended for security reasons.  Instead, start Tomcat with jsvc:
> http://tomcat.apache.org/tomcat-6.0-doc/setup.html#Unix%20daemon
>
>  - Chuck
>

I compiled jsvc per tomcat 5.5 documentation.

[Linux] service tomcat5 stop
[Linux] ./bin/jsvc -Djava.endorsed.dirs=./common/endorsed -cp
./bin/bootstrap.jar -outfile ./logs/catalina.out -errfile
./logs/catalina.err org.apache.catalina.startup.Bootstrap

No errors at the prompt.   Checking catalina.out logfile:

Dec 12, 2009 1:25:50 PM org.apache.coyote.http11.Http11BaseProtocol start
SEVERE: Error starting endpoint
java.net.BindException: Permission denied:80
at
org.apache.tomcat.util.net.PoolTcpEndpoint.initEndpoint(PoolTcpEndpoint.java:298)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.startEndpoint(PoolTcpEndpoint.java:313)
at
org.apache.coyote.http11.Http11BaseProtocol.start(Http11BaseProtocol.java:151)
at org.apache.coyote.http11.Http11Protocol.start(Http11Protocol.java:76)
at org.apache.catalina.connector.Connector.start(Connector.java:1090)
at
org.apache.catalina.core.StandardService.start(StandardService.java:457)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:700)
at org.apache.catalina.startup.Catalina.start(Catalina.java:552)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:177)
Dec 12, 2009 1:25:50 PM org.apache.catalina.startup.Catalina start
SEVERE: Catalina.start:
LifecycleException:  service.getName(): "Catalina";  Protocol handler start
failed: java.net.BindException: Per
mission denied:80
at org.apache.catalina.connector.Connector.start(Connector.java:1097)
at
org.apache.catalina.core.StandardService.start(StandardService.java:457)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:700)
at org.apache.catalina.startup.Catalina.start(Catalina.java:552)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:177)
Dec 12, 2009 1:25:50 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 641 ms


RE: New to Tomcat -- SSL

2009-12-12 Thread Caldarale, Charles R
> From: Adria Stembridge [mailto:adrya.stembri...@gmail.com]
> Subject: Re: New to Tomcat -- SSL
> 
> SEVERE: Catalina.start:
> LifecycleException:  service.getName(): "Catalina";  Protocol handler
> start
> failed: java.net.BindException: *Permission denied:80*
> at
> org.apache.catalina.connector.Connector.start(Connector.java:1097)

Linux/UNIX systems do not allow unprivileged userids to access ports < 1024.  
Although you can run Tomcat under the root userid, this is not recommended for 
security reasons.  Instead, start Tomcat with jsvc:
http://tomcat.apache.org/tomcat-6.0-doc/setup.html#Unix%20daemon

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Seeking consultant

2009-12-12 Thread Adria Stembridge
Not sure if this is allowed -- I am interested in hiring someone to help
with port forwarding on a standalone instance of tomcat5.I've done
everything I know to do and have asked for help in the right place.  Please
email with rates.


Re: New to Tomcat -- SSL

2009-12-12 Thread Adria Stembridge
>
> Don't the Tomcat logs say anything helpful ?


Actually, yes...

SEVERE: Catalina.start:
LifecycleException:  service.getName(): "Catalina";  Protocol handler start
failed: java.net.BindException: *Permission denied:80*
at org.apache.catalina.connector.Connector.start(Connector.java:1097)
at
org.apache.catalina.core.StandardService.start(StandardService.java:457)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:700)
at org.apache.catalina.startup.Catalina.start(Catalina.java:552)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433)
Dec 11, 2009 5:21:20 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 643 ms

I'm approaching my wits end with this project.

*server.xml*:



  
  
  
  
  


  
  





  
  
  

  



*Scanning ports from a different system:*

[Linux]:~$ nmap -p80,443,8080,8443 my.domain.org

Starting Nmap 4.62 ( http://nmap.org ) at 2009-12-12 12:15 EST
Interesting ports on my.domain.org (1.1.1.1):
PORT STATE  SERVICE
80/tcp   open   http
443/tcp  open   https
8080/tcp closed http-proxy
8443/tcp closed https-alt

Nmap done: 1 IP address (1 host up) scanned in 0.071 seconds


*Iptables -L*
Chain INPUT (policy ACCEPT)
target prot opt source   destination
RH-Firewall-1-INPUT  all  --  anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source   destination
RH-Firewall-1-INPUT  all  --  anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination

Chain RH-Firewall-1-INPUT (2 references)
target prot opt source   destination
ACCEPT all  --  anywhere anywhere
ACCEPT icmp --  anywhere anywhereicmp any
ACCEPT esp  --  anywhere anywhere
ACCEPT ah   --  anywhere anywhere
ACCEPT udp  --  anywhere 224.0.0.251 udp dpt:mdns
ACCEPT udp  --  anywhere anywhereudp dpt:ipp
ACCEPT tcp  --  anywhere anywheretcp dpt:ipp
ACCEPT all  --  anywhere anywherestate
RELATED,ESTABLISHED
ACCEPT tcp  --  anywhere anywherestate NEW tcp
dpt:ssh
ACCEPT tcp  --  anywhere anywherestate NEW tcp
dpt:https
ACCEPT tcp  --  anywhere anywherestate NEW tcp
dpt:http
ACCEPT tcp  --  anywhere anywherestate NEW tcp
dpt:webcache
ACCEPT tcp  --  anywhere anywherestate NEW tcp
dpt:pcsync-https
ACCEPT tcp  --  anywhere anywherestate NEW tcp
dpt:ddi-tcp-1
REJECT all  --  anywhere anywherereject-with
icmp-host-prohibited

*netstat -tln
*
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address   Foreign Address
State
tcp0  0 0.0.0.0:33060.0.0.0:*
LISTEN
tcp0  0 0.0.0.0:111 0.0.0.0:*
LISTEN
tcp0  0 127.0.0.1:631   0.0.0.0:*
LISTEN
tcp0  0 127.0.0.1:250.0.0.0:*
LISTEN
tcp0  0 127.0.0.1:6011  0.0.0.0:*
LISTEN
tcp0  0 0.0.0.0:892 0.0.0.0:*
LISTEN
tcp0  0 0.0.0.0:70060.0.0.0:*
LISTEN
tcp0  0 :::127.0.0.1:8005   :::*
LISTEN
tcp0  0 :::80   :::*
LISTEN
tcp0  0 :::22   :::*
LISTEN
tcp0  0 ::1:6011:::*
LISTEN
tcp0  0 :::443  :::*
LISTEN
tcp0  0 :::7006 :::*
LISTEN


*iptables*
[Linux]# more /etc/sysconfig/iptables
# Firewall configuration written by system-config-securitylevel
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dpo

Re: Tomcat 6.0.16 + mod_jk 1.2.19 - request threads hanging up

2009-12-12 Thread Rainer Jung

On 12.12.2009 13:26, Alessandro Bahgat wrote:

On Fri, Dec 11, 2009 at 4:27 PM, Rainer Jung  wrote:

On 09.12.2009 12:18, Pid wrote:


It could be, but while you're upgrading you might consider upgrading
HTTPD to the best available version too, 2.0.52 release date: 1 Oct
2004. (That's 35 internet years ago.)


... and mod_jk 1.2.19 dates back to September 2006, so according to your
math 21 internet years ago. There were so many bugs fixed since then, that
you'll hardly find anyone that really tries to help debugging those old
versions. At least use a recent mod_jk and look at

http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html

for some important hints about configuration.


Thank you both for your advice. I'm pushing towards upgrading the
Apache+mod_jk stack as well.
Our last tests with the latest Tomcat and mod_jk still showed a lot of
CPU time being spent in sendbb methods, with some threads being stuck
in that method for long time.

We actually found out a lot of "unrecoverable error 200, request
failed" error messages in the mod_jk log (roughly around 1k per hour),
so I'm starting to wonder if there's any issue with the firewalls and
the network infrastructure. What would you think about that?

[Thu Dec 03 16:58:52 2009][31539:42688] [info]
service::jk_lb_worker.c (873): unrecoverable error 200, request
failed. Client failed in the middle of request, we can't recover to
another instance.
[Thu Dec 03 16:58:52 2009][31539:42688] [info]  jk_handler::mod_jk.c
(2056): Aborting connection for worker=applprod


The above two lines belong together, the next lines are something 
different. The pait [pid:tid} changed.


The above lines are logged, whenever there was a problem sending back 
gthe response from Apache to the client/browser. It may happen, if a 
user in the meatime clicked on something else or pressed the reload 
button. If you get it a lot, maybe your app is to slow, your users are 
to nervous, or indeed there might be a network problem. Occasional 
occurrences are normal.



[Thu Dec 03 16:58:53 2009][31612:42688] [info]
jk_open_socket::jk_connect.c (450): connect to XXX.XXX.XXX.XXX:8009
failed with errno=111
[Thu Dec 03 16:58:53 2009][31612:42688] [info]
ajp_connect_to_endpoint::jk_ajp_common.c (872): Failed opening socket
to (XXX.XXX.XXX.XXX:8009) with (errno=111)
[Thu Dec 03 16:58:53 2009][31612:42688] [info]
ajp_send_request::jk_ajp_common.c (1247): (applprod05) error
connecting to the backend server (errno=111)
[Thu Dec 03 16:58:53 2009][31612:42688] [info]
ajp_service::jk_ajp_common.c (1867): (applprod05) sending request to
tomcat failed,  recoverable operation attempt=1


errno 111 is "Connection refused", so either your Tomcat was down or 
something else blocked the connection.


Regards,

Rainer


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: mod_jk all endpoints are disconnected

2009-12-12 Thread Rainer Jung
It's only an info message, no problem per se. As long as there are no 
accompanying warn or error messages, you can ignore them.


Regards,

Rainer


On 12.12.2009 07:27, peter.shen wrote:


Hi brother
I meet the same problem , I want to know the reason and how fix it?
%-|

ke...@newsgroupstats.hk wrote:


Hi All,

My Apache 2.2 (win32) + Tomcat 6 are running very well in my production
environment but I am noticed that jk are sometime spend unexpected long
time to response. (4-5 seconds, it's too long. Those pages are very static
with no database connection, no file io).


Here is my environment:
Apache/2.2.6 (Win32) mod_ssl/2.2.6 OpenSSL/0.9.8e mod_jk/1.2.26
with AcceptEx() WinSock2 API disabed

Tomcat and Apache are in same server (Windows 2000 Server)

Here is my worker:

# Define 1 real worker using ajp13
worker.list=worker1

# Set properties for worker1 (ajp13)
worker.worker1.type=ajp13
worker.worker1.host=localhost
worker.worker1.port=8009
worker.worker1.socket_timeout=300
worker.worker1.socket_keepalive=True
worker.worker1.connection_pool_timeout=600

Here are what I found in my mod_jk.log:

[Mon Feb 04 10:50:12 2008] [3068:8252] [info] jk_ajp_common.c (1347):
(worker1) all endpoints are disconnected, detected by connect check (5),
cping (0), send (0)
[Mon Feb 04 10:51:46 2008] [3068:9592] [info] jk_ajp_common.c (1347):
(worker1) all endpoints are disconnected, detected by connect check (6),
cping (0), send (0)
[Mon Feb 04 10:52:47 2008] [3068:9804] [info] jk_ajp_common.c (1347):
(worker1) all endpoints are disconnected, detected by connect check (4),
cping (0), send (0)


// here is source code of jk_ajp_common.c
 /*
  * If we failed to reuse a connection, try to reconnect.
  */
 if (!IS_VALID_SOCKET(ae->sd)) {
 /* Could not steal any connection from an endpoint - backend is
disconnected */
 if (err_conn + err_cping + err_send>  0)
 jk_log(l, JK_LOG_INFO,
"(%s) all endpoints are disconnected, "
"detected by connect check (%d), cping (%d), send
(%d)",
ae->worker->name, err_conn, err_cping, err_send);
 else if (JK_IS_DEBUG_LEVEL(l))
 jk_log(l, JK_LOG_DEBUG,
"(%s) all endpoints are disconnected, "
"detected by connect check (%d), cping (%d), send
(%d)",
ae->worker->name, err_conn, err_cping, err_send);
 /* Connect to the backend.
  */
 }

Is it mean that my jk always fail to reuse existing jk connections? if
yes, why?

Any solution? It's not a big problem but It will affect my bechmark.

Regards,
Ken


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Strange characters seen in RR and Cd columns on jkserver-status page after upgrading modjk to .28

2009-12-12 Thread Rainer Jung

On 11.12.2009 18:32, gerhardus.geldenh...@gta-travel.com wrote:

Hi

We have upgraded our modjk from .26 to .28
using mod_jk-1.2.28-httpd-2.2.X.so obtained from
http://../tomcat-connectors/jk/binaries/linux/jk-1.2.28/x86_64/

We are running
Server version: Apache/2.2.3
Server built:   Nov 12 2008 10:40:14

CentOS release 5.2 (Final)

After upgrading we are seeing random characters in the RR an Cd columns on the 
jkserver-status page.
eg
o%2B
o+


Upgrade were done by stopping httpd.
Copying new modjk to /etc/httpd/modules/
Editing /etc/httpd/conf.d/modjk.conf to reflect new version.

Requests are being served but the strange characters and there origin a bit 
troubling.

Our workers.properties looks as follows:
( There is actually 12 workers but I have removed most to simplify config)


# Worker list
worker.list=xml-gta,jkstatus

# Worker definitions

# main loadbalancer worker
worker.xml-gta.type=lb
worker.xml-gta.max_reply_timeouts=10
#worker.xml-gta.sticky_session=false
worker.xml-gta.retries=6
worker.xml-gta.method=Busyness

worker.xml-gta.balance_workers=worker1, worker2


# status page worker
worker.jkstatus.type=status

# Worker Reference worker.reference.port=8009
worker.reference.type=ajp13
worker.reference.lbfactor=1
worker.reference.socket_timeout=0
worker.reference.socket_keepalive=true
worker.reference.connect_timeout=5000
worker.reference.prepost_timeout=0
worker.reference.reply_timeout=0
worker.reference.retries=6
worker.reference.recovery_options=27
worker.reference.connection_pool_timeout=600
worker.reference.connection_pool_size=2

worker.reference.ping_mode=A
worker.reference.ping_timeout=5000
worker.reference.retry_interval=60

# Balance workers

worker.worker1.reference=worker.reference
worker.worker1.host=10.10.10.10

worker.worker2.reference=worker.reference
worker.worker2.host=10.10.10.11

Regards


It's a known problem. There's an open Bugzilla for that issue. It seems 
you need at least around 8 worker for it to happen and I suspect it has 
to do with webserver restarts (apachectl graceful or apachectl restart). 
Unfortunately I don't yet fully understand the reasons, but noone has 
reported an operational problem resulting our of it, like stickyness or 
load balancing being broken. Of course we need to fix it ...


Can you confirm it happens only after restarting? And yes, it would be 
nice if your could build from the sources yourself and double check the 
problem is still there.


Regards,

Rainer

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: mod_jk and session stickyness of images requests

2009-12-12 Thread Rainer Jung

On 11.12.2009 18:38, Kockert, Timo wrote:

We are using Cocoon and its EncodeUrlTransformer to do the session ID encoding:


transformer.pool-max}" 
src="org.apache.cocoon.transformation.EncodeURLTransformer">


.*/@href=|.*/@action=|frame/@src=|img/@src=|input/@src=

nonexistinghtmlelement/@nonexistingattribute=



Hmm... I haven't used that transformer before. I'll have to take a look.
Something that seems obvious to me is that you probably want to add
something like this to the include-name:

|img/@src

This will (presumably) instruct the EncodeUrlTransformer to also
transform  src attributes, too.


I did include that (see above) and it works (mostly) like expected.


As I wrote before this seems to be working fine for most devices.
They
either use cookies for all requests or all urls are beeing rewritten to
include the session ID.


The devices themselves don't do the URL rewriting: your server-side code
(or someone else's, in the case of Cocoon) does it for you.


Just to clarify: I know the EncodeUrlTransformer does the encoding for me. The 
problem seems to be that some devices do not send session ID cookies with image 
requests.


Hmmm, sounds a bit confusing. You'll need either working URL encoding or 
working cookies. You can support both at the same time, but either of it 
will suffice to implement session stickyness. mod_jk will look at the 
URL, searching for the ";jsessionid=..." as well as looking for a 
JSESSIONID cookie.


If you want to track, in which cases the browsers suport what, you can 
use the Apache access log. The URL is part of it, so you can see, 
whether the session id was part of the request URL, and by adding 
%{JSESSIONID}C to the LogFormat, you can log the JSESSIONID cookie send. 
By adding %{Set-Cookie}o you can log, whenever your server sets a new 
cookie.


You are aware of the fact, taht supporting session stickyness with 
mod_jk neeeds


- an individual jvmRoute set in server.xml for each node
- a loadbalancing worker defined for mod_jk, with one ajp member for 
each node, the name of the member equal to the jvmRoute (or at least the 
route attribute set to that).



And this is part of our problem: we cannot recreate the issue
locally
to debug it. We just see some 404s in the mod_jk logs from time to time.


Try just disabling cookies on your web browser and then checking the
pages. You ought to be able to figure out which images are failing by
just looking at your web server logs, and then searching for those image
references in your webapp. Browse to those pages with cookies disabled
and you should see broken images (or maybe not).


We already tried that. If we disable cookies on our web browsers (or the 
devices we tested), all urls (including image links) are beeing rewritten 
correctly by the Cocoon transformer.


You could also write a filter that sends an error when the URL doesn't
contain a jsessionid, just for this no-cookies test so you can reproduce
it and test it.


Interesting idea. I could modified the EncodeUrlTransformer to get some more 
debug information. Will try that on Monday.

Greetings,
Timo


Regards,

Rainer

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat 6.0.16 + mod_jk 1.2.19 - request threads hanging up

2009-12-12 Thread Alessandro Bahgat
On Fri, Dec 11, 2009 at 4:27 PM, Rainer Jung  wrote:
> On 09.12.2009 12:18, Pid wrote:
>>
>> It could be, but while you're upgrading you might consider upgrading
>> HTTPD to the best available version too, 2.0.52 release date: 1 Oct
>> 2004. (That's 35 internet years ago.)
>
> ... and mod_jk 1.2.19 dates back to September 2006, so according to your
> math 21 internet years ago. There were so many bugs fixed since then, that
> you'll hardly find anyone that really tries to help debugging those old
> versions. At least use a recent mod_jk and look at
>
> http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html
>
> for some important hints about configuration.

Thank you both for your advice. I'm pushing towards upgrading the
Apache+mod_jk stack as well.
Our last tests with the latest Tomcat and mod_jk still showed a lot of
CPU time being spent in sendbb methods, with some threads being stuck
in that method for long time.

We actually found out a lot of "unrecoverable error 200, request
failed" error messages in the mod_jk log (roughly around 1k per hour),
so I'm starting to wonder if there's any issue with the firewalls and
the network infrastructure. What would you think about that?

[Thu Dec 03 16:58:52 2009][31539:42688] [info]
service::jk_lb_worker.c (873): unrecoverable error 200, request
failed. Client failed in the middle of request, we can't recover to
another instance.
[Thu Dec 03 16:58:52 2009][31539:42688] [info]  jk_handler::mod_jk.c
(2056): Aborting connection for worker=applprod
[Thu Dec 03 16:58:53 2009][31612:42688] [info]
jk_open_socket::jk_connect.c (450): connect to XXX.XXX.XXX.XXX:8009
failed with errno=111
[Thu Dec 03 16:58:53 2009][31612:42688] [info]
ajp_connect_to_endpoint::jk_ajp_common.c (872): Failed opening socket
to (XXX.XXX.XXX.XXX:8009) with (errno=111)
[Thu Dec 03 16:58:53 2009][31612:42688] [info]
ajp_send_request::jk_ajp_common.c (1247): (applprod05) error
connecting to the backend server (errno=111)
[Thu Dec 03 16:58:53 2009][31612:42688] [info]
ajp_service::jk_ajp_common.c (1867): (applprod05) sending request to
tomcat failed,  recoverable operation attempt=1

Thank you for your help,
Alessandro

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org