Re: tomcat 7 APR Connector problems

2012-10-15 Thread Pid *
On 15 Oct 2012, at 07:42, Andrey Timofeyev  wrote:

> Hi Chris,
>
> thank you so much for answer,
>
>> What about your Tomcat configuration:
> 
> SSLEngine="on"/>

You have no other listeners?


>
>   maxPostSize="5242880"
>   enableLookups="false"
>   useBodyEncodingForURI="true"
>   port="80"
>   maxThreads="1100"
>   disableUploadTimeout="true"
>   maxHttpHeaderSize="8192"
>   pollerSize="16768"
>   maxKeepAliveRequests="-1"
>   connectionTimeout="2"
>   asyncTimeout="11"
>   keepAliveTimeout="12"
>   compression="on"
>
> compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/x-javascript"
>   address="{...}"
>   acceptCount="1000"/>
>   maxPostSize="5242880"
>   enableLookups="false"
>   useBodyEncodingForURI="true"
>   port="82"
>   maxThreads="100"
>   disableUploadTimeout="true"
>   maxHttpHeaderSize="8192"
>   pollerSize="100"
>   maxKeepAliveRequests="-1"
>   connectionTimeout="2"
>   keepAliveTimeout="120"
>   compression="on"
>
> compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/x-javascript"
>   address="{...}"
>   acceptCount="100"/>
>   maxPostSize="5242880"
>   enableLookups="false"
>   useBodyEncodingForURI="true"
>   port="443"
>   maxThreads="1100"
>   disableUploadTimeout="true"
>   maxHttpHeaderSize="8192"
>   pollerSize="32768"
>   maxKeepAliveRequests="-1"
>   connectionTimeout="2"
>   keepAliveTimeout="12"
>   compression="on"
>
> compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/x-javascript"
>   address="0.0.0.0"
>   acceptCount="100" scheme="https" secure="true"
>   SSLEnabled="true"
>   SSLCipherSuite="HIGH:MEDIUM:!ADH:!SSLv2"
>   SSLCertificateFile="{...}"
>   SSLCertificateKeyFile="{...}"
>   SSLCertificateChainFile="{...}"/>
>
>  appBase="{...}"
>  autoDeploy="false"
>  unpackWARs="true"
>  deployXML="false">


>
> maxActiveSessions="163840"
> maxInactiveInterval="1800"
> pathname=""/>
>

This Context seems to be missing a docBase, unless you are doing
something very bad and publishing the appBase.

Defining context in server.xml is not recommended.


p


> privileged="true"
> docBase="{...}">
> className="org.apache.catalina.realm.MemoryRealm"
> pathname="conf/tomcat-users.xml"/>
> className="org.apache.catalina.valves.RemoteAddrValve"
>   allow="{...}"/>
>
>
>
>
> docBase="{deploy.dir}/web/gwt-alt"/>
>
>
>
> 
>
>> Do you get exceptions or apparent deadlock? Can you generate a thread
> dump?
> There are no any deadlock or aniything strange compared to life server (i
> will generate it one yet time, may be i missed something)
>
>> Are your client connections long-lived
> Average client connection live 11 minutes.
>
>> What does 'ulimit -n' tell you
> 256k
>
> 2012/10/12 Christopher Schultz 
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Andrey,
>>
>> On 10/12/12 11:30 AM, Andrey Timofeyev wrote:
>>> Hi, everybody,
>>>
>>> There is followen problem with tomcat 7.0.29 (With tomcat 6.0.18
>>> there is no such problem):
>>>
>>> Any other services on the same machine lost connections with
>>> remote services, when number of incoming connections to tomcat
>>> reach pollerSize. (It seems that all file descriptors is used or
>>> something else)
>>>
>>> As I see in the tomcat 7  latch was added in AprEndpoint, and if
>>> connections reach maxLimit Acceptor locked on the latch.
>>>
>>> Here is server configuration: Linux 2.6.34.6-uni-02 #1 SMP Mon Sep
>>> 19 17:13:09 MSD 2011 x86_64 x86_64 x86_64 GNU/Linux APR:
>>> libapr1-1.4.6-3.8 kernel.panic = 20
>>> net.ipv4.conf.all.accept_redirects = 0
>>> net.ipv4.conf.default.accept_redirects = 0
>>> ne

Re: tomcat 7 APR Connector problems

2012-10-14 Thread Andrey Timofeyev
Hi Chris,

thank you so much for answer,

> What about your Tomcat configuration:
























> Do you get exceptions or apparent deadlock? Can you generate a thread
dump?
There are no any deadlock or aniything strange compared to life server (i
will generate it one yet time, may be i missed something)

> Are your client connections long-lived
Average client connection live 11 minutes.

> What does 'ulimit -n' tell you
256k

2012/10/12 Christopher Schultz 

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Andrey,
>
> On 10/12/12 11:30 AM, Andrey Timofeyev wrote:
> > Hi, everybody,
> >
> > There is followen problem with tomcat 7.0.29 (With tomcat 6.0.18
> > there is no such problem):
> >
> > Any other services on the same machine lost connections with
> > remote services, when number of incoming connections to tomcat
> > reach pollerSize. (It seems that all file descriptors is used or
> > something else)
> >
> > As I see in the tomcat 7  latch was added in AprEndpoint, and if
> > connections reach maxLimit Acceptor locked on the latch.
> >
> > Here is server configuration: Linux 2.6.34.6-uni-02 #1 SMP Mon Sep
> > 19 17:13:09 MSD 2011 x86_64 x86_64 x86_64 GNU/Linux APR:
> > libapr1-1.4.6-3.8 kernel.panic = 20
> > net.ipv4.conf.all.accept_redirects = 0
> > net.ipv4.conf.default.accept_redirects = 0
> > net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.default.rp_filter =
> > 0 net.ipv4.icmp_echo_ignore_broadcasts = 1 vm.min_free_kbytes =
> > 65536 vm.swappiness = 0 net.core.optmem_max = 16777216
> > net.core.rmem_max = 16777216 net.core.rmem_default = 16777216
> > net.core.wmem_max = 16777216 net.core.wmem_default = 16777216
> > net.ipv4.tcp_rmem = 4096 16777216 16777216 net.ipv4.tcp_wmem = 4096
> > 16777216 16777216 net.core.netdev_max_backlog = 30
> > net.core.somaxconn = 65536 net.ipv4.tcp_max_orphans = 262144
> > net.ipv4.tcp_max_syn_backlog = 65536 net.ipv4.tcp_max_tw_buckets =
> > 1048576 net.ipv4.tcp_sack = 1 net.ipv4.tcp_synack_retries = 3
> > net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_syn_retries = 3
> > net.ipv4.tcp_timestamps = 1 net.ipv4.tcp_window_scaling = 1
> > net.ipv4.conf.all.arp_filter = 1 net.ipv4.conf.default.arp_filter =
> > 1 net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.default.arp_ignore
> > = 1 net.ipv4.conf.all.arp_announce = 2
> > net.ipv4.conf.default.arp_announce = 2
> > net.ipv4.neigh.default.gc_thresh1 = 2048
> > net.ipv4.neigh.default.gc_thresh2 = 4096
> > net.ipv4.neigh.default.gc_thresh3 = 8192
> >
> > Is it tomcat issue or some misconfiguration?
>
> What about your Tomcat configuration?
>
> Do you get exceptions or apparent deadlock? Can you generate a thread
> dump? Are your client connections long-lived? How long? What does
> 'ulimit -n' tell you?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iEYEARECAAYFAlB4PB4ACgkQ9CaO5/Lv0PB6owCfdKmTMEEiaZrlEOWwDSn8Zdic
> P7MAn0dmd8U6FJMZvWEg89o8wWEuCqJV
> =rdPD
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Best regards,
Andrey.


Re: tomcat 7 APR Connector problems

2012-10-12 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andrey,

On 10/12/12 11:30 AM, Andrey Timofeyev wrote:
> Hi, everybody,
> 
> There is followen problem with tomcat 7.0.29 (With tomcat 6.0.18
> there is no such problem):
> 
> Any other services on the same machine lost connections with
> remote services, when number of incoming connections to tomcat
> reach pollerSize. (It seems that all file descriptors is used or
> something else)
> 
> As I see in the tomcat 7  latch was added in AprEndpoint, and if 
> connections reach maxLimit Acceptor locked on the latch.
> 
> Here is server configuration: Linux 2.6.34.6-uni-02 #1 SMP Mon Sep
> 19 17:13:09 MSD 2011 x86_64 x86_64 x86_64 GNU/Linux APR:
> libapr1-1.4.6-3.8 kernel.panic = 20 
> net.ipv4.conf.all.accept_redirects = 0 
> net.ipv4.conf.default.accept_redirects = 0 
> net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.default.rp_filter =
> 0 net.ipv4.icmp_echo_ignore_broadcasts = 1 vm.min_free_kbytes =
> 65536 vm.swappiness = 0 net.core.optmem_max = 16777216 
> net.core.rmem_max = 16777216 net.core.rmem_default = 16777216 
> net.core.wmem_max = 16777216 net.core.wmem_default = 16777216 
> net.ipv4.tcp_rmem = 4096 16777216 16777216 net.ipv4.tcp_wmem = 4096
> 16777216 16777216 net.core.netdev_max_backlog = 30 
> net.core.somaxconn = 65536 net.ipv4.tcp_max_orphans = 262144 
> net.ipv4.tcp_max_syn_backlog = 65536 net.ipv4.tcp_max_tw_buckets =
> 1048576 net.ipv4.tcp_sack = 1 net.ipv4.tcp_synack_retries = 3 
> net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_syn_retries = 3 
> net.ipv4.tcp_timestamps = 1 net.ipv4.tcp_window_scaling = 1 
> net.ipv4.conf.all.arp_filter = 1 net.ipv4.conf.default.arp_filter =
> 1 net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.default.arp_ignore
> = 1 net.ipv4.conf.all.arp_announce = 2 
> net.ipv4.conf.default.arp_announce = 2 
> net.ipv4.neigh.default.gc_thresh1 = 2048 
> net.ipv4.neigh.default.gc_thresh2 = 4096 
> net.ipv4.neigh.default.gc_thresh3 = 8192
> 
> Is it tomcat issue or some misconfiguration?

What about your Tomcat configuration?

Do you get exceptions or apparent deadlock? Can you generate a thread
dump? Are your client connections long-lived? How long? What does
'ulimit -n' tell you?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlB4PB4ACgkQ9CaO5/Lv0PB6owCfdKmTMEEiaZrlEOWwDSn8Zdic
P7MAn0dmd8U6FJMZvWEg89o8wWEuCqJV
=rdPD
-END PGP SIGNATURE-

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



RE: NIO-connector problems (excessive CPU-usage)

2010-01-14 Thread Tobias Lind
Hello!
I think I have something for you to reproduce this issue. I managed to
create a test-servlet which causes the problem (every time) when I call it
on Linux kernel 2.4 with the NIO-connector (and no problem in kernel 2.6 or
with the BIO-connector).

I have also created a VMWare-installation of Centos 3.9 (kernel 2.4.21-50)
where this test-case "works", and I'd be happy to send it to you. It's quite
big (~630 Mb), so I'd rather not publish a link to it in public - can I send
you a private email with a download-link to it?

The problem is triggered when the servlet calls Thread.sleep() in a call
(yes, I know all about calling sleep() in a servlet, but this is for showing
this issue, and it'll probably happen in other situations as well).
When the thread is sleeping, and more calls comes in to the same connection,
the NIO-selector starts looping. The CPU goes back down to normal when ALL
sleeping thread is done.

The servlet-code is below..


How to repeat:
==
Set up this servlet on a Linux system with kernel 2.4
Don't know if my config makes any difference, but the server.xml I used is
also below.

Make a call to it wherever you've installed it
In my case it's http://192.168.0.134/test/NioBugTest

Hit the link "Call sleepy operation" a few times rapidly (3 times will do),
and the NIO-selector starts spinning.
All calls have to be made from the same browser window - it has something to
do with the Kept-alive-connection I think.
If many simultaneous calls are made to "NioBugTest?do=sleep" from
_different_ browser windows, the problem does not occur!




server.xml
===

   



   

  localhost

  

  
   
   
  






NioBugTest.java
=

import javax.servlet.http.*;
import java.io.PrintWriter;

final public class NioBugTest extends HttpServlet {
  static int servedThreads=0;

  public void doGet(HttpServletRequest req, HttpServletResponse res) {
try {
  servedThreads++;

  res.setHeader("Cache-Control", "no-store, no-cache, must-revalidate");
  res.setHeader("Pragma", "no-cache");
  res.setHeader("Expires", "Tue, 01 Jan 1980 01:00:00 GMT");

  PrintWriter toClient = res.getWriter();

  String operation=req.getParameter("do");
  if ((operation==null)||(operation.length()==0)) {
toClient.println("Test NIO-problem in Linux kernel 2.4 with
Tomcat");
toClient.println("Call sleepy
operation");
toClient.println("Check number of served
clients");
  } else if (operation.equals("sleep")) {
int secs=30;
try {
  secs=Integer.parseInt(req.getParameter("secs"),10);
} catch (Exception e) {}
toClient.println("Going to sleep for "+Integer.toString(secs)+"
seconds...");
Thread.sleep(1000*secs);
  } else if (operation.equals("check")) {
toClient.println("Number of served
Threads="+Integer.toString(servedThreads));
  } else {
toClient.println("unknown operation");
  }

  toClient.close();
} catch (Exception e) {
  System.err.println("Exception in doGet: "+e.toString());
} finally {
  servedThreads--;
}
  }
}





-Original Message-
From: Filip Hanik - Dev Lists [mailto:devli...@hanik.com] 
Sent: den 13 januari 2010 18:46
To: Tomcat Users List
Subject: Re: NIO-connector problems (excessive CPU-usage)

On 01/13/2010 10:25 AM, Tobias Lind wrote:
> Ok, so chances are that we will not encounter this issue if we upgrade to
a
> newer kernel (and/or another machine - we are currently also thinking
about
> upgrading the hardware)?
>
not necessarily. The bug was in the JDK and how it uses the kernel
libraries.

> It would be nice to see that others are using the NIO-connector on Linux
in
> a productive environment without problems before we start upgrading...
> Anyone?
>
> Is there anything we can do to assist you in reproducing this issue?
>
In order to test a workaround for this issue, one would need to be able
to reproduce it.
So far, we've had a few bugzilla issues opened, but no one to actually
work it to the way where its reproducible.

> Maybe try any special build with extra logging, etc...
>
We know where the code is looping. The reproduction is not for seeing
the issue, its for testing the workaround.
> It only occurs on our production machine, so we can't experiment too much,
> but as the issue is quite serious, we'd gladly help in any way we can.
>
same as everyone else. I would stick with BIO connector in that case.
> It just jumped to>100% CPU just a minute ago now, so it happens pretty
> frequently on our machine. I wish there was 

Re: NIO-connector problems (excessive CPU-usage)

2010-01-13 Thread Filip Hanik - Dev Lists
0x53790010>  (a sun.nio.ch.Util$1)
- locked<0x5379>  (a java.util.Collections$UnmodifiableSet)
- locked<0x548b0798>  (a sun.nio.ch.PollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
at
org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:1545)
at java.lang.Thread.run(Thread.java:619)

/Tobias


-Original Message-
From: Filip Hanik - Dev Lists [mailto:devli...@hanik.com]
Sent: den 13 januari 2010 16:13
To: Tomcat Users List
Subject: Re: NIO-connector problems (excessive CPU-usage)

yes, the issue is known. However, we have not been able to create a use
case for it, since I've never been able to reproduce it.
One of the work arounds would be to close the selector, but that is a
royal pain, since you'd then have to reregister all keys and you'd end
up in a synchronization nightmare.

Filip

On 01/13/2010 07:57 AM, Tobias Lind wrote:
   

Hi!
We've been using Tomcat on Linux for a very long time (and the good old
JServe before it), and we recently started testing the NIO-connector
 

instead
   

of the old blocking one. We are currently running the latest Tomcat
 

v6.0.20.
   



We have a pretty large website with quite a lot of traffic, and switching
 

to
   

the NIO-connector gives us a VERY good performance boost! We also got rid
 

of
   

problems with hanging connections, etc, so it was very promising.



But it also gave us new headaches :/

We were using IBM's JDK 6.0_7 (the latest), and on the first testing on
 

our
   

production server, the CPU hit 100% (everything started and the site
 

worked
   

though).

We installed Sun's JDK 1.6.0_17 instead, and the CPU was constantly
 

running
   

at ~20-30% even when the traffic to the site was quite low. In about 24
hours runtime, we also saw one occasion where the CPU went up to 100% and
never came down again (while no clients where actually running our
 

server),
   

and it took a Tomcat-restart to get it "down" to 30% again.



I started investigating, and found quite a lot of reports on problem with
NIO and the Selector looping out of control.

Hera are some links to pages about this problem:
http://bugs.sun.com/view_bug.do?bug_id=6403933

http://bugs.sun.com/view_bug.do?bug_id=6525190

http://forums.sun.com/thread.jspa?threadID=5135128

http://issues.apache.org/jira/browse/DIRMINA-678





A thread-dump showed that it's very likely to be this problem we are
 

seeing.
   

These threads are taking much more CPU than expected (although on Sun's
 

JDK
   

it seems a bit better than on IBM's), and when the system load  jumped to
100%, it was the "http-80-ClientPoller-0" that behaving badly:



"http-80-Acceptor-0" daemon prio=10 tid=0x0828d400 nid=0x7308 runnable
[0x4df19000]

 java.lang.Thread.State: RUNNABLE

   at
sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)

   at

 

sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:145)
   

   - locked<0x547f84c8>   (a java.lang.Object)

   at
org.apache.tomcat.util.net.NioEndpoint$Acceptor.run(NioEndpoint.java:1266)

   at java.lang.Thread.run(Thread.java:619)



"http-80-ClientPoller-1" daemon prio=10 tid=0x0825f400 nid=0x7307 runnable
[0x4df6a000]

 java.lang.Thread.State: RUNNABLE

   at sun.nio.ch.PollArrayWrapper.poll0(Native
Method)

   at
sun.nio.ch.PollArrayWrapper.poll(PollArrayWrapper.java:100)

   at
sun.nio.ch.PollSelectorImpl.doSelect(PollSelectorImpl.java:56)

   at
sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)

   - locked<0x54941568>   (a sun.nio.ch.Util$1)

   - locked<0x54941558>   (a
java.util.Collections$UnmodifiableSet)

   - locked<0x54941410>   (a
sun.nio.ch.PollSelectorImpl)

   at
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)

   at
org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:1545)

   at java.lang.Thread.run(Thread.java:619)



"http-80-ClientPoller-0" daemon prio=10 tid=0x0831b400 nid=0x7306 runnable
[0x4dfbb000]

 java.lang.Thread.State: RUNNABLE

   at sun.nio.ch.PollArrayWrapper.poll0(Native
Method)

   at
sun.nio.ch.PollArrayWrapper.poll(PollArrayWrapper.java:100)

   at
sun.nio.ch.PollSelectorImpl.doSelect(PollSelectorImpl.java:56)

   at
sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.

RE: NIO-connector problems (excessive CPU-usage)

2010-01-13 Thread Tobias Lind
Ok, so chances are that we will not encounter this issue if we upgrade to a
newer kernel (and/or another machine - we are currently also thinking about
upgrading the hardware)?

It would be nice to see that others are using the NIO-connector on Linux in
a productive environment without problems before we start upgrading...
Anyone?

Is there anything we can do to assist you in reproducing this issue?
Maybe try any special build with extra logging, etc...
It only occurs on our production machine, so we can't experiment too much,
but as the issue is quite serious, we'd gladly help in any way we can.

It just jumped to >100% CPU just a minute ago now, so it happens pretty
frequently on our machine. I wish there was some kind of dump I could make
and send you to help you :)

The two top-threads on this "top"-dump are the two
"http-80-ClientPoller"-threads:

18:24:06  up 212 days,  6:18,  3 users,  load average: 2.66, 2.81, 2.29
647 processes: 641 sleeping, 6 running, 0 zombie, 0 stopped
CPU states:  cpuusernice  systemirq  softirq  iowaitidle
   total   26.6%0.0%  111.8%   0.0% 6.4%   24.2%   30.4%
   cpu00   15.4%0.0%   47.6%   0.0% 4.9%   16.0%   15.8%
   cpu01   11.3%0.0%   64.2%   0.0% 1.5%8.1%   14.6%
Mem:  4031024k av, 3983960k used,   47064k free,   0k shrd,   35336k
buff
   3080496k actv,  593696k in_d,   70952k in_c
Swap:   0k av,   0k used,   0k free 2334824k
cached

  PID USER PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME CPU COMMAND
 6563 root  25   0  802M 802M  9144 R90.1 20.3  36:28   0 java
 6562 root  25   0  802M 802M  9144 S15.4 20.3  28:48   1 java
 6636 root  15   0  802M 802M  9144 S 2.1 20.3   2:05   0 java
29633 mysql 16   0  606M 606M  2352 S 1.5 15.4  14:09   1 mysqld
29634 mysql 16   0  606M 606M  2352 S 1.3 15.4  15:26   0 mysqld
 6855 mysql 16   0  606M 606M  2352 S 0.9 15.4   0:10   1 mysqld
 6964 mysql 15   0  606M 606M  2352 S 0.9 15.4   0:10   0 mysqld
11917 root  15   0  1896 1896   900 R 0.9  0.0   0:01   1 top
 6546 root  16   0  802M 802M  9144 S 0.7 20.3   1:45   1 java
32744 mysql 15   0  606M 606M  2352 S 0.5 15.4   0:55   0 mysqld
 6547 root  16   0  802M 802M  9144 S 0.5 20.3   1:45   0 java
 6555 root  15   0  802M 802M  9144 S 0.5 20.3   0:11   0 java
 6962 mysql 15   0  606M 606M  2352 S 0.5 15.4   0:10   1 mysqld
 6576 root  16   0  802M 802M  9144 S 0.3 20.3   0:05   1 java
 6578 root  15   0  802M 802M  9144 S 0.3 20.3   0:06   0 java
 6751 mysql 15   0  606M 606M  2352 S 0.3 15.4   0:09   1 mysqld
 6963 mysql 15   0  606M 606M  2352 S 0.3 15.4   0:13   0 mysqld
 6997 root  15   0  802M 802M  9144 S 0.3 20.3   0:05   0 java



"http-80-ClientPoller-1" daemon prio=10 tid=0x0833ac00 nid=0x19a3 runnable
[0x4de5d000]
   java.lang.Thread.State: RUNNABLE
at sun.nio.ch.PollArrayWrapper.poll0(Native Method)
at sun.nio.ch.PollArrayWrapper.poll(PollArrayWrapper.java:100)
at sun.nio.ch.PollSelectorImpl.doSelect(PollSelectorImpl.java:56)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
- locked <0x53ae1cb8> (a sun.nio.ch.Util$1)
- locked <0x53ae1ca8> (a java.util.Collections$UnmodifiableSet)
- locked <0x548b0008> (a sun.nio.ch.PollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
at
org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:1545)
at java.lang.Thread.run(Thread.java:619)

"http-80-ClientPoller-0" daemon prio=10 tid=0x0833a400 nid=0x19a2 runnable
[0x4deae000]
   java.lang.Thread.State: RUNNABLE
at sun.nio.ch.PollArrayWrapper.poll0(Native Method)
at sun.nio.ch.PollArrayWrapper.poll(PollArrayWrapper.java:100)
at sun.nio.ch.PollSelectorImpl.doSelect(PollSelectorImpl.java:56)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
- locked <0x53790010> (a sun.nio.ch.Util$1)
- locked <0x5379> (a java.util.Collections$UnmodifiableSet)
- locked <0x548b0798> (a sun.nio.ch.PollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
at
org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:1545)
at java.lang.Thread.run(Thread.java:619)

/Tobias


-Original Message-
From: Filip Hanik - Dev Lists [mailto:devli...@hanik.com] 
Sent: den 13 januari 2010 16:13
To: Tomcat Users List
Subject: Re: NIO-connector problems (excessive CPU-usage)

yes, the issue is known. However, we have not been able to create a use 
case for it, since I've never been able to reproduce it.
One of the work arounds would be to close the selector, but that is a 
royal pain, since you'd then have t

Re: NIO-connector problems (excessive CPU-usage)

2010-01-13 Thread Filip Hanik - Dev Lists
yes, the issue is known. However, we have not been able to create a use 
case for it, since I've never been able to reproduce it.
One of the work arounds would be to close the selector, but that is a 
royal pain, since you'd then have to reregister all keys and you'd end 
up in a synchronization nightmare.


Filip

On 01/13/2010 07:57 AM, Tobias Lind wrote:

Hi!
We've been using Tomcat on Linux for a very long time (and the good old
JServe before it), and we recently started testing the NIO-connector instead
of the old blocking one. We are currently running the latest Tomcat v6.0.20.



We have a pretty large website with quite a lot of traffic, and switching to
the NIO-connector gives us a VERY good performance boost! We also got rid of
problems with hanging connections, etc, so it was very promising.



But it also gave us new headaches :/

We were using IBM's JDK 6.0_7 (the latest), and on the first testing on our
production server, the CPU hit 100% (everything started and the site worked
though).

We installed Sun's JDK 1.6.0_17 instead, and the CPU was constantly running
at ~20-30% even when the traffic to the site was quite low. In about 24
hours runtime, we also saw one occasion where the CPU went up to 100% and
never came down again (while no clients where actually running our server),
and it took a Tomcat-restart to get it "down" to 30% again.



I started investigating, and found quite a lot of reports on problem with
NIO and the Selector looping out of control.

Hera are some links to pages about this problem:
http://bugs.sun.com/view_bug.do?bug_id=6403933

http://bugs.sun.com/view_bug.do?bug_id=6525190

http://forums.sun.com/thread.jspa?threadID=5135128

http://issues.apache.org/jira/browse/DIRMINA-678





A thread-dump showed that it's very likely to be this problem we are seeing.
These threads are taking much more CPU than expected (although on Sun's JDK
it seems a bit better than on IBM's), and when the system load  jumped to
100%, it was the "http-80-ClientPoller-0" that behaving badly:



"http-80-Acceptor-0" daemon prio=10 tid=0x0828d400 nid=0x7308 runnable
[0x4df19000]

java.lang.Thread.State: RUNNABLE

  at
sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)

  at
sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:145)

  - locked<0x547f84c8>  (a java.lang.Object)

  at
org.apache.tomcat.util.net.NioEndpoint$Acceptor.run(NioEndpoint.java:1266)

  at java.lang.Thread.run(Thread.java:619)



"http-80-ClientPoller-1" daemon prio=10 tid=0x0825f400 nid=0x7307 runnable
[0x4df6a000]

java.lang.Thread.State: RUNNABLE

  at sun.nio.ch.PollArrayWrapper.poll0(Native
Method)

  at
sun.nio.ch.PollArrayWrapper.poll(PollArrayWrapper.java:100)

  at
sun.nio.ch.PollSelectorImpl.doSelect(PollSelectorImpl.java:56)

  at
sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)

  - locked<0x54941568>  (a sun.nio.ch.Util$1)

  - locked<0x54941558>  (a
java.util.Collections$UnmodifiableSet)

  - locked<0x54941410>  (a
sun.nio.ch.PollSelectorImpl)

  at
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)

  at
org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:1545)

  at java.lang.Thread.run(Thread.java:619)



"http-80-ClientPoller-0" daemon prio=10 tid=0x0831b400 nid=0x7306 runnable
[0x4dfbb000]

java.lang.Thread.State: RUNNABLE

  at sun.nio.ch.PollArrayWrapper.poll0(Native
Method)

  at
sun.nio.ch.PollArrayWrapper.poll(PollArrayWrapper.java:100)

  at
sun.nio.ch.PollSelectorImpl.doSelect(PollSelectorImpl.java:56)

  at
sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)

  - locked<0x54941758>  (a sun.nio.ch.Util$1)

  - locked<0x54941748>  (a
java.util.Collections$UnmodifiableSet)

  - locked<0x54941610>  (a
sun.nio.ch.PollSelectorImpl)

  at
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)

  at
org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:1545)

  at java.lang.Thread.run(Thread.java:619)









I'm sure this issue is well known to the Tomcat community and that it has
been discussed before, but I'd just like to know the current status on the
issue.



The webpages i referred to above indicates that there are some workarounds
to this problem - are these workarounds implemented in Tomcat?

Is there anything we can do to 

NIO-connector problems (excessive CPU-usage)

2010-01-13 Thread Tobias Lind
Hi!
We've been using Tomcat on Linux for a very long time (and the good old
JServe before it), and we recently started testing the NIO-connector instead
of the old blocking one. We are currently running the latest Tomcat v6.0.20.

 

We have a pretty large website with quite a lot of traffic, and switching to
the NIO-connector gives us a VERY good performance boost! We also got rid of
problems with hanging connections, etc, so it was very promising.

 

But it also gave us new headaches :/

We were using IBM's JDK 6.0_7 (the latest), and on the first testing on our
production server, the CPU hit 100% (everything started and the site worked
though).

We installed Sun's JDK 1.6.0_17 instead, and the CPU was constantly running
at ~20-30% even when the traffic to the site was quite low. In about 24
hours runtime, we also saw one occasion where the CPU went up to 100% and
never came down again (while no clients where actually running our server),
and it took a Tomcat-restart to get it "down" to 30% again.

 

I started investigating, and found quite a lot of reports on problem with
NIO and the Selector looping out of control.

Hera are some links to pages about this problem:
http://bugs.sun.com/view_bug.do?bug_id=6403933

http://bugs.sun.com/view_bug.do?bug_id=6525190

http://forums.sun.com/thread.jspa?threadID=5135128

http://issues.apache.org/jira/browse/DIRMINA-678

 

 

A thread-dump showed that it's very likely to be this problem we are seeing.
These threads are taking much more CPU than expected (although on Sun's JDK
it seems a bit better than on IBM's), and when the system load  jumped to
100%, it was the "http-80-ClientPoller-0" that behaving badly:

 

"http-80-Acceptor-0" daemon prio=10 tid=0x0828d400 nid=0x7308 runnable
[0x4df19000]

   java.lang.Thread.State: RUNNABLE

 at
sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)

 at
sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:145)

 - locked <0x547f84c8> (a java.lang.Object)

 at
org.apache.tomcat.util.net.NioEndpoint$Acceptor.run(NioEndpoint.java:1266)

 at java.lang.Thread.run(Thread.java:619)

 

"http-80-ClientPoller-1" daemon prio=10 tid=0x0825f400 nid=0x7307 runnable
[0x4df6a000]

   java.lang.Thread.State: RUNNABLE

 at sun.nio.ch.PollArrayWrapper.poll0(Native
Method)

 at
sun.nio.ch.PollArrayWrapper.poll(PollArrayWrapper.java:100)

 at
sun.nio.ch.PollSelectorImpl.doSelect(PollSelectorImpl.java:56)

 at
sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)

 - locked <0x54941568> (a sun.nio.ch.Util$1)

 - locked <0x54941558> (a
java.util.Collections$UnmodifiableSet)

 - locked <0x54941410> (a
sun.nio.ch.PollSelectorImpl)

 at
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)

 at
org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:1545)

 at java.lang.Thread.run(Thread.java:619)

 

"http-80-ClientPoller-0" daemon prio=10 tid=0x0831b400 nid=0x7306 runnable
[0x4dfbb000]

   java.lang.Thread.State: RUNNABLE

 at sun.nio.ch.PollArrayWrapper.poll0(Native
Method)

 at
sun.nio.ch.PollArrayWrapper.poll(PollArrayWrapper.java:100)

 at
sun.nio.ch.PollSelectorImpl.doSelect(PollSelectorImpl.java:56)

 at
sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)

 - locked <0x54941758> (a sun.nio.ch.Util$1)

 - locked <0x54941748> (a
java.util.Collections$UnmodifiableSet)

 - locked <0x54941610> (a
sun.nio.ch.PollSelectorImpl)

 at
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)

 at
org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:1545)

 at java.lang.Thread.run(Thread.java:619)

 

 

 

 

I'm sure this issue is well known to the Tomcat community and that it has
been discussed before, but I'd just like to know the current status on the
issue. 

 

The webpages i referred to above indicates that there are some workarounds
to this problem - are these workarounds implemented in Tomcat?

Is there anything we can do to get it running?

We'd REALLY like to use this connector as it's performing a lot better.

Even though the CPU-load is a lot higher, the clients on the site is served
a lot better it seems.

So running with 30-40% CPU could actually be ok for now, but when it also
jumps up to 100% and stays there, it's not possible to use...



We are running on quite an old Linux system wi

RE: AJP Connector - Problems Proxying HTTPS Connections

2007-02-05 Thread Bill Bailey
Hassan,

Thanks for your help. I am going to try making my app the ROOT context
for the default host and get rid of the virtual hosts on the Tomcat
side. If that still doesn't work, I'll try some of your troubleshooting
ideas.

I actually tried using mod_proxy_http once in my many attempts to find a
solution and had problems there, too, but I've been through so many
iterations now, I won't swear to exactly what I did or didn't try.

You are right. This really shouldn't be this hard. And I didn't expect
it to be when I started (after all, I did this for another application
in far less time), but once I committed to an approach I was like an old
dog with a bone and refused to let it go until I got it working. Maybe a
new direction will be the ticket to getting me past this.

Thanks again.

Bill Bailey


-Original Message-
From: Hassan Schroeder [mailto:[EMAIL PROTECTED] 
Sent: Monday, February 05, 2007 3:33 PM
To: Tomcat Users List
Subject: Re: AJP Connector - Problems Proxying HTTPS Connections

On 2/5/07, Bill Bailey <[EMAIL PROTECTED]> wrote:

> So the context (which I don't want visible to the end users) has
> 'escaped' into the browser world. I found that this was not a problem
if
> I made my application appear in the ROOT context for the server, but
> didn't want to remove the standard ROOT applications (manager, etc.)
for
> the local host. Therefore, I decided to have a second virtual host on
> the Tomcat side.

whoa, you lost me here. The manager is a separate Context -- there's
no reason you can't have your app as the ROOT context on the default
host. Still,

> One of my next tests is going to be to replace this
> JSP with a vanilla HTML file to eliminate for certain the possibility
> that my application is doing this unwanted redirect, but I'm
reasonably
> confident that it isn't.

Not a perfect test, since your app might have some Filter doing stuff
that's non-obvious :-)

Anyway, here's my suggestion: replace your current app with a very
skeletal web app, just an index.html, say, so you know there's nothing
wierd going on. Try that. If that still doesn't work, change your httpd
proxy to use mod_proxy_http and forward to your 8080 port.  At the
worst, you can sniff that traffic to see what's really happening :-)

This really shouldn't be this hard  -- I've set up a similar config (but
with multiple virtual hosts) pretty recently, and there was nothing to
it.

HTH,
-- 
Hassan Schroeder  [EMAIL PROTECTED]

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: AJP Connector - Problems Proxying HTTPS Connections

2007-02-05 Thread Bill Bailey
Thanks, Charles.

The main reason for deploying behind httpd rather than standalone was to
leave a bit more flexibility in the event we decide to deploy one or
more other non-J2EE (e.g. PHP) web applications to this same server at a
later date, should that become desirable or necessary. I've also heard
that the httpd SSL implementation is faster than Tomcat, but perhaps
that is now a thing of the past.

Thanks for setting me straight on the ROOT context. I got the same
comment from someone else. This will probably be the next thing I try
since I have this working in a similar configuration for another
application.

At this point, any approach that works is a good one, but even though I
may not have needed to take the approach I selected, I'm still curious
to know what I did wrong. So if anyone sees the reason why this approach
could never have worked or sees an error in my configuration, I'd still
be interested.

Thanks again.

Bill Bailey


-Original Message-
From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] 
Sent: Monday, February 05, 2007 3:25 PM
To: Tomcat Users List
Subject: RE: AJP Connector - Problems Proxying HTTPS Connections

> From: Bill Bailey [mailto:[EMAIL PROTECTED] 
> Subject: RE: AJP Connector - Problems Proxying HTTPS Connections
> 
> I have a J2EE (Struts) Application running in Tomcat. I want
> to use Apache HTTPD to provide the HTTPS connections and simply
> proxy all requests to the Tomcat container.

It seems like you're going through a lot of unnecessary work & headaches
to put httpd in front of Tomcat; if you don't have some other pressing
need, why not just run Tomcat standalone?  It handles SSL quite nicely.

> Another constraint is that I want the web site to
> be accessible by just its hostname and domain (e.g.
> https://www.resourcepoint.org) and I don't want to
> require a servlet context path to be typed as part
> of the URL every time one accesses the site.

Then simply deploy your application as ROOT.

> I found that this was not a problem if I made my
> application appear in the ROOT context for the server,
> but didn't want to remove the standard ROOT applications 
> (manager, etc.) for the local host.

You laboring under a misconception - the only ROOT application in Tomcat
is its default welcome page; manager, admin, the examples, etc., are all
deployed as independent applications and are still available even if
ROOT has been replaced.

> Therefore, I decided to have a second virtual host on
> the Tomcat side.

You're going through a lot (a whole lot) more work than you need to.

 - 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 start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: AJP Connector - Problems Proxying HTTPS Connections

2007-02-05 Thread Hassan Schroeder

On 2/5/07, Bill Bailey <[EMAIL PROTECTED]> wrote:


So the context (which I don't want visible to the end users) has
'escaped' into the browser world. I found that this was not a problem if
I made my application appear in the ROOT context for the server, but
didn't want to remove the standard ROOT applications (manager, etc.) for
the local host. Therefore, I decided to have a second virtual host on
the Tomcat side.


whoa, you lost me here. The manager is a separate Context -- there's
no reason you can't have your app as the ROOT context on the default
host. Still,


One of my next tests is going to be to replace this
JSP with a vanilla HTML file to eliminate for certain the possibility
that my application is doing this unwanted redirect, but I'm reasonably
confident that it isn't.


Not a perfect test, since your app might have some Filter doing stuff
that's non-obvious :-)

Anyway, here's my suggestion: replace your current app with a very
skeletal web app, just an index.html, say, so you know there's nothing
wierd going on. Try that. If that still doesn't work, change your httpd
proxy to use mod_proxy_http and forward to your 8080 port.  At the
worst, you can sniff that traffic to see what's really happening :-)

This really shouldn't be this hard  -- I've set up a similar config (but
with multiple virtual hosts) pretty recently, and there was nothing to
it.

HTH,
--
Hassan Schroeder  [EMAIL PROTECTED]

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: AJP Connector - Problems Proxying HTTPS Connections

2007-02-05 Thread Caldarale, Charles R
> From: Bill Bailey [mailto:[EMAIL PROTECTED] 
> Subject: RE: AJP Connector - Problems Proxying HTTPS Connections
> 
> I have a J2EE (Struts) Application running in Tomcat. I want
> to use Apache HTTPD to provide the HTTPS connections and simply
> proxy all requests to the Tomcat container.

It seems like you're going through a lot of unnecessary work & headaches
to put httpd in front of Tomcat; if you don't have some other pressing
need, why not just run Tomcat standalone?  It handles SSL quite nicely.

> Another constraint is that I want the web site to
> be accessible by just its hostname and domain (e.g.
> https://www.resourcepoint.org) and I don't want to
> require a servlet context path to be typed as part
> of the URL every time one accesses the site.

Then simply deploy your application as ROOT.

> I found that this was not a problem if I made my
> application appear in the ROOT context for the server,
> but didn't want to remove the standard ROOT applications 
> (manager, etc.) for the local host.

You laboring under a misconception - the only ROOT application in Tomcat
is its default welcome page; manager, admin, the examples, etc., are all
deployed as independent applications and are still available even if
ROOT has been replaced.

> Therefore, I decided to have a second virtual host on
> the Tomcat side.

You're going through a lot (a whole lot) more work than you need to.

 - 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 start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: AJP Connector - Problems Proxying HTTPS Connections

2007-02-05 Thread Bill Bailey
Chris and Hassan,

I removed the secure and scheme options to no avail; still seeing the
same behavior. Since the waters are getting a bit muddy, let me back up
and say what my goals are and maybe someone can suggest a change in
direction. Let me apologize in advance for the length of this message,
but I did not want to omit any detail that might shed light on the
problem.

I have a J2EE (Struts) Application running in Tomcat. I want to use
Apache HTTPD to provide the HTTPS connections and simply proxy all
requests to the Tomcat container. I want to use Tomcat only as a J2EE
container. I have not even configured SSL on Tomcat nor do I really want
to. I have set up SSL in Apache HTTPD and I can see convincing evidence
in the log files that Apache is accepting connections on port 443 and
attempting to handle them.

Another constraint is that I want the web site to be accessible by just
its hostname and domain (e.g. https://www.resourcepoint.org) and I don't
want to require a servlet context path to be typed as part of the URL
every time one accesses the site. This is why I created the virtual host
on Apache.

However, I found that I had problems if I deployed my application in
Tomcat using other than the ROOT context. The Struts tags I am using all
throughout my application embed the servlet context path in all of the
URL's generated by those tags. This means that a request for

http://www.resourcepoint.org/somefile.jsp

after being forwarded to my Tomcat application (deployed to
/resourcepoint for example) would return a page with embedded URL's that
look like

http://www.resourcepoint.org/resourcepoint/someotherfile.jsp

So the context (which I don't want visible to the end users) has
'escaped' into the browser world. I found that this was not a problem if
I made my application appear in the ROOT context for the server, but
didn't want to remove the standard ROOT applications (manager, etc.) for
the local host. Therefore, I decided to have a second virtual host on
the Tomcat side.

I configured it all as described above initially using just HTTP because
we were only in testing. Everything worked just fine.

I only ran into problems when I configured the additional virtual host
on Apache for SSL. Although Apache shows clearly in its log files that
it has accepted my HTTPS request AND although I can also see clearly in
the Tomcat log files that it has accepted a request on port 8009, the
next thing I see in the Tomcat logs is a redirect to the equivalent
http: URL.

I do not believe the redirect is coming from my application because I
see no evidence it gets far enough for any of my application code to
even execute. The default page for the application is index.jsp and the
redirect I see in the Tomcat logs is for this page, not any of the pages
it might forward to. One of my next tests is going to be to replace this
JSP with a vanilla HTML file to eliminate for certain the possibility
that my application is doing this unwanted redirect, but I'm reasonably
confident that it isn't.

My experimenting with proxyName, proxyPort, scheme, and secure on the
AJP connector were just that: experimentation. I tried almost every
combination including having none of them configured and I got the same
result with all the ones I tried. 

According to my interpretation of the documentation, these attributes
don't do much other than cause Tomcat to return the specified values for
the host, port, scheme, and secure attributes when you call the
corresponding Tomcat API calls (e.g. Request.isSecure(),
Request.getPort(), etc.) so it is not surprising in retrospect that
changing them hasn't altered the behavior.

Finally, I should mention that I have another application deployed on
this same platform (Apache SSL with Tomcat behind) that works perfectly.
The only difference is that in this other application there is no
virtual host on the Tomcat side; the Apache virtual host sends all
requests to the default host using the servlet context path of the
application.

If you've made it this far, thank you for your attention and any help
you can provide will be most appreciated.

Bill Bailey
Senior Developer / DBA
Northland, A Church Distributed

-Original Message-
From: Hassan Schroeder [mailto:[EMAIL PROTECTED] 
Sent: Monday, February 05, 2007 1:26 PM
To: Tomcat Users List
Subject: Re: AJP Connector - Problems Proxying HTTPS Connections

On 2/5/07, Bill Bailey <[EMAIL PROTECTED]> wrote:

> ServerName www.resourcepoint.org:80
> ServerAlias www.resourcepoint.org:80

again, the port # doesn't belong there, and there's no sense
to defining a ServerAlias the same as the ServerName

> # Note that this approach with single argument
> # nested in a Location element works just fine

> ProxyPass ajp://127.0.0.1:8010/
> ProxyPassReverse ajp://127.0.0.1:8010/

Personally I prefer to follow the documentation, even

Re: AJP Connector - Problems Proxying HTTPS Connections

2007-02-05 Thread Hassan Schroeder

On 2/5/07, Bill Bailey <[EMAIL PROTECTED]> wrote:


ServerName www.resourcepoint.org:80
ServerAlias www.resourcepoint.org:80


again, the port # doesn't belong there, and there's no sense
to defining a ServerAlias the same as the ServerName


# Note that this approach with single argument
# nested in a Location element works just fine



ProxyPass ajp://127.0.0.1:8010/
ProxyPassReverse ajp://127.0.0.1:8010/


Personally I prefer to follow the documentation, even when
something "seems to work" otherwise... :-)





+1 on Christopher's comment -- AJP doesn't do https; I would remove
that from this connector and see what happens.

FWIW,
--
Hassan Schroeder  [EMAIL PROTECTED]

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: AJP Connector - Problems Proxying HTTPS Connections

2007-02-05 Thread Rainer Jung

It should be OK, it's not named based virtual hosts in his case.

You should be posting this to the httpd user list, since you are using 
mod_proxy_* and not mod_jk. You might get help here too, but it's more a 
question concerning an httpd standard module.


From general experience: the answer might depend on which component is 
actually producing the redirect: tomcat, you application or some 
framework used. In general the ajp protocol transports knowledge about 
using https on the apache side to your servelt container, such that it 
is able to produce correct self-referring URLs. If the redirect comes 
from some other component, this could produce wrong redirects.


Regards,

Rainer

David Delbecq wrote:

Not speaking of tomcat, as far as i know https and virtual hosting do
not mix very well unless the same certificate is used for all hosts.

En l'instant précis du 02/05/07 15:53, Bill Bailey s'exprimait en ces
termes:

Hi,

 


I am trying to run Tomcat 5.5.20 behind Win32 Apache HTTPD 2.2.4 with
SSL (downloaded from apachelounge.com) using the AJP connector. 

 


I have a virtual host configured on both Tomcat and Apache HTTPD.

 


Everything works fine if I configure my Apache HTTPD virtual host to run
unsecured on port 80, but if I set it up to run secured on port 443, it
appears that when it forwards an https request to Tomcat, Tomcat is
redirecting Apache to http://www.resourcepoint.org
 . If I also have the port 80 virtual
host configured in Apache HTTPD, it simply resubmits the http request to
Tomcat which happily processes it (but obviously this is not what was
wanted since I am now running unsecured). If the Apache HTTPD port 80
virtual host hasn't been configured, Apache can't find a suitable
virtual host and tries to serve up the document from htdocs and, of
course, fails.

 


I can see in Apache HTTPD log files where it is successfully getting the
https request and I can see a connection accepted on port 8009 in the
tomcat log files (followed by a line containing Location =
http://www.resourcepoint.org/index.jsp). Finally, in the case where the
Apache HTTPD port 80 virtual host is not configured I can see entries in
the Apache HTTPD error file where it says the file could not be found in
htdocs (because that isn't where it is).

 

My question is: 

 


Why doesn't Tomcat process this https request? Why is it redirecting
Apache to an http URL? Am I missing some configuration parameter that
I'm unaware of?

 


I have included fragments of both my Apache and Tomcat configuration
files below.

 


Thanks in advance for any assistance you can provide.

 


Bill Bailey

Senior Developer / DBA

Northland, A Church Distributed

 


Apache Virtual Host Configuration Fragment

 


NameVirtualHost xxx.xx.xx.x:443

 




 


  # General setup for the virtual host

 


  ServerName www.resourcepoint.org:443

  DocumentRoot E:\Apache2\vhosts\resourcepoint

  ServerAlias www.resourcepoint.org:443

  ErrorLog logs/resourcepoint-ssl-error_log

  CustomLog logs/resourcepoint-ssl-access_log common

 


  

 


... directory stuff in here ...

 


  

 


  

 


ProxyPass ajp://127.0.0.1:8009/

ProxyPassReverse ajp://127.0.0.1:8009/

 


  

 


  ... SSL stuff here ...



 


Tomcat Virtual Host Configuration Fragment

 




 


  

 


   maxThreads="150" 

 minSpareThreads="25" 


 maxSpareThreads="75"

 enableLookups="false" 


 redirectPort="8443"

 acceptCount="100"

 connectionTimeout="2" 


 disableUploadTimeout="true" />

 


  

 

  

 address="127.0.0.1"

 enableLookups="false"  

 protocol="AJP/1.3" 


 secure="true"

 scheme="https"

 proxyName="www.resourcepoint.org" 


 proxyPort="443" />

 


  

 


  

 




 




 



  appBase="E:\webapps\resourcepoint"

  unpackWARs="true" 


  autoDeploy="true"

  xmlValidation="false" 


  xmlNamespaceAware="false">

 




 


  



 


  

 




 

 



  


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: AJP Connector - Problems Proxying HTTPS Connections

2007-02-05 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bill,

Bill Bailey wrote:
> 

This one is irrelevant to this discussion, right? Your AJP connector is
the only one not working.

> 
>   address="127.0.0.1"
>enableLookups="false"  
>protocol="AJP/1.3" 
>  secure="true"
>  scheme="https"
>  proxyName="www.resourcepoint.org" 
>  proxyPort="443" />

If you are using Apache to do all your SLL, then why do you have
secure="true" and scheme="https" on the AJP connector?

>   address="127.0.0.1"
>enableLookups="false"  
>protocol="AJP/1.3" 
>  secure="false"
>  scheme="http"
>  proxyName="www.resourcepoint.org" 
>  proxyPort="80" />

I'm guessing that you are using this connector and not the other one.
Apache forwards the request to Tomcat, which sees that "secure" is set
to "false", the scheme is "http" and the port is "80". So, it sends a
redirect to get the user /out/ of HTTPS, because it's configured to do so.

I would remove (at least) the secure and scheme attributes from your
connector and try that. Tomcat should not care about the security status
of the browser->Apache httpd connection.

I believe this is the problem.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFx2Gk9CaO5/Lv0PARAsSYAKCL4NV8TiuBU28LTCyWbRgExa5wCgCgnMKS
PraT19n7TGcvoE4MjMpQ470=
=mkHX
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: AJP Connector - Problems Proxying HTTPS Connections

2007-02-05 Thread Bill Bailey
Thanks for your suggestions. However, I still have the same problem.

I removed the NameVirtualHost entry for port 443, removed the port from
the ServerName, removed the DocumentRoot and ServerAlias completely, and
added the / to both the ProxyPass and ProxyPassReverse entries after
removing the Location element (I should mention that I had tried that
previously and then changed to the single argument version inside a
Location / element as an experiment which, by the way, works fine as
long as the connection is via port 80). In fact, several of the things I
changed this time around were introduced by my desperation to find some
combination that works.

I still get the same problem. If I connect to https: I am immediately
redirected to the http: version of the URL. If the port 80 virtual host
is set up under Apache HTTPD it processes it and if not, I get an error
saying Apache could not find whatever file I'm trying to access.

I also want to emphasize that the connection to Apache via SSL is
working fine. I see the entries in the log files indicating Apache got
the request. I can even see in the Tomcat logs where Apache forwarded
the request on the port specified in the ProxyPass directives. But ... I
can also see an entry in the Tomcat log where it appears to send a
redirect using http: as the scheme. Thus, my conclusion that it is my
Tomcat configuration rather than my Apache HTTPD configuration that is
the cause of the problem.

I have pasted the latest fragments of the Apache HTTPD configuration
files below in case I've still missed the point of one or more of your
comments.

The only change to the Tomcat configuration is the addition of a
separate AJP connector specifically for the unsecured connection.

Thanks for any additional ideas or input.

Apache HTTPD Configuration Fragments



##
## SSL Virtual Host Context
##


# General setup for the virtual host

ServerName www.resourcepoint.org
ErrorLog logs/resourcepoint-ssl-error_log
CustomLog logs/resourcepoint-ssl-access_log common



... directory stuff here ...



ProxyPass / ajp://127.0.0.1:8009/
ProxyPassReverse / ajp://127.0.0.1:8009/

... SSL stuff here ...



Just in case it helps, here is the port 80 virtual host configuration
which works just fine.

#
# Use name-based virtual hosting.
#
NameVirtualHost 172.30.90.2:80

#
# VirtualHost
#


ServerName www.resourcepoint.org:80
DocumentRoot E:\Apache2\vhosts\resourcepoint
ServerAlias www.resourcepoint.org:80
ErrorLog logs/resourcepoint-error_log
CustomLog logs/resourcepoint-access_log common



... directory stuff here ...



# Note that this approach with single argument
# nested in a Location element works just fine
# for the non-SSL, port 80 virtual host.



ProxyPass ajp://127.0.0.1:8010/
ProxyPassReverse ajp://127.0.0.1:8010/





Tomcat Configuration (Server.xml)
==

  






 








  

  

  








-Original Message-
From: Hassan Schroeder [mailto:[EMAIL PROTECTED] 
Sent: Monday, February 05, 2007 11:11 AM
To: Tomcat Users List
Subject: Re: AJP Connector - Problems Proxying HTTPS Connections

On 2/5/07, Bill Bailey <[EMAIL PROTECTED]> wrote:

To start with --

> Apache Virtual Host Configuration Fragment

> NameVirtualHost xxx.xx.xx.x:443

NameVirtualHosting and SSL don't go together -- yank that

> 

Put the real IP that belongs to the SSL cert there

>   ServerName www.resourcepoint.org:443
>
>   DocumentRoot E:\Apache2\vhosts\resourcepoint
>
>   ServerAlias www.resourcepoint.org:443

The server name and alias should not have the port # appended
In the example, the name and alias are the same, which makes no
sense. And if you're proxying everything, you don't need to specify
a DocumentRoot. However,

> ProxyPass ajp://127.0.0.1:8009/
> ProxyPassReverse ajp://127.0.0.1:8009/

that's wrong -- those two directives take two arguments, e.g

   ProxyPass / ajp://127.0.0.1:8009

Fix those, and make sure your config files at least passes the config
test ( $APACHE_HOME/bin/apachectl -t )

HTH!
-- 
Hassan Schroeder  [EMAIL PROTECTED]

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: AJP Connector - Problems Proxying HTTPS Connections

2007-02-05 Thread Hassan Schroeder

On 2/5/07, Bill Bailey <[EMAIL PROTECTED]> wrote:

To start with --


Apache Virtual Host Configuration Fragment



NameVirtualHost xxx.xx.xx.x:443


NameVirtualHosting and SSL don't go together -- yank that





Put the real IP that belongs to the SSL cert there


  ServerName www.resourcepoint.org:443

  DocumentRoot E:\Apache2\vhosts\resourcepoint

  ServerAlias www.resourcepoint.org:443


The server name and alias should not have the port # appended
In the example, the name and alias are the same, which makes no
sense. And if you're proxying everything, you don't need to specify
a DocumentRoot. However,


ProxyPass ajp://127.0.0.1:8009/
ProxyPassReverse ajp://127.0.0.1:8009/


that's wrong -- those two directives take two arguments, e.g

  ProxyPass / ajp://127.0.0.1:8009

Fix those, and make sure your config files at least passes the config
test ( $APACHE_HOME/bin/apachectl -t )

HTH!
--
Hassan Schroeder  [EMAIL PROTECTED]

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: AJP Connector - Problems Proxying HTTPS Connections

2007-02-05 Thread David Delbecq
Not speaking of tomcat, as far as i know https and virtual hosting do
not mix very well unless the same certificate is used for all hosts.

En l'instant précis du 02/05/07 15:53, Bill Bailey s'exprimait en ces
termes:
> Hi,
>
>  
>
> I am trying to run Tomcat 5.5.20 behind Win32 Apache HTTPD 2.2.4 with
> SSL (downloaded from apachelounge.com) using the AJP connector. 
>
>  
>
> I have a virtual host configured on both Tomcat and Apache HTTPD.
>
>  
>
> Everything works fine if I configure my Apache HTTPD virtual host to run
> unsecured on port 80, but if I set it up to run secured on port 443, it
> appears that when it forwards an https request to Tomcat, Tomcat is
> redirecting Apache to http://www.resourcepoint.org
>  . If I also have the port 80 virtual
> host configured in Apache HTTPD, it simply resubmits the http request to
> Tomcat which happily processes it (but obviously this is not what was
> wanted since I am now running unsecured). If the Apache HTTPD port 80
> virtual host hasn't been configured, Apache can't find a suitable
> virtual host and tries to serve up the document from htdocs and, of
> course, fails.
>
>  
>
> I can see in Apache HTTPD log files where it is successfully getting the
> https request and I can see a connection accepted on port 8009 in the
> tomcat log files (followed by a line containing Location =
> http://www.resourcepoint.org/index.jsp). Finally, in the case where the
> Apache HTTPD port 80 virtual host is not configured I can see entries in
> the Apache HTTPD error file where it says the file could not be found in
> htdocs (because that isn't where it is).
>
>  
>
> My question is: 
>
>  
>
> Why doesn't Tomcat process this https request? Why is it redirecting
> Apache to an http URL? Am I missing some configuration parameter that
> I'm unaware of?
>
>  
>
> I have included fragments of both my Apache and Tomcat configuration
> files below.
>
>  
>
> Thanks in advance for any assistance you can provide.
>
>  
>
> Bill Bailey
>
> Senior Developer / DBA
>
> Northland, A Church Distributed
>
>  
>
> Apache Virtual Host Configuration Fragment
>
>  
>
> NameVirtualHost xxx.xx.xx.x:443
>
>  
>
> 
>
>  
>
>   # General setup for the virtual host
>
>  
>
>   ServerName www.resourcepoint.org:443
>
>   DocumentRoot E:\Apache2\vhosts\resourcepoint
>
>   ServerAlias www.resourcepoint.org:443
>
>   ErrorLog logs/resourcepoint-ssl-error_log
>
>   CustomLog logs/resourcepoint-ssl-access_log common
>
>  
>
>   
>
>  
>
> ... directory stuff in here ...
>
>  
>
>   
>
>  
>
>   
>
>  
>
> ProxyPass ajp://127.0.0.1:8009/
>
> ProxyPassReverse ajp://127.0.0.1:8009/
>
>  
>
>   
>
>  
>
>   ... SSL stuff here ...
>
> 
>
>  
>
> Tomcat Virtual Host Configuration Fragment
>
>  
>
> 
>
>  
>
>   
>
>  
>
>   
>  address="127.0.0.1"
>
>  maxHttpHeaderSize="8192"
>
>  maxThreads="150" 
>
>  minSpareThreads="25" 
>
>  maxSpareThreads="75"
>
>  enableLookups="false" 
>
>  redirectPort="8443"
>
>  acceptCount="100"
>
>  connectionTimeout="2" 
>
>  disableUploadTimeout="true" />
>
>  
>
>   
>
>  
>
>   
>  address="127.0.0.1"
>
>  enableLookups="false"  
>
>  protocol="AJP/1.3" 
>
>  secure="true"
>
>  scheme="https"
>
>  proxyName="www.resourcepoint.org" 
>
>  proxyPort="443" />
>
>  
>
>   
>
>  
>
>   
>
>  
>
>  resourceName="UserDatabase" />
>
>  
>
> 
>
>  
>
> 
>   appBase="E:\webapps\resourcepoint"
>
>   unpackWARs="true" 
>
>   autoDeploy="true"
>
>   xmlValidation="false" 
>
>   xmlNamespaceAware="false">
>
>  
>
> 
>
>  
>
>   
>
> 
>
>  
>
>   
>
>  
>
> 
>
>  
>
>  
>
>
>   


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



AJP Connector - Problems Proxying HTTPS Connections

2007-02-05 Thread Bill Bailey
Hi,

 

I am trying to run Tomcat 5.5.20 behind Win32 Apache HTTPD 2.2.4 with
SSL (downloaded from apachelounge.com) using the AJP connector. 

 

I have a virtual host configured on both Tomcat and Apache HTTPD.

 

Everything works fine if I configure my Apache HTTPD virtual host to run
unsecured on port 80, but if I set it up to run secured on port 443, it
appears that when it forwards an https request to Tomcat, Tomcat is
redirecting Apache to http://www.resourcepoint.org
 . If I also have the port 80 virtual
host configured in Apache HTTPD, it simply resubmits the http request to
Tomcat which happily processes it (but obviously this is not what was
wanted since I am now running unsecured). If the Apache HTTPD port 80
virtual host hasn't been configured, Apache can't find a suitable
virtual host and tries to serve up the document from htdocs and, of
course, fails.

 

I can see in Apache HTTPD log files where it is successfully getting the
https request and I can see a connection accepted on port 8009 in the
tomcat log files (followed by a line containing Location =
http://www.resourcepoint.org/index.jsp). Finally, in the case where the
Apache HTTPD port 80 virtual host is not configured I can see entries in
the Apache HTTPD error file where it says the file could not be found in
htdocs (because that isn't where it is).

 

My question is: 

 

Why doesn't Tomcat process this https request? Why is it redirecting
Apache to an http URL? Am I missing some configuration parameter that
I'm unaware of?

 

I have included fragments of both my Apache and Tomcat configuration
files below.

 

Thanks in advance for any assistance you can provide.

 

Bill Bailey

Senior Developer / DBA

Northland, A Church Distributed

 

Apache Virtual Host Configuration Fragment

 

NameVirtualHost xxx.xx.xx.x:443

 



 

  # General setup for the virtual host

 

  ServerName www.resourcepoint.org:443

  DocumentRoot E:\Apache2\vhosts\resourcepoint

  ServerAlias www.resourcepoint.org:443

  ErrorLog logs/resourcepoint-ssl-error_log

  CustomLog logs/resourcepoint-ssl-access_log common

 

  

 

... directory stuff in here ...

 

  

 

  

 

ProxyPass ajp://127.0.0.1:8009/

ProxyPassReverse ajp://127.0.0.1:8009/

 

  

 

  ... SSL stuff here ...



 

Tomcat Virtual Host Configuration Fragment

 



 

  

 

  

 

  

 

  

 

  

 

  

 



 



 



 



 

  



 

  

 



 

 



Re: jk connector problems

2006-11-15 Thread brian bay

did you try setting the default host in the workers.properties file to the
actual host you want apache to forward to tomcat?

worker.default.host = 10.x.x.x
instead of
worker.default.host=127.0.0.1




Brian


On 11/15/06, Martin Gainty <[EMAIL PROTECTED]> wrote:


The connectors tutorial is located at
http://tomcat.apache.org/connectors-doc/howto/apache.html

be sure to Read the howto at
http://tomcat.apache.org/connectors-doc/howto/workers.html

Assuming you are not using auto-conf I would use the supplied
workers.properties from the supplied connectors tutorial
If you follow instructions previously mentioned to setup JkMount in your
workers.properties you should only forward those requests identified in
JkMount

be aware that when you configure in multiple workers through loadbalance
the higher lbfactor is favored over lower
worker.worker2.lbfactor=3
worker.worker1.lbfactor=2
(worker2 is favored to handle incoming request over worker1)

Viel Gluck,
Martin
This e-mail communication and any attachments may contain confidential and
privileged information for the use of the
designated recipients named above. If you are not the intended recipient,
you are hereby notified that you have received
this communication in error and that any review, disclosure,
dissemination, distribution or copying of it or its
contents
- Original Message -
From: "Rainer Jung" <[EMAIL PROTECTED]>
To: "Tomcat Users List" 
Sent: Wednesday, November 15, 2006 2:44 AM
Subject: Re: jk connector problems


> Hi Martin,
>
> these lines only mean, that mod_jk is checking whether it should forward
> the request or not, but it doesn't find a match (=JkMount), so it
> decides to let other apache modules handle the request. This part of
> request processing is normal, even if there is no JkMount.
>
> Regards,
>
> Rainer
>
>
> Martin Hochreiter schrieb:
>> Rainer Jung schrieb:
>>> Hi,
>>>
>>> Martin Hochreiter schrieb:
>>>
>>>> Hi!
>>>>
>>>> I have some problems with Tomcat & JK Connector and Apache Virtual
>>>> hosts.
>>>>
>>>> Apache should only give requests of one virtual host to the jk
>>>> connector, but
>>>> it handles all requests over to the jk connector, no matter what
host.
>>>>
>>>
>>> I didn't try your config, but it looks like the config is OK. The
first
>>> virtual server should not forward any requests, the second one should
>>> forward all requests.
>>>
>>>
>>>> Actually the log files of jkerror.log are very big - and getting
bigger.
>>>>
>>>
>>> You've not JkLogLevel statement. The docs say it's default is INFO,
but
>>> some versions of mod_jk are broken with respect to the default log
level
>>> and take debug or trace instead. Please add an explicit "JkLogLevel
>>> info" to the config.
>>>
>>>
>>>> As jk could not map the uri of other virtual hosts, it gives the
request
>>>> back to apache (or something) and the right page opens, but I don't
>>>> want apache to handle all requests of all virtual hosts to the
>>>> connector.
>>>>
>>>
>>> Are you sure that mod_jk actually tries to forward the requests for
the
>>> first virtual host? Maybe you are only mislead by the debug logging
int
>>> the log file. Of course mod_jk will look at the requests (and log some
>>> debug lines) even, if it later decides not to forward a request via a
>>> worker.
>>>
>>>
>>>> Can somebody please give me  hint?
>>>>
>>>
>>> Lower your log level and try to make more explicit, why you think,
that
>>> mod_jk forwards all requests for both virtual servers.
>>>
>>> Regards,
>>>
>>> Rainer
>>>
>> Hello Rainer!
>>
>> I will lower the log level and monitor the issue -
>> I think that the connector gets every request because of
>> these lines in jkerror.log:
>>
>> [Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (618)]:
>> jk_uri_worker_map_t::map_uri_to_worker, done without a match
>> [Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (486)]: Into
>> jk_uri_worker_map_t::map_uri_to_worker
>> [Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (500)]: Attempting to
>> map URI '/error/include/top.html'
>> [Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (618)]:
>> jk_uri_worker_map_t::map_uri_to_worker, done without a match
>> [Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (486)]: Into
>> jk_uri_worker_map

Re: jk connector problems

2006-11-15 Thread Martin Gainty
The connectors tutorial is located at
http://tomcat.apache.org/connectors-doc/howto/apache.html

be sure to Read the howto at
http://tomcat.apache.org/connectors-doc/howto/workers.html

Assuming you are not using auto-conf I would use the supplied 
workers.properties from the supplied connectors tutorial
If you follow instructions previously mentioned to setup JkMount in your 
workers.properties you should only forward those requests identified in JkMount

be aware that when you configure in multiple workers through loadbalance the 
higher lbfactor is favored over lower 
worker.worker2.lbfactor=3
worker.worker1.lbfactor=2
(worker2 is favored to handle incoming request over worker1)

Viel Gluck,
Martin
This e-mail communication and any attachments may contain confidential and 
privileged information for the use of the 
designated recipients named above. If you are not the intended recipient, you 
are hereby notified that you have received
this communication in error and that any review, disclosure, dissemination, 
distribution or copying of it or its 
contents
- Original Message - 
From: "Rainer Jung" <[EMAIL PROTECTED]>
To: "Tomcat Users List" 
Sent: Wednesday, November 15, 2006 2:44 AM
Subject: Re: jk connector problems


> Hi Martin,
> 
> these lines only mean, that mod_jk is checking whether it should forward
> the request or not, but it doesn't find a match (=JkMount), so it
> decides to let other apache modules handle the request. This part of
> request processing is normal, even if there is no JkMount.
> 
> Regards,
> 
> Rainer
> 
> 
> Martin Hochreiter schrieb:
>> Rainer Jung schrieb:
>>> Hi,
>>>
>>> Martin Hochreiter schrieb:
>>>  
>>>> Hi!
>>>>
>>>> I have some problems with Tomcat & JK Connector and Apache Virtual
>>>> hosts.
>>>>
>>>> Apache should only give requests of one virtual host to the jk
>>>> connector, but
>>>> it handles all requests over to the jk connector, no matter what host.
>>>> 
>>>
>>> I didn't try your config, but it looks like the config is OK. The first
>>> virtual server should not forward any requests, the second one should
>>> forward all requests.
>>>
>>>  
>>>> Actually the log files of jkerror.log are very big - and getting bigger.
>>>> 
>>>
>>> You've not JkLogLevel statement. The docs say it's default is INFO, but
>>> some versions of mod_jk are broken with respect to the default log level
>>> and take debug or trace instead. Please add an explicit "JkLogLevel
>>> info" to the config.
>>>
>>>  
>>>> As jk could not map the uri of other virtual hosts, it gives the request
>>>> back to apache (or something) and the right page opens, but I don't
>>>> want apache to handle all requests of all virtual hosts to the
>>>> connector.
>>>> 
>>>
>>> Are you sure that mod_jk actually tries to forward the requests for the
>>> first virtual host? Maybe you are only mislead by the debug logging int
>>> the log file. Of course mod_jk will look at the requests (and log some
>>> debug lines) even, if it later decides not to forward a request via a
>>> worker.
>>>
>>>  
>>>> Can somebody please give me  hint?
>>>> 
>>>
>>> Lower your log level and try to make more explicit, why you think, that
>>> mod_jk forwards all requests for both virtual servers.
>>>
>>> Regards,
>>>
>>> Rainer
>>> 
>> Hello Rainer!
>> 
>> I will lower the log level and monitor the issue -
>> I think that the connector gets every request because of
>> these lines in jkerror.log:
>> 
>> [Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (618)]:
>> jk_uri_worker_map_t::map_uri_to_worker, done without a match
>> [Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (486)]: Into
>> jk_uri_worker_map_t::map_uri_to_worker
>> [Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (500)]: Attempting to
>> map URI '/error/include/top.html'
>> [Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (618)]:
>> jk_uri_worker_map_t::map_uri_to_worker, done without a match
>> [Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (486)]: Into
>> jk_uri_worker_map_t::map_uri_to_worker
>> [Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (500)]: Attempting to
>> map URI '/error/include/bottom.html'
>> [Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (618)]:
>> jk_uri_work

Re: jk connector problems

2006-11-15 Thread Mladen Turk

Martin Hochreiter wrote:


I'll see, I "solved" it with another way:

I simply kicked out mod_jk and use mod_proxy.
The performance is a significant better.



Great. You can at least say that you are
the first one!
Please give us some benchmark results.

Cheers,
Mladen.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: jk connector problems

2006-11-15 Thread Martin Hochreiter

Rainer Jung schrieb:

Hi Martin,

these lines only mean, that mod_jk is checking whether it should forward
the request or not, but it doesn't find a match (=JkMount), so it
decides to let other apache modules handle the request. This part of
request processing is normal, even if there is no JkMount.

Regards,

Rainer
  


I'll see, I "solved" it with another way:

I simply kicked out mod_jk and use mod_proxy.
The performance is a significant better.

lg

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: jk connector problems

2006-11-14 Thread Rainer Jung
Hi Martin,

these lines only mean, that mod_jk is checking whether it should forward
the request or not, but it doesn't find a match (=JkMount), so it
decides to let other apache modules handle the request. This part of
request processing is normal, even if there is no JkMount.

Regards,

Rainer


Martin Hochreiter schrieb:
> Rainer Jung schrieb:
>> Hi,
>>
>> Martin Hochreiter schrieb:
>>  
>>> Hi!
>>>
>>> I have some problems with Tomcat & JK Connector and Apache Virtual
>>> hosts.
>>>
>>> Apache should only give requests of one virtual host to the jk
>>> connector, but
>>> it handles all requests over to the jk connector, no matter what host.
>>> 
>>
>> I didn't try your config, but it looks like the config is OK. The first
>> virtual server should not forward any requests, the second one should
>> forward all requests.
>>
>>  
>>> Actually the log files of jkerror.log are very big - and getting bigger.
>>> 
>>
>> You've not JkLogLevel statement. The docs say it's default is INFO, but
>> some versions of mod_jk are broken with respect to the default log level
>> and take debug or trace instead. Please add an explicit "JkLogLevel
>> info" to the config.
>>
>>  
>>> As jk could not map the uri of other virtual hosts, it gives the request
>>> back to apache (or something) and the right page opens, but I don't
>>> want apache to handle all requests of all virtual hosts to the
>>> connector.
>>> 
>>
>> Are you sure that mod_jk actually tries to forward the requests for the
>> first virtual host? Maybe you are only mislead by the debug logging int
>> the log file. Of course mod_jk will look at the requests (and log some
>> debug lines) even, if it later decides not to forward a request via a
>> worker.
>>
>>  
>>> Can somebody please give me  hint?
>>> 
>>
>> Lower your log level and try to make more explicit, why you think, that
>> mod_jk forwards all requests for both virtual servers.
>>
>> Regards,
>>
>> Rainer
>> 
> Hello Rainer!
> 
> I will lower the log level and monitor the issue -
> I think that the connector gets every request because of
> these lines in jkerror.log:
> 
> [Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (618)]:
> jk_uri_worker_map_t::map_uri_to_worker, done without a match
> [Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (486)]: Into
> jk_uri_worker_map_t::map_uri_to_worker
> [Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (500)]: Attempting to
> map URI '/error/include/top.html'
> [Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (618)]:
> jk_uri_worker_map_t::map_uri_to_worker, done without a match
> [Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (486)]: Into
> jk_uri_worker_map_t::map_uri_to_worker
> [Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (500)]: Attempting to
> map URI '/error/include/bottom.html'
> [Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (618)]:
> jk_uri_worker_map_t::map_uri_to_worker, done without a match
> [Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (486)]: Into
> jk_uri_worker_map_t::map_uri_to_worker
> [Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (500)]: Attempting to
> map URI '/error/contact.html.var'
> [Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (618)]:
> jk_uri_worker_map_t::map_uri_to_worker, done without a match
> 
> This are requests to the first virtual host and I don't understand why
> apache handles
> that requests over to the connector.
> 
> 
> -
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: jk connector problems

2006-11-14 Thread Martin Hochreiter

Rainer Jung schrieb:

Hi,

Martin Hochreiter schrieb:
  

Hi!

I have some problems with Tomcat & JK Connector and Apache Virtual hosts.

Apache should only give requests of one virtual host to the jk
connector, but
it handles all requests over to the jk connector, no matter what host.



I didn't try your config, but it looks like the config is OK. The first
virtual server should not forward any requests, the second one should
forward all requests.

  

Actually the log files of jkerror.log are very big - and getting bigger.



You've not JkLogLevel statement. The docs say it's default is INFO, but
some versions of mod_jk are broken with respect to the default log level
and take debug or trace instead. Please add an explicit "JkLogLevel
info" to the config.

  

As jk could not map the uri of other virtual hosts, it gives the request
back to apache (or something) and the right page opens, but I don't
want apache to handle all requests of all virtual hosts to the connector.



Are you sure that mod_jk actually tries to forward the requests for the
first virtual host? Maybe you are only mislead by the debug logging int
the log file. Of course mod_jk will look at the requests (and log some
debug lines) even, if it later decides not to forward a request via a
worker.

  

Can somebody please give me  hint?



Lower your log level and try to make more explicit, why you think, that
mod_jk forwards all requests for both virtual servers.

Regards,

Rainer
  
  

Hello Rainer!

I will lower the log level and monitor the issue -
I think that the connector gets every request because of
these lines in jkerror.log:

[Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (618)]: 
jk_uri_worker_map_t::map_uri_to_worker, done without a match
[Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (486)]: Into 
jk_uri_worker_map_t::map_uri_to_worker
[Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (500)]: Attempting to 
map URI '/error/include/top.html'
[Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (618)]: 
jk_uri_worker_map_t::map_uri_to_worker, done without a match
[Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (486)]: Into 
jk_uri_worker_map_t::map_uri_to_worker
[Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (500)]: Attempting to 
map URI '/error/include/bottom.html'
[Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (618)]: 
jk_uri_worker_map_t::map_uri_to_worker, done without a match
[Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (486)]: Into 
jk_uri_worker_map_t::map_uri_to_worker
[Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (500)]: Attempting to 
map URI '/error/contact.html.var'
[Wed Nov 15 07:15:09 2006]  [jk_uri_worker_map.c (618)]: 
jk_uri_worker_map_t::map_uri_to_worker, done without a match


This are requests to the first virtual host and I don't understand why 
apache handles

that requests over to the connector.


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: jk connector problems

2006-11-14 Thread Rainer Jung
Hi,

Martin Hochreiter schrieb:
> Hi!
> 
> I have some problems with Tomcat & JK Connector and Apache Virtual hosts.
> 
> Apache should only give requests of one virtual host to the jk
> connector, but
> it handles all requests over to the jk connector, no matter what host.

I didn't try your config, but it looks like the config is OK. The first
virtual server should not forward any requests, the second one should
forward all requests.

> Actually the log files of jkerror.log are very big - and getting bigger.

You've not JkLogLevel statement. The docs say it's default is INFO, but
some versions of mod_jk are broken with respect to the default log level
and take debug or trace instead. Please add an explicit "JkLogLevel
info" to the config.

> 
> As jk could not map the uri of other virtual hosts, it gives the request
> back to apache (or something) and the right page opens, but I don't
> want apache to handle all requests of all virtual hosts to the connector.

Are you sure that mod_jk actually tries to forward the requests for the
first virtual host? Maybe you are only mislead by the debug logging int
the log file. Of course mod_jk will look at the requests (and log some
debug lines) even, if it later decides not to forward a request via a
worker.

> 
> Can somebody please give me  hint?

Lower your log level and try to make more explicit, why you think, that
mod_jk forwards all requests for both virtual servers.

Regards,

Rainer

> 
> 
> I have configured apache like that:
> 
>  http443.conf 
> NameVirtualHost 10.0.0.6:443
> 
>ScriptAlias /otrs/ "/opt/otrs/bin/cgi-bin/"
>Alias /otrs-web/ "/opt/otrs/var/httpd/htdocs/"
>Perlrequire /opt/otrs/scripts/apache2-perl-startup.pl
>PerlModule Apache2::Reload
>PerlInitHandler Apache2::Reload
>PerlModule Apache2::RequestRec
>ErrorLog /var/log/apache2/httpserror_log
>TransferLog /var/log/apache2/httpsaccess_log
>SSLEngine on
>SSLCipherSuite
> ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
>SSLCertificateFile /etc/apache2/ssl.crt/otrs.crt
>SSLCertificateKeyFile /etc/apache2/ssl.key/otrs.key
>
>SSLOptions +StdEnvVars
>
>
>SSLOptions +StdEnvVars
>
>SetEnvIf User-Agent ".*MSIE.*" \
> nokeepalive ssl-unclean-shutdown \
> downgrade-1.0 force-response-1.0
>CustomLog /var/log/apache2/ssl_request_log   ssl_combined
>ServerName XXX1.xx
>DocumentRoot /opt/otrs/var/httpd/htdocs/
>
>ErrorDocument 403 /otrs/index.pl
>SetHandler  perl-script
>PerlResponseHandler ModPerl::Registry
>Options +ExecCGI
>PerlOptions +ParseHeaders
>PerlOptions +SetupEnv
>Order allow,deny
>Allow from all
>
> 
># directory settings
>
>AllowOverride None
>Options +ExecCGI -Includes
>Order allow,deny
>Allow from all
>
>
>AllowOverride None
>Order allow,deny
>Allow from all
>
>SetEnvIf Request_URI "/*" no-jk
> 
> 
> NameVirtualHost 10.0.0.3:443
> 
>ErrorLog /var/log/apache2/httpserror_log
>TransferLog /var/log/apache2/httpsaccess_log
>ServerName XXX.xx
>SSLEngine on
>SSLCipherSuite
> ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
>SSLCertificateFile /etc/apache2/ssl.crt/intranet.crt
>SSLCertificateKeyFile /etc/apache2/ssl.key/intranet.key
>SetEnvIf User-Agent ".*MSIE.*" \
> nokeepalive ssl-unclean-shutdown \
> downgrade-1.0 force-response-1.0
>CustomLog /var/log/apache2/ssl_request_log   ssl_combined
>JkMount /* default
> 
> -
> 
> in http.conf you read:
> 
> 
> 
> 
> JkWorkersFile "/etc/apache2/workers.properties"
> JkLogFile "/opt/xtreme/tomcat/logs/mod_jk.log"
> JkLogFile /var/log/apache2/jkerror.log
> 
> 
> and at least the workers.properies
> 
> --
>workers.tomcat_home=/opt/xtreme/tomcat
>   ps=/
>   worker.list=default
>   worker.default.port=8009
>   worker.default.host=127.0.0.1
>   worker.default.type=ajp13
>   worker.default.lbfactor=1
> --
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional co

jk connector problems

2006-11-14 Thread Martin Hochreiter

Hi!

I have some problems with Tomcat & JK Connector and Apache Virtual hosts.

Apache should only give requests of one virtual host to the jk 
connector, but

it handles all requests over to the jk connector, no matter what host.
Actually the log files of jkerror.log are very big - and getting bigger.

As jk could not map the uri of other virtual hosts, it gives the request
back to apache (or something) and the right page opens, but I don't
want apache to handle all requests of all virtual hosts to the connector.

Can somebody please give me  hint?


I have configured apache like that:

 http443.conf 
NameVirtualHost 10.0.0.6:443

   ScriptAlias /otrs/ "/opt/otrs/bin/cgi-bin/"
   Alias /otrs-web/ "/opt/otrs/var/httpd/htdocs/"
   Perlrequire /opt/otrs/scripts/apache2-perl-startup.pl
   PerlModule Apache2::Reload
   PerlInitHandler Apache2::Reload
   PerlModule Apache2::RequestRec
   ErrorLog /var/log/apache2/httpserror_log
   TransferLog /var/log/apache2/httpsaccess_log
   SSLEngine on
   SSLCipherSuite 
ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

   SSLCertificateFile /etc/apache2/ssl.crt/otrs.crt
   SSLCertificateKeyFile /etc/apache2/ssl.key/otrs.key
   
   SSLOptions +StdEnvVars
   
   
   SSLOptions +StdEnvVars
   
   SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
   CustomLog /var/log/apache2/ssl_request_log   ssl_combined
   ServerName XXX1.xx
   DocumentRoot /opt/otrs/var/httpd/htdocs/
   
   ErrorDocument 403 /otrs/index.pl
   SetHandler  perl-script
   PerlResponseHandler ModPerl::Registry
   Options +ExecCGI
   PerlOptions +ParseHeaders
   PerlOptions +SetupEnv
   Order allow,deny
   Allow from all
   

   # directory settings
   
   AllowOverride None
   Options +ExecCGI -Includes
   Order allow,deny
   Allow from all
   
   
   AllowOverride None
   Order allow,deny
   Allow from all
   
   SetEnvIf Request_URI "/*" no-jk


NameVirtualHost 10.0.0.3:443

   ErrorLog /var/log/apache2/httpserror_log
   TransferLog /var/log/apache2/httpsaccess_log
   ServerName XXX.xx
   SSLEngine on
   SSLCipherSuite 
ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

   SSLCertificateFile /etc/apache2/ssl.crt/intranet.crt
   SSLCertificateKeyFile /etc/apache2/ssl.key/intranet.key
   SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
   CustomLog /var/log/apache2/ssl_request_log   ssl_combined
   JkMount /* default

-

in http.conf you read:




JkWorkersFile "/etc/apache2/workers.properties"
JkLogFile "/opt/xtreme/tomcat/logs/mod_jk.log"
JkLogFile /var/log/apache2/jkerror.log


and at least the workers.properies

--
   workers.tomcat_home=/opt/xtreme/tomcat
  ps=/
  worker.list=default
  worker.default.port=8009
  worker.default.host=127.0.0.1
  worker.default.type=ajp13
  worker.default.lbfactor=1
--









-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Connector Problems -

2006-08-08 Thread Mark Eggers
I just checked - it's copied exactly.  Sometimes I
drop characters when copying from emacs to Firefox.

Please see the following link under Mandatory
Directives

http://tomcat.apache.org/connectors-doc/config/workers.html

Also, LoadModule must be used in the server config and
not in the VirtualHost directive.  If you have Apache
and its documentation installed locally, please see:

http://localhost/manual/mod/mod_so.html#loadmodule
http://localhost/manual/mod/directive-dict.html#Context

HTH

/mde/
just my two cents . . . .


--- "M. Goodell" <[EMAIL PROTECTED]> wrote:

> In looking at your config, I see that the word
> "type" is spelled "typw" Was this copied directly
> from your actual config file?
>
>   worker.worker1.typw=ajp13
> 
> Just wondering . . .


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Connector Problems - FIXED!! THANK EVERYONE!!

2006-08-08 Thread M. Goodell
ffer 
size:  0
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] jk_ajp_common.c (1980): pool 
timeout: 0
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] jk_ajp_common.c (1984): connect 
timeout:  0
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] jk_ajp_common.c (1988): reply 
timeout:0
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] jk_ajp_common.c (1992): prepost 
timeout:  0
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] jk_ajp_common.c (1996): recovery 
options: 0
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] jk_ajp_common.c (2000): retries: 
 2
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] jk_ajp_common.c (1879): setting 
connection pool size to 250 with min 125
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] jk_shm.c (135): Initialized 
shared memory size=24704 free=24576 addr=0xd2e9d8
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] mod_jk.c (2355): Initialized 
shm:memory
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] jk_uri_worker_map.c (361): rule 
map size is 0
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] jk_worker.c (236): creating 
worker worker1
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] jk_worker.c (141): about to 
create instance worker1 of ajp13
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] jk_worker.c (154): about to 
validate and init worker1
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] jk_ajp_common.c (1842): worker 
worker1 contact is 'localhost:8009'
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] jk_ajp_common.c (1965): setting 
endpoint options:
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] jk_ajp_common.c (1968): 
keepalive:0
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] jk_ajp_common.c (1972): timeout: 
 -1
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] jk_ajp_common.c (1976): buffer 
size:  0
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] jk_ajp_common.c (1980): pool 
timeout: 0
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] jk_ajp_common.c (1984): connect 
timeout:  0
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] jk_ajp_common.c (1988): reply 
timeout:0
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] jk_ajp_common.c (1992): prepost 
timeout:  0
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] jk_ajp_common.c (1996): recovery 
options: 0
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] jk_ajp_common.c (2000): retries: 
 2
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] jk_ajp_common.c (1879): setting 
connection pool size to 250 with min 125
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] jk_shm.c (87): Shared memory is 
already opened
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] jk_shm.c (149): Attached shared 
memory [1] size=24576 free=24576 addr=0xd2e9d8
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] mod_jk.c (2311): Attached 
shm:memory
[Tue Aug 08 15:09:24 2006] [0176:1648] [debug] mod_jk.c (2321): Initialized 
mod_jk/1.2.18


fredk2 <[EMAIL PROTECTED]> wrote:
  
could it be that the loading of the module and the related configuration
?must? be outside of the section ?

LoadModule jk_module modules/mod_jk.so 
kWorkersFile conf/workers.properties 
JkLogFile logs/mod_jk.log 
JkLogLevel debug 

-- 
View this message in context: 
http://www.nabble.com/Connector-Problems---tf2074658.html#a5714885
Sent from the Tomcat - User forum at Nabble.com.


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ 
countries) for 2¢/min or less.

Re: Connector Problems -

2006-08-08 Thread M. Goodell
In looking at your config, I see that the word "type" is spelled "typw" Was 
this copied directly from your actual config file?
   
  worker.worker1.typw=ajp13

Just wondering . . .
  
Mark Eggers <[EMAIL PROTECTED]> wrote:
  I just finally moved over to mod_jk from mod_jk2. 
Since this is a development environment on
Windows/2000 Professional, I didn't have the pressure
to move.

Anyway, here's my environment:

Windows/2000 Professional
Apache 2.054 (will upgrade one of these days)
Tomcat 5.5.17
JDK 1.5.0_06-b05

Since I don't like spaces in my file names, everything
is installed under C:\Apache\Apache2 and
C:\Apache\Tomcat.

My workers file looks like the following (I specify a
lot of the defaults).

# only one worker
# a better name is called for
worker.list=worker1

#
# worker1 specs
#
worker.worker1.typw=ajp13
worker.worker1.host=localhost
worker.worker1.port=8009
worker.worker1.socket_timeout=60

Loading mod_jk in my httpd.conf file:

#
# mod_jk
#
LoadModule jk_module modules/mod_jk.so
JkWorkersFile conf/workers.properties
JkLogFile logs/mod_jk.log

Now I create aliased for each of my web applications
and set up directory controls. I do that so I can
serve static files from Apache, and dynamic files from
Tomcat. I could also use JkAutoAlias.


Options Indexes MultiViews
AllowOverride None
Order deny,allow
Allow from 192.168.1
Allow from 127.0.0.1


This sets directory access, since the Tomcat webapps
directory is outside my document root.

An Alias and a JkMount finish up the configuration.

# all on one line
Alias /jsp-examples
"C:/Apache/Tomcat/webapps/jsp-examples"

# separate line
JkMount /jsp-examples/*.jsp worker1

Hope this helps.

/mde/
just my two cents . . . .


--- "M. Goodell" wrote:

> I am unable to get the tomcat connectors to work
> after spending hours 
> reading docs and scouring google in search of
> answers. 
> 
> I have seen the problem I am having posted all over
> the web but there 
> are no solutions to it that I have seen.
> 
> Here is the summary of the problem:
> 
> Component information:
> 
> - MS Windows XP
> - Tomcat-5.5.17
> - Apache 2.0.58
> - mod_jk-1.2.18
> 
> I define the workers.properties file as specified
> per the 
> documentation which resides in:
> "C:/Program Files/Apache
> Group/Apache2/conf/workers.properties"
> 
> worker.list = worker1
> worker.worker1.type = ajp13
> 
> (according to the docs "type" is the only mandatory
> element)
> 
> And the VirtualHost portion of httpd.conf looks like
> this:
> 
> 
> ServerAdmin [EMAIL PROTECTED]
> DocumentRoot /www/sandbox
> ServerName dummy-host.example.com
> ErrorLog logs/172.27.224.236.error.log
> CustomLog logs/172.27.224.236.access.log common
> LoadModule jk_module "C:/Program Files/Apache 
> Group/Apache2/modules/mod_jk.so"
> JkWorkersFile "C:/Program Files/Apache
> Group/Apache2/conf/workers.properties"
> JkLogFile "C:/Program Files/Apache 
> Group/apache-tomcat-5.5.17/logs/mod_jk.log"
> JkLogLevel debug
> JkMount /axis ajp13
> JkMount /axis/* ajp13
> JkMount /servlets-examples ajp13
> JkMount /servlets-examples/* ajp13
> JkMount /jsp-examples ajp13
> JkMount /jsp-examples/* ajp13
> JkMount /MGGWebApp worker1
> JkMount /MGGWebApp/* worker1
> 
> 
> When I attempt to access
> http://172.27.224.236/MGGWebApp/ I get an 
> "Internal Server Error" page and the error info is
> dumped to the log. The regular ajp13 references work
> perfect.
> 
> Alas, Here is the log entry:
> 
> [Tue Aug 08 12:47:16 2006] [1988:0324] [debug]
> jk_uri_worker_map.c 
> (508): Attempting to map URI '/MGGWebApp/index.jsp'
> from 8 maps
> [Tue Aug 08 12:47:16 2006] [1988:0324] [debug]
> jk_uri_worker_map.c 
> (520): Attempting to map context URI
> '/servlets-examples/*'
> [Tue Aug 08 12:47:16 2006] [1988:0324] [debug]
> jk_uri_worker_map.c 
> (520): Attempting to map context URI
> '/jsp-examples/*'
> [Tue Aug 08 12:47:16 2006] [1988:0324] [debug]
> jk_uri_worker_map.c 
> (520): Attempting to map context URI '/MGGWebApp/*'
> [Tue Aug 08 12:47:16 2006] [1988:0324] [debug]
> jk_uri_worker_map.c 
> (534): Found a wildchar match worker1 ->
> /MGGWebApp/*
> [Tue Aug 08 12:47:16 2006] [1988:0324] [debug]
> mod_jk.c (1832): Into 
> handler jakarta-servlet worker=worker1 r->proxyreq=0
> [Tue Aug 08 12:47:16 2006] [1988:0324] [debug]
> jk_worker.c (111): did 
> not find a worker worker1
> [Tue Aug 08 12:47:16 2006] [1988:0324] [info] 
> mod_jk.c (1986): Could 
> not find a worker for worker name=worker1
> 
> It seems to me, from the log file information, that
> it simply cannot 
> find the workers.properties file. Also, it looks as
> though the mod_jk 
> is loading due to Apaches lack of complaining.
> 
> Any help / direction or chastisment on this would
> be welcomed.
> 
> Many thanks! 
> 
> M Goodell


__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
To start a new topic, e-mai

Re: Connector Problems -

2006-08-08 Thread fredk2

could it be that the loading of the module and the related configuration
?must? be outside of the   section ?

LoadModule jk_module modules/mod_jk.so 
kWorkersFile conf/workers.properties 
JkLogFile logs/mod_jk.log 
JkLogLevel debug 

-- 
View this message in context: 
http://www.nabble.com/Connector-Problems---tf2074658.html#a5714885
Sent from the Tomcat - User forum at Nabble.com.


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Connector Problems -

2006-08-08 Thread Mark Eggers
I just finally moved over to mod_jk from mod_jk2. 
Since this is a development environment on
Windows/2000 Professional, I didn't have the pressure
to move.

Anyway, here's my environment:

Windows/2000 Professional
Apache 2.054 (will upgrade one of these days)
Tomcat 5.5.17
JDK 1.5.0_06-b05

Since I don't like spaces in my file names, everything
is installed under C:\Apache\Apache2 and
C:\Apache\Tomcat.

My workers file looks like the following (I specify a
lot of the defaults).

# only one worker
# a better name is called for
worker.list=worker1

#
# worker1 specs
#
worker.worker1.typw=ajp13
worker.worker1.host=localhost
worker.worker1.port=8009
worker.worker1.socket_timeout=60

Loading mod_jk in my httpd.conf file:

#
# mod_jk
#
LoadModule jk_module   modules/mod_jk.so
JkWorkersFile  conf/workers.properties
JkLogFile  logs/mod_jk.log

Now I create aliased for each of my web applications
and set up directory controls.  I do that so I can
serve static files from Apache, and dynamic files from
Tomcat.  I could also use JkAutoAlias.


   Options Indexes MultiViews
   AllowOverride None
   Order deny,allow
   Allow from 192.168.1
   Allow from 127.0.0.1


This sets directory access, since the Tomcat webapps
directory is outside my document root.

An Alias and a JkMount finish up the configuration.

# all on one line
Alias /jsp-examples
"C:/Apache/Tomcat/webapps/jsp-examples"

# separate line
JkMount /jsp-examples/*.jsp  worker1

Hope this helps.

/mde/
just my two cents . . . .


--- "M. Goodell" <[EMAIL PROTECTED]> wrote:

> I am unable to get the tomcat connectors to work
> after spending hours 
> reading docs and scouring google in search of
> answers. 
>
> I have seen the problem I am having posted all over
> the web but there 
> are no solutions to it that I have seen.
>
>   Here is the summary of the problem:
>
>   Component information:
>
>   - MS Windows XP
>   - Tomcat-5.5.17
>   - Apache 2.0.58
>   - mod_jk-1.2.18
>
> I define the workers.properties file as specified
> per the 
> documentation which resides in:
>   "C:/Program Files/Apache
> Group/Apache2/conf/workers.properties"
>
>   worker.list = worker1
> worker.worker1.type = ajp13
>   
> (according to the docs "type" is the only mandatory
> element)
>
> And the VirtualHost portion of httpd.conf looks like
> this:
>
> 
>   ServerAdmin [EMAIL PROTECTED]
> DocumentRoot /www/sandbox
> ServerName dummy-host.example.com
> ErrorLog logs/172.27.224.236.error.log
> CustomLog logs/172.27.224.236.access.log common
> LoadModule jk_module "C:/Program Files/Apache 
> Group/Apache2/modules/mod_jk.so"
> JkWorkersFile "C:/Program Files/Apache
> Group/Apache2/conf/workers.properties"
> JkLogFile "C:/Program Files/Apache 
> Group/apache-tomcat-5.5.17/logs/mod_jk.log"
>   JkLogLevel debug
>   JkMount /axis ajp13
> JkMount /axis/* ajp13
>   JkMount /servlets-examples ajp13
> JkMount /servlets-examples/* ajp13
>   JkMount /jsp-examples ajp13
> JkMount /jsp-examples/* ajp13
>   JkMount /MGGWebApp worker1
> JkMount /MGGWebApp/* worker1
>   
> 
>   When I attempt to access
> http://172.27.224.236/MGGWebApp/  I get an 
> "Internal Server Error" page and the error info is
> dumped to the log. The regular ajp13 references work
> perfect.
>
>   Alas, Here is the log entry:
>
>   [Tue Aug 08 12:47:16 2006] [1988:0324] [debug]
> jk_uri_worker_map.c 
> (508): Attempting to map URI '/MGGWebApp/index.jsp'
> from 8 maps
> [Tue Aug 08 12:47:16 2006] [1988:0324] [debug]
> jk_uri_worker_map.c 
> (520): Attempting to map context URI
> '/servlets-examples/*'
> [Tue Aug 08 12:47:16 2006] [1988:0324] [debug]
> jk_uri_worker_map.c 
> (520): Attempting to map context URI
> '/jsp-examples/*'
> [Tue Aug 08 12:47:16 2006] [1988:0324] [debug]
> jk_uri_worker_map.c 
> (520): Attempting to map context URI '/MGGWebApp/*'
> [Tue Aug 08 12:47:16 2006] [1988:0324] [debug]
> jk_uri_worker_map.c 
> (534): Found a wildchar match worker1 ->
> /MGGWebApp/*
> [Tue Aug 08 12:47:16 2006] [1988:0324] [debug]
> mod_jk.c (1832): Into 
> handler jakarta-servlet worker=worker1 r->proxyreq=0
> [Tue Aug 08 12:47:16 2006] [1988:0324] [debug]
> jk_worker.c (111): did 
> not find a worker worker1
> [Tue Aug 08 12:47:16 2006] [1988:0324] [info] 
> mod_jk.c (1986): Could 
> not find a worker for worker name=worker1
>
>  It seems to me, from the log file information, that
> it simply cannot 
> find the workers.properties file. Also, it looks as
> though the mod_jk 
> is loading due to Apaches lack of complaining.
>
>  Any help / direction or chastisment on this would
> be welcomed.
> 
>   Many thanks! 
>
>  M Goodell


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mai

Re: Connector Problems -

2006-08-08 Thread M. Goodell
The server still fails with, "Internal Server Error"
   
  (Note: I tested if Apache was even looking for the conf/workers.properties by 
changing its name. When the file did not exist(conf/workersA.properties), 
Apache would not start. When the file was there (conf/workers.properties) 
Apache started fine.)
   
  My httpd.conf now (with all absolute paths dropped) looks like:
   
  
   
   ServerAdmin [EMAIL PROTECTED]
 DocumentRoot /www/sandbox
 ServerName dummy-host.example.com
 ErrorLog logs/172.27.224.236.error.log
 CustomLog logs/172.27.224.236.access.log common
   LoadModule jk_module modules/mod_jk.so
   JkWorkersFile conf/workers.properties
 JkLogFile logs/mod_jk.log
 JkLogLevel debug
 
 JkMount /axis ajp13
 JkMount /axis/* ajp13
   
   JkMount /servlets-examples ajp13
 JkMount /servlets-examples/* ajp13
   
   JkMount /jsp-examples ajp13
 JkMount /jsp-examples/* ajp13
   
   JkMount /MGGWebApp worker1
 JkMount /MGGWebApp/* worker1
   
  

  The mod_jk.log file shows:
   
  [Tue Aug 08 14:45:55 2006] [1564:2044] [debug] jk_uri_worker_map.c (508): 
Attempting to map URI '/MGGWebApp/index.jsp' from 8 maps
[Tue Aug 08 14:45:55 2006] [1564:2044] [debug] jk_uri_worker_map.c (520): 
Attempting to map context URI '/servlets-examples/*'
[Tue Aug 08 14:45:55 2006] [1564:2044] [debug] jk_uri_worker_map.c (520): 
Attempting to map context URI '/jsp-examples/*'
[Tue Aug 08 14:45:55 2006] [1564:2044] [debug] jk_uri_worker_map.c (520): 
Attempting to map context URI '/MGGWebApp/*'
[Tue Aug 08 14:45:55 2006] [1564:2044] [debug] jk_uri_worker_map.c (534): Found 
a wildchar match worker1 -> /MGGWebApp/*
[Tue Aug 08 14:45:55 2006] [1564:2044] [debug] mod_jk.c (1832): Into handler 
jakarta-servlet worker=worker1 r->proxyreq=0
[Tue Aug 08 14:45:55 2006] [1564:2044] [debug] jk_worker.c (111): did not find 
a worker worker1
[Tue Aug 08 14:45:55 2006] [1564:2044] [info]  mod_jk.c (1986): Could not find 
a worker for worker name=worker1

  
David Smith <[EMAIL PROTECTED]> wrote:
  What happens when you drop the full paths in favor of relative paths to 
the Apache directory as in:

ServerAdmin [EMAIL PROTECTED]
DocumentRoot /www/sandbox
ServerName dummy-host.example.com
ErrorLog logs/172.27.224.236.error.log
CustomLog logs/172.27.224.236.access.log common
LoadModule jk_module modules/mod_jk.so
JkWorkersFile conf/workers.properties
JkLogFile "C:/Program Files/Apache
Group/apache-tomcat-5.5.17/logs/mod_jk.log"
JkLogLevel debug
JkMount /axis ajp13
JkMount /axis/* ajp13
JkMount /servlets-examples ajp13
JkMount /servlets-examples/* ajp13
JkMount /jsp-examples ajp13
JkMount /jsp-examples/* ajp13
JkMount /MGGWebApp worker1
JkMount /MGGWebApp/* worker1

--David

M. Goodell wrote:

>Yes, I am able to access all web apps that are using ajp13. 
> The only one that does not work is the "/MGGWebApp" which uses worker1
> The ajp13 is configured in the server.xml file. That is the only reference to 
> it.
> 
>David Smith wrote:
> I meant in this snippet of your Apache httpd.conf, you have:
>
>JkMount /axis ajp13
>JkMount /axis/* ajp13
>JkMount /servlets-examples ajp13
>JkMount /servlets-examples/* ajp13
>JkMount /jsp-examples ajp13
>JkMount /jsp-examples/* ajp13
>JkMount /MGGWebApp worker1
>JkMount /MGGWebApp/* worker1
>
>
>Where we see two workers here -- 'ajp13' and 'worker1'. Where is the 
>worker 'ajp13' configured? Are you able to successfully get to /axis or 
>/servlet-examples?
>
>--David
>
>
>M. Goodell wrote:
>
> 
>
>>Yes, the ajp13 connector is working great. It is configured in server.xml as:
>>
>> 
>>
>>>enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />
>>> 
>>>
>>Is this what your were looking for ? ? ?
>>
>>David Smith wrote:
>>Past thread have effectively said use the .so with Apache even though 
>>you might be on Windows. In reality I would think the error would be 
>>much different if Apache couldn't load mod_jk.so.
>>
>>Your Apache config mentions use of a worker named ajp13. Is that one 
>>working, and if so, where is it configured?
>>
>>--David
>>
>>M. Goodell wrote:
>>
>>
>>
>> 
>>
>>>I used the .so file from the following link:
>>>
>>>http://apache.seekmeup.com/tomcat/tomcat-connectors/jk/binaries/win32/jk-1.2.18/
>>>
>>>where there are no .DLL files only .so files. Also, there are several .so 
>>>files in my apache/modules directory.
>>>
>>>"Sharma, Siddharth" wrote:
>>>
>>>
>>> 
>>>
>>>>LoadModule jk_module "C:/Program Files/Apache 
>>>>
>>>>
>>

Re: Connector Problems -

2006-08-08 Thread David Smith
What happens when you drop the full paths in favor of relative paths to 
the Apache directory as in:


ServerAdmin [EMAIL PROTECTED]
DocumentRoot /www/sandbox
ServerName dummy-host.example.com
ErrorLog logs/172.27.224.236.error.log
CustomLog logs/172.27.224.236.access.log common
LoadModule jk_module modules/mod_jk.so
JkWorkersFile conf/workers.properties
JkLogFile "C:/Program Files/Apache
Group/apache-tomcat-5.5.17/logs/mod_jk.log"
JkLogLevel debug
JkMount /axis ajp13
JkMount /axis/* ajp13
JkMount /servlets-examples ajp13
JkMount /servlets-examples/* ajp13
JkMount /jsp-examples ajp13
JkMount /jsp-examples/* ajp13
JkMount /MGGWebApp worker1
JkMount /MGGWebApp/* worker1

--David

M. Goodell wrote:

Yes, I am able to access all web apps that are using ajp13. 
 The only one that does not work is the "/MGGWebApp" which uses worker1

 The ajp13 is configured in the server.xml file. That is the only reference to 
it.
 
David Smith <[EMAIL PROTECTED]> wrote:

 I meant in this snippet of your Apache httpd.conf, you have:

JkMount /axis ajp13
JkMount /axis/* ajp13
JkMount /servlets-examples ajp13
JkMount /servlets-examples/* ajp13
JkMount /jsp-examples ajp13
JkMount /jsp-examples/* ajp13
JkMount /MGGWebApp worker1
JkMount /MGGWebApp/* worker1


Where we see two workers here -- 'ajp13' and 'worker1'. Where is the 
worker 'ajp13' configured? Are you able to successfully get to /axis or 
/servlet-examples?


--David


M. Goodell wrote:

 


Yes, the ajp13 connector is working great. It is configured in server.xml as:

   


enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />
 


Is this what your were looking for ? ? ?

David Smith wrote:
Past thread have effectively said use the .so with Apache even though 
you might be on Windows. In reality I would think the error would be 
much different if Apache couldn't load mod_jk.so.


Your Apache config mentions use of a worker named ajp13. Is that one 
working, and if so, where is it configured?


--David

M. Goodell wrote:



   


I used the .so file from the following link:

http://apache.seekmeup.com/tomcat/tomcat-connectors/jk/binaries/win32/jk-1.2.18/

where there are no .DLL files only .so files. Also, there are several .so files 
in my apache/modules directory.

"Sharma, Siddharth" wrote:


 

LoadModule jk_module "C:/Program Files/Apache 



   

 


Group/Apache2/modules/mod_jk.so"




   


Since you have windows, shouldn't the mod_jk load library be a dll rather
than so?
I believe you have referenced the incorrect mod_jk.





-Original Message-
From: M. Goodell [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, August 08, 2006 3:15 PM

To: Tomcat Questions
Subject: Connector Problems - 

I am unable to get the tomcat connectors to work after spending hours 
reading docs and scouring google in search of answers. 

I have seen the problem I am having posted all over the web but there 
are no solutions to it that I have seen.


Here is the summary of the problem:

Component information:

- MS Windows XP
- Tomcat-5.5.17
- Apache 2.0.58
- mod_jk-1.2.18

I define the workers.properties file as specified per the 
documentation which resides in:

"C:/Program Files/Apache Group/Apache2/conf/workers.properties"

worker.list = worker1
worker.worker1.type = ajp13

(according to the docs "type" is the only mandatory element)

And the VirtualHost portion of httpd.conf looks like this:


ServerAdmin [EMAIL PROTECTED]
DocumentRoot /www/sandbox
ServerName dummy-host.example.com
ErrorLog logs/172.27.224.236.error.log
CustomLog logs/172.27.224.236.access.log common
LoadModule jk_module "C:/Program Files/Apache 
Group/Apache2/modules/mod_jk.so"

JkWorkersFile "C:/Program Files/Apache
Group/Apache2/conf/workers.properties"
JkLogFile "C:/Program Files/Apache 
Group/apache-tomcat-5.5.17/logs/mod_jk.log"

JkLogLevel debug
JkMount /axis ajp13
JkMount /axis/* ajp13
JkMount /servlets-examples ajp13
JkMount /servlets-examples/* ajp13
JkMount /jsp-examples ajp13
JkMount /jsp-examples/* ajp13
JkMount /MGGWebApp worker1
JkMount /MGGWebApp/* worker1


When I attempt to access http://172.27.224.236/MGGWebApp/ I get an 
"Internal Server Error" page and the error info is dumped to the log. The

regular ajp13 references work perfect.

Alas, Here is the log entry:

[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(508): Attempting to map URI '/MGGWebApp/index.jsp' from 8 maps
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(520): Attempting to map context URI '/servlets-examples/*'
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(520): Attempting to map context URI '/jsp-examples/*'
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(520): Attempting to map context URI '/MGGWeb

Re: Connector Problems -

2006-08-08 Thread M. Goodell
Yes, I am able to access all web apps that are using ajp13. 
  The only one that does not work is the "/MGGWebApp" which uses worker1
  The ajp13 is configured in the server.xml file. That is the only reference to 
it.
  
David Smith <[EMAIL PROTECTED]> wrote:
  I meant in this snippet of your Apache httpd.conf, you have:

JkMount /axis ajp13
JkMount /axis/* ajp13
JkMount /servlets-examples ajp13
JkMount /servlets-examples/* ajp13
JkMount /jsp-examples ajp13
JkMount /jsp-examples/* ajp13
JkMount /MGGWebApp worker1
JkMount /MGGWebApp/* worker1


Where we see two workers here -- 'ajp13' and 'worker1'. Where is the 
worker 'ajp13' configured? Are you able to successfully get to /axis or 
/servlet-examples?

--David


M. Goodell wrote:

>Yes, the ajp13 connector is working great. It is configured in server.xml as:
> 
> > enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />
>
>Is this what your were looking for ? ? ?
> 
>David Smith wrote:
> Past thread have effectively said use the .so with Apache even though 
>you might be on Windows. In reality I would think the error would be 
>much different if Apache couldn't load mod_jk.so.
>
>Your Apache config mentions use of a worker named ajp13. Is that one 
>working, and if so, where is it configured?
>
>--David
>
>M. Goodell wrote:
>
> 
>
>>I used the .so file from the following link:
>>
>>http://apache.seekmeup.com/tomcat/tomcat-connectors/jk/binaries/win32/jk-1.2.18/
>>
>>where there are no .DLL files only .so files. Also, there are several .so 
>>files in my apache/modules directory.
>>
>>"Sharma, Siddharth" wrote:
>> 
>>
>>>LoadModule jk_module "C:/Program Files/Apache 
>>> 
>>>
>> 
>>
>>>Group/Apache2/modules/mod_jk.so"
>>>
>>>
>>> 
>>>
>>Since you have windows, shouldn't the mod_jk load library be a dll rather
>>than so?
>>I believe you have referenced the incorrect mod_jk.
>>
>>
>>
>>
>>
>>-Original Message-
>>From: M. Goodell [mailto:[EMAIL PROTECTED] 
>>Sent: Tuesday, August 08, 2006 3:15 PM
>>To: Tomcat Questions
>>Subject: Connector Problems - 
>>
>>I am unable to get the tomcat connectors to work after spending hours 
>>reading docs and scouring google in search of answers. 
>>
>>I have seen the problem I am having posted all over the web but there 
>>are no solutions to it that I have seen.
>>
>>Here is the summary of the problem:
>>
>>Component information:
>>
>>- MS Windows XP
>>- Tomcat-5.5.17
>>- Apache 2.0.58
>>- mod_jk-1.2.18
>>
>>I define the workers.properties file as specified per the 
>>documentation which resides in:
>>"C:/Program Files/Apache Group/Apache2/conf/workers.properties"
>>
>>worker.list = worker1
>>worker.worker1.type = ajp13
>>
>>(according to the docs "type" is the only mandatory element)
>>
>>And the VirtualHost portion of httpd.conf looks like this:
>>
>>
>>ServerAdmin [EMAIL PROTECTED]
>>DocumentRoot /www/sandbox
>>ServerName dummy-host.example.com
>>ErrorLog logs/172.27.224.236.error.log
>>CustomLog logs/172.27.224.236.access.log common
>>LoadModule jk_module "C:/Program Files/Apache 
>>Group/Apache2/modules/mod_jk.so"
>>JkWorkersFile "C:/Program Files/Apache
>>Group/Apache2/conf/workers.properties"
>>JkLogFile "C:/Program Files/Apache 
>>Group/apache-tomcat-5.5.17/logs/mod_jk.log"
>>JkLogLevel debug
>>JkMount /axis ajp13
>>JkMount /axis/* ajp13
>>JkMount /servlets-examples ajp13
>>JkMount /servlets-examples/* ajp13
>>JkMount /jsp-examples ajp13
>>JkMount /jsp-examples/* ajp13
>>JkMount /MGGWebApp worker1
>>JkMount /MGGWebApp/* worker1
>>
>>
>>When I attempt to access http://172.27.224.236/MGGWebApp/ I get an 
>>"Internal Server Error" page and the error info is dumped to the log. The
>>regular ajp13 references work perfect.
>>
>>Alas, Here is the log entry:
>>
>>[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
>>(508): Attempting to map URI '/MGGWebApp/index.jsp' from 8 maps
>>[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
>>(520): Attempting to map context URI '/servlets-examples/*'
>>[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
>>(520): Attempting to map context URI '/jsp-examples/*'
>>[Tue

Re: Connector Problems -

2006-08-08 Thread David Smith
Not a big deal.  The tomcat 3.3 docs are very old and may not be 
maintained as they should.  The tomcat connectors documentation at 
http://tomcat.apache.org/connectors-doc/howto/apache.html show that 
mod_jk.so is the name for it on both linux/unix and Windows.


--David

Sharma, Siddharth wrote:


Hmm. Interesting. My bad. Maybe the web page is not updated.
I was only going by 
http://tomcat.apache.org/tomcat-3.3-doc/mod_jk-howto.html#s61 
which states:


linux/i386 Contains mod_jk.so for Apache 1.3 for the standard API as well as
EAPI and mod_jk.so for Apache 2.0 

netware/i386 Contains the mod_jk.nlm and nsapi.nlm 


win32/i386 Contains the mod_jk.dll for Windows as well as other useful
binaries.



-Original Message-
From: David Smith [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, August 08, 2006 3:39 PM

To: Tomcat Users List
Subject: Re: Connector Problems -

Past thread have effectively said use the .so with Apache even though 
you might be on Windows.  In reality I would think the error would be 
much different if Apache couldn't load mod_jk.so.


Your Apache config mentions use of a worker named ajp13.  Is that one 
working, and if so, where is it configured?


--David

M. Goodell wrote:

 


I used the .so file from the following link:
 

   


http://apache.seekmeup.com/tomcat/tomcat-connectors/jk/binaries/win32/jk-1.2
.18/
 

 
where there are no .DLL files only .so files. Also, there are several .so
   


files in my apache/modules directory.
 


"Sharma, Siddharth" <[EMAIL PROTECTED]> wrote:
> LoadModule jk_module "C:/Program Files/Apache 



   


Group/Apache2/modules/mod_jk.so"
  

 


Since you have windows, shouldn't the mod_jk load library be a dll rather
than so?
I believe you have referenced the incorrect mod_jk.





-Original Message-
From: M. Goodell [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, August 08, 2006 3:15 PM

To: Tomcat Questions
Subject: Connector Problems - 

I am unable to get the tomcat connectors to work after spending hours 
reading docs and scouring google in search of answers. 

I have seen the problem I am having posted all over the web but there 
are no solutions to it that I have seen.


Here is the summary of the problem:

Component information:

- MS Windows XP
- Tomcat-5.5.17
- Apache 2.0.58
- mod_jk-1.2.18

I define the workers.properties file as specified per the 
documentation which resides in:

"C:/Program Files/Apache Group/Apache2/conf/workers.properties"

worker.list = worker1
worker.worker1.type = ajp13

(according to the docs "type" is the only mandatory element)

And the VirtualHost portion of httpd.conf looks like this:


ServerAdmin [EMAIL PROTECTED]
DocumentRoot /www/sandbox
ServerName dummy-host.example.com
ErrorLog logs/172.27.224.236.error.log
CustomLog logs/172.27.224.236.access.log common
LoadModule jk_module "C:/Program Files/Apache 
Group/Apache2/modules/mod_jk.so"

JkWorkersFile "C:/Program Files/Apache
Group/Apache2/conf/workers.properties"
JkLogFile "C:/Program Files/Apache 
Group/apache-tomcat-5.5.17/logs/mod_jk.log"

JkLogLevel debug
JkMount /axis ajp13
JkMount /axis/* ajp13
JkMount /servlets-examples ajp13
JkMount /servlets-examples/* ajp13
JkMount /jsp-examples ajp13
JkMount /jsp-examples/* ajp13
JkMount /MGGWebApp worker1
JkMount /MGGWebApp/* worker1


When I attempt to access http://172.27.224.236/MGGWebApp/ I get an 
"Internal Server Error" page and the error info is dumped to the log. The

regular ajp13 references work perfect.

Alas, Here is the log entry:

[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(508): Attempting to map URI '/MGGWebApp/index.jsp' from 8 maps
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(520): Attempting to map context URI '/servlets-examples/*'
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(520): Attempting to map context URI '/jsp-examples/*'
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(520): Attempting to map context URI '/MGGWebApp/*'
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(534): Found a wildchar match worker1 -> /MGGWebApp/*
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] mod_jk.c (1832): Into 
handler jakarta-servlet worker=worker1 r->proxyreq=0
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_worker.c (111): did 
not find a worker worker1
[Tue Aug 08 12:47:16 2006] [1988:0324] [info] mod_jk.c (1986): Could 
not find a worker for worker name=worker1


It seems to me, from the log file information, that it simply cannot 
find the workers.properties file. Also, it looks as though the mod_jk 
is loading due to Apaches lack of complaining.


Any help / direction or chastisment on this would be welcomed.

Many thanks! 


M Goodell



-
Stay in the know. Pulse on the new Yahoo.com. Check 

Re: Connector Problems -

2006-08-08 Thread David Smith

I meant in this snippet of your Apache httpd.conf, you have:

JkMount /axis ajp13
JkMount /axis/* ajp13
JkMount /servlets-examples ajp13
JkMount /servlets-examples/* ajp13
JkMount /jsp-examples ajp13
JkMount /jsp-examples/* ajp13
JkMount /MGGWebApp worker1
JkMount /MGGWebApp/* worker1


Where we see two workers here -- 'ajp13' and 'worker1'. Where is the 
worker 'ajp13' configured? Are you able to successfully get to /axis or 
/servlet-examples?


--David


M. Goodell wrote:


Yes, the ajp13 connector is working great. It is configured in server.xml as:
  
   enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />


Is this what your were looking for ? ? ?
 
David Smith <[EMAIL PROTECTED]> wrote:
 Past thread have effectively said use the .so with Apache even though 
you might be on Windows. In reality I would think the error would be 
much different if Apache couldn't load mod_jk.so.


Your Apache config mentions use of a worker named ajp13. Is that one 
working, and if so, where is it configured?


--David

M. Goodell wrote:

 


I used the .so file from the following link:

http://apache.seekmeup.com/tomcat/tomcat-connectors/jk/binaries/win32/jk-1.2.18/

where there are no .DLL files only .so files. Also, there are several .so files 
in my apache/modules directory.

"Sharma, Siddharth" wrote:
   

LoadModule jk_module "C:/Program Files/Apache 
 

   


Group/Apache2/modules/mod_jk.so"


 


Since you have windows, shouldn't the mod_jk load library be a dll rather
than so?
I believe you have referenced the incorrect mod_jk.





-Original Message-
From: M. Goodell [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, August 08, 2006 3:15 PM

To: Tomcat Questions
Subject: Connector Problems - 

I am unable to get the tomcat connectors to work after spending hours 
reading docs and scouring google in search of answers. 

I have seen the problem I am having posted all over the web but there 
are no solutions to it that I have seen.


Here is the summary of the problem:

Component information:

- MS Windows XP
- Tomcat-5.5.17
- Apache 2.0.58
- mod_jk-1.2.18

I define the workers.properties file as specified per the 
documentation which resides in:

"C:/Program Files/Apache Group/Apache2/conf/workers.properties"

worker.list = worker1
worker.worker1.type = ajp13

(according to the docs "type" is the only mandatory element)

And the VirtualHost portion of httpd.conf looks like this:


ServerAdmin [EMAIL PROTECTED]
DocumentRoot /www/sandbox
ServerName dummy-host.example.com
ErrorLog logs/172.27.224.236.error.log
CustomLog logs/172.27.224.236.access.log common
LoadModule jk_module "C:/Program Files/Apache 
Group/Apache2/modules/mod_jk.so"

JkWorkersFile "C:/Program Files/Apache
Group/Apache2/conf/workers.properties"
JkLogFile "C:/Program Files/Apache 
Group/apache-tomcat-5.5.17/logs/mod_jk.log"

JkLogLevel debug
JkMount /axis ajp13
JkMount /axis/* ajp13
JkMount /servlets-examples ajp13
JkMount /servlets-examples/* ajp13
JkMount /jsp-examples ajp13
JkMount /jsp-examples/* ajp13
JkMount /MGGWebApp worker1
JkMount /MGGWebApp/* worker1


When I attempt to access http://172.27.224.236/MGGWebApp/ I get an 
"Internal Server Error" page and the error info is dumped to the log. The

regular ajp13 references work perfect.

Alas, Here is the log entry:

[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(508): Attempting to map URI '/MGGWebApp/index.jsp' from 8 maps
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(520): Attempting to map context URI '/servlets-examples/*'
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(520): Attempting to map context URI '/jsp-examples/*'
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(520): Attempting to map context URI '/MGGWebApp/*'
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(534): Found a wildchar match worker1 -> /MGGWebApp/*
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] mod_jk.c (1832): Into 
handler jakarta-servlet worker=worker1 r->proxyreq=0
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_worker.c (111): did 
not find a worker worker1
[Tue Aug 08 12:47:16 2006] [1988:0324] [info] mod_jk.c (1986): Could 
not find a worker for worker name=worker1


It seems to me, from the log file information, that it simply cannot 
find the workers.properties file. Also, it looks as though the mod_jk 
is loading due to Apaches lack of complaining.


Any help / direction or chastisment on this would be welcomed.

Many thanks! 


M Goodell



-
Stay in the know. Pulse on the new Yahoo.com. Check it out. 


-
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+
countries) for 2¢/m

Re: Connector Problems -

2006-08-08 Thread M. Goodell
Yes, the ajp13 connector is working great. It is configured in server.xml as:
   
  

Is this what your were looking for ? ? ?
  
David Smith <[EMAIL PROTECTED]> wrote:
  Past thread have effectively said use the .so with Apache even though 
you might be on Windows. In reality I would think the error would be 
much different if Apache couldn't load mod_jk.so.

Your Apache config mentions use of a worker named ajp13. Is that one 
working, and if so, where is it configured?

--David

M. Goodell wrote:

>I used the .so file from the following link:
> 
> http://apache.seekmeup.com/tomcat/tomcat-connectors/jk/binaries/win32/jk-1.2.18/
> 
> where there are no .DLL files only .so files. Also, there are several .so 
> files in my apache/modules directory.
>
>"Sharma, Siddharth" wrote:
> > LoadModule jk_module "C:/Program Files/Apache 
> 
>
>>Group/Apache2/modules/mod_jk.so"
>> 
>>
>
>Since you have windows, shouldn't the mod_jk load library be a dll rather
>than so?
>I believe you have referenced the incorrect mod_jk.
>
>
>
>
>
>-Original Message-----
>From: M. Goodell [mailto:[EMAIL PROTECTED] 
>Sent: Tuesday, August 08, 2006 3:15 PM
>To: Tomcat Questions
>Subject: Connector Problems - 
>
>I am unable to get the tomcat connectors to work after spending hours 
>reading docs and scouring google in search of answers. 
>
>I have seen the problem I am having posted all over the web but there 
>are no solutions to it that I have seen.
>
>Here is the summary of the problem:
>
>Component information:
>
>- MS Windows XP
>- Tomcat-5.5.17
>- Apache 2.0.58
>- mod_jk-1.2.18
>
>I define the workers.properties file as specified per the 
>documentation which resides in:
>"C:/Program Files/Apache Group/Apache2/conf/workers.properties"
>
>worker.list = worker1
>worker.worker1.type = ajp13
>
>(according to the docs "type" is the only mandatory element)
>
>And the VirtualHost portion of httpd.conf looks like this:
>
>
>ServerAdmin [EMAIL PROTECTED]
>DocumentRoot /www/sandbox
>ServerName dummy-host.example.com
>ErrorLog logs/172.27.224.236.error.log
>CustomLog logs/172.27.224.236.access.log common
>LoadModule jk_module "C:/Program Files/Apache 
>Group/Apache2/modules/mod_jk.so"
>JkWorkersFile "C:/Program Files/Apache
>Group/Apache2/conf/workers.properties"
>JkLogFile "C:/Program Files/Apache 
>Group/apache-tomcat-5.5.17/logs/mod_jk.log"
>JkLogLevel debug
>JkMount /axis ajp13
>JkMount /axis/* ajp13
>JkMount /servlets-examples ajp13
>JkMount /servlets-examples/* ajp13
>JkMount /jsp-examples ajp13
>JkMount /jsp-examples/* ajp13
>JkMount /MGGWebApp worker1
>JkMount /MGGWebApp/* worker1
>
>
>When I attempt to access http://172.27.224.236/MGGWebApp/ I get an 
>"Internal Server Error" page and the error info is dumped to the log. The
>regular ajp13 references work perfect.
>
>Alas, Here is the log entry:
>
>[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
>(508): Attempting to map URI '/MGGWebApp/index.jsp' from 8 maps
>[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
>(520): Attempting to map context URI '/servlets-examples/*'
>[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
>(520): Attempting to map context URI '/jsp-examples/*'
>[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
>(520): Attempting to map context URI '/MGGWebApp/*'
>[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
>(534): Found a wildchar match worker1 -> /MGGWebApp/*
>[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] mod_jk.c (1832): Into 
>handler jakarta-servlet worker=worker1 r->proxyreq=0
>[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_worker.c (111): did 
>not find a worker worker1
>[Tue Aug 08 12:47:16 2006] [1988:0324] [info] mod_jk.c (1986): Could 
>not find a worker for worker name=worker1
>
>It seems to me, from the log file information, that it simply cannot 
>find the workers.properties file. Also, it looks as though the mod_jk 
>is loading due to Apaches lack of complaining.
>
>Any help / direction or chastisment on this would be welcomed.
>
>Many thanks! 
>
>M Goodell
>
>
>
>-
>Stay in the know. Pulse on the new Yahoo.com. Check it out. 
>
>-
>Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+
>countries) for 2¢/min or less.
>
>-
>To start a new topic, e-mail: users@tomcat.apache.org
>To unsubs

RE: Connector Problems -

2006-08-08 Thread Sharma, Siddharth
Hmm. Interesting. My bad. Maybe the web page is not updated.
I was only going by 
http://tomcat.apache.org/tomcat-3.3-doc/mod_jk-howto.html#s61 
which states:

linux/i386 Contains mod_jk.so for Apache 1.3 for the standard API as well as
EAPI and mod_jk.so for Apache 2.0 

netware/i386 Contains the mod_jk.nlm and nsapi.nlm 

win32/i386 Contains the mod_jk.dll for Windows as well as other useful
binaries.



-Original Message-
From: David Smith [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, August 08, 2006 3:39 PM
To: Tomcat Users List
Subject: Re: Connector Problems -

Past thread have effectively said use the .so with Apache even though 
you might be on Windows.  In reality I would think the error would be 
much different if Apache couldn't load mod_jk.so.

Your Apache config mentions use of a worker named ajp13.  Is that one 
working, and if so, where is it configured?

--David

M. Goodell wrote:

>I used the .so file from the following link:
>   
>
http://apache.seekmeup.com/tomcat/tomcat-connectors/jk/binaries/win32/jk-1.2
.18/
>   
>  where there are no .DLL files only .so files. Also, there are several .so
files in my apache/modules directory.
>
>"Sharma, Siddharth" <[EMAIL PROTECTED]> wrote:
>  > LoadModule jk_module "C:/Program Files/Apache 
>  
>
>>Group/Apache2/modules/mod_jk.so"
>>
>>
>
>Since you have windows, shouldn't the mod_jk load library be a dll rather
>than so?
>I believe you have referenced the incorrect mod_jk.
>
>
>
>
>
>-Original Message-
>From: M. Goodell [mailto:[EMAIL PROTECTED] 
>Sent: Tuesday, August 08, 2006 3:15 PM
>To: Tomcat Questions
>Subject: Connector Problems - 
>
>I am unable to get the tomcat connectors to work after spending hours 
>reading docs and scouring google in search of answers. 
>
>I have seen the problem I am having posted all over the web but there 
>are no solutions to it that I have seen.
>
>Here is the summary of the problem:
>
>Component information:
>
>- MS Windows XP
>- Tomcat-5.5.17
>- Apache 2.0.58
>- mod_jk-1.2.18
>
>I define the workers.properties file as specified per the 
>documentation which resides in:
>"C:/Program Files/Apache Group/Apache2/conf/workers.properties"
>
>worker.list = worker1
>worker.worker1.type = ajp13
>
>(according to the docs "type" is the only mandatory element)
>
>And the VirtualHost portion of httpd.conf looks like this:
>
>
>ServerAdmin [EMAIL PROTECTED]
>DocumentRoot /www/sandbox
>ServerName dummy-host.example.com
>ErrorLog logs/172.27.224.236.error.log
>CustomLog logs/172.27.224.236.access.log common
>LoadModule jk_module "C:/Program Files/Apache 
>Group/Apache2/modules/mod_jk.so"
>JkWorkersFile "C:/Program Files/Apache
>Group/Apache2/conf/workers.properties"
>JkLogFile "C:/Program Files/Apache 
>Group/apache-tomcat-5.5.17/logs/mod_jk.log"
>JkLogLevel debug
>JkMount /axis ajp13
>JkMount /axis/* ajp13
>JkMount /servlets-examples ajp13
>JkMount /servlets-examples/* ajp13
>JkMount /jsp-examples ajp13
>JkMount /jsp-examples/* ajp13
>JkMount /MGGWebApp worker1
>JkMount /MGGWebApp/* worker1
>
>
>When I attempt to access http://172.27.224.236/MGGWebApp/ I get an 
>"Internal Server Error" page and the error info is dumped to the log. The
>regular ajp13 references work perfect.
>
>Alas, Here is the log entry:
>
>[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
>(508): Attempting to map URI '/MGGWebApp/index.jsp' from 8 maps
>[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
>(520): Attempting to map context URI '/servlets-examples/*'
>[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
>(520): Attempting to map context URI '/jsp-examples/*'
>[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
>(520): Attempting to map context URI '/MGGWebApp/*'
>[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
>(534): Found a wildchar match worker1 -> /MGGWebApp/*
>[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] mod_jk.c (1832): Into 
>handler jakarta-servlet worker=worker1 r->proxyreq=0
>[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_worker.c (111): did 
>not find a worker worker1
>[Tue Aug 08 12:47:16 2006] [1988:0324] [info] mod_jk.c (1986): Could 
>not find a worker for worker name=worker1
>
>It seems to me, from the log file information, that it simply cannot 
>find the workers.properties file. Also, it looks as though the mod_jk 
>is loading due to Apaches lack of complaining.
>
>Any help / direction or chastisment on this would be welcomed.
>
>Many thanks! 
>

Re: Connector Problems -

2006-08-08 Thread David Smith
Past thread have effectively said use the .so with Apache even though 
you might be on Windows.  In reality I would think the error would be 
much different if Apache couldn't load mod_jk.so.


Your Apache config mentions use of a worker named ajp13.  Is that one 
working, and if so, where is it configured?


--David

M. Goodell wrote:


I used the .so file from the following link:
  
 http://apache.seekmeup.com/tomcat/tomcat-connectors/jk/binaries/win32/jk-1.2.18/
  
 where there are no .DLL files only .so files. Also, there are several .so files in my apache/modules directory.


"Sharma, Siddharth" <[EMAIL PROTECTED]> wrote:
 > LoadModule jk_module "C:/Program Files/Apache 
 


Group/Apache2/modules/mod_jk.so"
   



Since you have windows, shouldn't the mod_jk load library be a dll rather
than so?
I believe you have referenced the incorrect mod_jk.





-Original Message-
From: M. Goodell [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, August 08, 2006 3:15 PM

To: Tomcat Questions
Subject: Connector Problems - 

I am unable to get the tomcat connectors to work after spending hours 
reading docs and scouring google in search of answers. 

I have seen the problem I am having posted all over the web but there 
are no solutions to it that I have seen.


Here is the summary of the problem:

Component information:

- MS Windows XP
- Tomcat-5.5.17
- Apache 2.0.58
- mod_jk-1.2.18

I define the workers.properties file as specified per the 
documentation which resides in:

"C:/Program Files/Apache Group/Apache2/conf/workers.properties"

worker.list = worker1
worker.worker1.type = ajp13

(according to the docs "type" is the only mandatory element)

And the VirtualHost portion of httpd.conf looks like this:


ServerAdmin [EMAIL PROTECTED]
DocumentRoot /www/sandbox
ServerName dummy-host.example.com
ErrorLog logs/172.27.224.236.error.log
CustomLog logs/172.27.224.236.access.log common
LoadModule jk_module "C:/Program Files/Apache 
Group/Apache2/modules/mod_jk.so"

JkWorkersFile "C:/Program Files/Apache
Group/Apache2/conf/workers.properties"
JkLogFile "C:/Program Files/Apache 
Group/apache-tomcat-5.5.17/logs/mod_jk.log"

JkLogLevel debug
JkMount /axis ajp13
JkMount /axis/* ajp13
JkMount /servlets-examples ajp13
JkMount /servlets-examples/* ajp13
JkMount /jsp-examples ajp13
JkMount /jsp-examples/* ajp13
JkMount /MGGWebApp worker1
JkMount /MGGWebApp/* worker1


When I attempt to access http://172.27.224.236/MGGWebApp/ I get an 
"Internal Server Error" page and the error info is dumped to the log. The

regular ajp13 references work perfect.

Alas, Here is the log entry:

[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(508): Attempting to map URI '/MGGWebApp/index.jsp' from 8 maps
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(520): Attempting to map context URI '/servlets-examples/*'
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(520): Attempting to map context URI '/jsp-examples/*'
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(520): Attempting to map context URI '/MGGWebApp/*'
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(534): Found a wildchar match worker1 -> /MGGWebApp/*
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] mod_jk.c (1832): Into 
handler jakarta-servlet worker=worker1 r->proxyreq=0
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_worker.c (111): did 
not find a worker worker1
[Tue Aug 08 12:47:16 2006] [1988:0324] [info] mod_jk.c (1986): Could 
not find a worker for worker name=worker1


It seems to me, from the log file information, that it simply cannot 
find the workers.properties file. Also, it looks as though the mod_jk 
is loading due to Apaches lack of complaining.


Any help / direction or chastisment on this would be welcomed.

Many thanks! 


M Goodell



-
Stay in the know. Pulse on the new Yahoo.com. Check it out. 


-
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+
countries) for 2¢/min or less.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls.  Great rates 
starting at 1¢/min.

-
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ 
countries) for 2¢/min or less.
 




-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Connector Problems -

2006-08-08 Thread M. Goodell
I used the .so file from the following link:
   
  
http://apache.seekmeup.com/tomcat/tomcat-connectors/jk/binaries/win32/jk-1.2.18/
   
  where there are no .DLL files only .so files. Also, there are several .so 
files in my apache/modules directory.

"Sharma, Siddharth" <[EMAIL PROTECTED]> wrote:
  > LoadModule jk_module "C:/Program Files/Apache 
> Group/Apache2/modules/mod_jk.so"

Since you have windows, shouldn't the mod_jk load library be a dll rather
than so?
I believe you have referenced the incorrect mod_jk.





-Original Message-
From: M. Goodell [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, August 08, 2006 3:15 PM
To: Tomcat Questions
Subject: Connector Problems - 

I am unable to get the tomcat connectors to work after spending hours 
reading docs and scouring google in search of answers. 

I have seen the problem I am having posted all over the web but there 
are no solutions to it that I have seen.

Here is the summary of the problem:

Component information:

- MS Windows XP
- Tomcat-5.5.17
- Apache 2.0.58
- mod_jk-1.2.18

I define the workers.properties file as specified per the 
documentation which resides in:
"C:/Program Files/Apache Group/Apache2/conf/workers.properties"

worker.list = worker1
worker.worker1.type = ajp13

(according to the docs "type" is the only mandatory element)

And the VirtualHost portion of httpd.conf looks like this:


ServerAdmin [EMAIL PROTECTED]
DocumentRoot /www/sandbox
ServerName dummy-host.example.com
ErrorLog logs/172.27.224.236.error.log
CustomLog logs/172.27.224.236.access.log common
LoadModule jk_module "C:/Program Files/Apache 
Group/Apache2/modules/mod_jk.so"
JkWorkersFile "C:/Program Files/Apache
Group/Apache2/conf/workers.properties"
JkLogFile "C:/Program Files/Apache 
Group/apache-tomcat-5.5.17/logs/mod_jk.log"
JkLogLevel debug
JkMount /axis ajp13
JkMount /axis/* ajp13
JkMount /servlets-examples ajp13
JkMount /servlets-examples/* ajp13
JkMount /jsp-examples ajp13
JkMount /jsp-examples/* ajp13
JkMount /MGGWebApp worker1
JkMount /MGGWebApp/* worker1


When I attempt to access http://172.27.224.236/MGGWebApp/ I get an 
"Internal Server Error" page and the error info is dumped to the log. The
regular ajp13 references work perfect.

Alas, Here is the log entry:

[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(508): Attempting to map URI '/MGGWebApp/index.jsp' from 8 maps
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(520): Attempting to map context URI '/servlets-examples/*'
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(520): Attempting to map context URI '/jsp-examples/*'
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(520): Attempting to map context URI '/MGGWebApp/*'
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(534): Found a wildchar match worker1 -> /MGGWebApp/*
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] mod_jk.c (1832): Into 
handler jakarta-servlet worker=worker1 r->proxyreq=0
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_worker.c (111): did 
not find a worker worker1
[Tue Aug 08 12:47:16 2006] [1988:0324] [info] mod_jk.c (1986): Could 
not find a worker for worker name=worker1

It seems to me, from the log file information, that it simply cannot 
find the workers.properties file. Also, it looks as though the mod_jk 
is loading due to Apaches lack of complaining.

Any help / direction or chastisment on this would be welcomed.

Many thanks! 

M Goodell



-
Stay in the know. Pulse on the new Yahoo.com. Check it out. 

-
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+
countries) for 2¢/min or less.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls.  Great rates 
starting at 1¢/min.

-
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ 
countries) for 2¢/min or less.

RE: Connector Problems -

2006-08-08 Thread Sharma, Siddharth
> LoadModule jk_module "C:/Program Files/Apache 
> Group/Apache2/modules/mod_jk.so"

Since you have windows, shouldn't the mod_jk load library be a dll rather
than so?
I believe you have referenced the incorrect mod_jk.





-Original Message-
From: M. Goodell [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, August 08, 2006 3:15 PM
To: Tomcat Questions
Subject: Connector Problems - 

I am unable to get the tomcat connectors to work after spending hours 
reading docs and scouring google in search of answers. 
   
I have seen the problem I am having posted all over the web but there 
are no solutions to it that I have seen.
   
  Here is the summary of the problem:
   
  Component information:
   
  - MS Windows XP
  - Tomcat-5.5.17
  - Apache 2.0.58
  - mod_jk-1.2.18
   
I define the workers.properties file as specified per the 
documentation which resides in:
  "C:/Program Files/Apache Group/Apache2/conf/workers.properties"
   
  worker.list = worker1
worker.worker1.type = ajp13
  
(according to the docs "type" is the only mandatory element)
   
And the VirtualHost portion of httpd.conf looks like this:
   

  ServerAdmin [EMAIL PROTECTED]
DocumentRoot /www/sandbox
ServerName dummy-host.example.com
ErrorLog logs/172.27.224.236.error.log
CustomLog logs/172.27.224.236.access.log common
LoadModule jk_module "C:/Program Files/Apache 
Group/Apache2/modules/mod_jk.so"
JkWorkersFile "C:/Program Files/Apache
Group/Apache2/conf/workers.properties"
JkLogFile "C:/Program Files/Apache 
Group/apache-tomcat-5.5.17/logs/mod_jk.log"
  JkLogLevel debug
  JkMount /axis ajp13
JkMount /axis/* ajp13
  JkMount /servlets-examples ajp13
JkMount /servlets-examples/* ajp13
  JkMount /jsp-examples ajp13
JkMount /jsp-examples/* ajp13
  JkMount /MGGWebApp worker1
JkMount /MGGWebApp/* worker1
  

  When I attempt to access http://172.27.224.236/MGGWebApp/  I get an 
"Internal Server Error" page and the error info is dumped to the log. The
regular ajp13 references work perfect.
   
  Alas, Here is the log entry:
   
  [Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(508): Attempting to map URI '/MGGWebApp/index.jsp' from 8 maps
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(520): Attempting to map context URI '/servlets-examples/*'
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(520): Attempting to map context URI '/jsp-examples/*'
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(520): Attempting to map context URI '/MGGWebApp/*'
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(534): Found a wildchar match worker1 -> /MGGWebApp/*
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] mod_jk.c (1832): Into 
handler jakarta-servlet worker=worker1 r->proxyreq=0
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_worker.c (111): did 
not find a worker worker1
[Tue Aug 08 12:47:16 2006] [1988:0324] [info]  mod_jk.c (1986): Could 
not find a worker for worker name=worker1
   
 It seems to me, from the log file information, that it simply cannot 
find the workers.properties file. Also, it looks as though the mod_jk 
is loading due to Apaches lack of complaining.
   
 Any help / direction or chastisment on this would be welcomed.

  Many thanks! 
   
 M Goodell



-
Stay in the know. Pulse on the new Yahoo.com.  Check it out. 

-
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+
countries) for 2¢/min or less.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Connector Problems -

2006-08-08 Thread M. Goodell
I am unable to get the tomcat connectors to work after spending hours 
reading docs and scouring google in search of answers. 
   
I have seen the problem I am having posted all over the web but there 
are no solutions to it that I have seen.
   
  Here is the summary of the problem:
   
  Component information:
   
  - MS Windows XP
  - Tomcat-5.5.17
  - Apache 2.0.58
  - mod_jk-1.2.18
   
I define the workers.properties file as specified per the 
documentation which resides in:
  "C:/Program Files/Apache Group/Apache2/conf/workers.properties"
   
  worker.list = worker1
worker.worker1.type = ajp13
  
(according to the docs "type" is the only mandatory element)
   
And the VirtualHost portion of httpd.conf looks like this:
   

  ServerAdmin [EMAIL PROTECTED]
DocumentRoot /www/sandbox
ServerName dummy-host.example.com
ErrorLog logs/172.27.224.236.error.log
CustomLog logs/172.27.224.236.access.log common
LoadModule jk_module "C:/Program Files/Apache 
Group/Apache2/modules/mod_jk.so"
JkWorkersFile "C:/Program Files/Apache Group/Apache2/conf/workers.properties"
JkLogFile "C:/Program Files/Apache 
Group/apache-tomcat-5.5.17/logs/mod_jk.log"
  JkLogLevel debug
  JkMount /axis ajp13
JkMount /axis/* ajp13
  JkMount /servlets-examples ajp13
JkMount /servlets-examples/* ajp13
  JkMount /jsp-examples ajp13
JkMount /jsp-examples/* ajp13
  JkMount /MGGWebApp worker1
JkMount /MGGWebApp/* worker1
  

  When I attempt to access http://172.27.224.236/MGGWebApp/  I get an 
"Internal Server Error" page and the error info is dumped to the log. The 
regular ajp13 references work perfect.
   
  Alas, Here is the log entry:
   
  [Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(508): Attempting to map URI '/MGGWebApp/index.jsp' from 8 maps
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(520): Attempting to map context URI '/servlets-examples/*'
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(520): Attempting to map context URI '/jsp-examples/*'
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(520): Attempting to map context URI '/MGGWebApp/*'
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_uri_worker_map.c 
(534): Found a wildchar match worker1 -> /MGGWebApp/*
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] mod_jk.c (1832): Into 
handler jakarta-servlet worker=worker1 r->proxyreq=0
[Tue Aug 08 12:47:16 2006] [1988:0324] [debug] jk_worker.c (111): did 
not find a worker worker1
[Tue Aug 08 12:47:16 2006] [1988:0324] [info]  mod_jk.c (1986): Could 
not find a worker for worker name=worker1
   
 It seems to me, from the log file information, that it simply cannot 
find the workers.properties file. Also, it looks as though the mod_jk 
is loading due to Apaches lack of complaining.
   
 Any help / direction or chastisment on this would be welcomed.

  Many thanks! 
   
 M Goodell



-
Stay in the know. Pulse on the new Yahoo.com.  Check it out. 

-
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ 
countries) for 2¢/min or less.