RE: Problem with OpenSSL cipher suites -what's wrong with this configuration?

2019-08-08 Thread Alten, Jessica-Aileen 
> > I have a problem with the Tomcat 9.0.22 configuration for TLSv1.3  using
> > jdk8u222-b10_openj9-0.15.1 on Windows Server 2016. In principle
> > TLSv1.3 works, but I want to specify the allowed cipher suites as well.
> >
> > The relevant parts of server.xml are:
> >  > SSLEngine="on" />
> > ...
> >  >   maxThreads="150" SSLEnabled="true"
> > sslImplementationName="org.apache.tomcat.util.net.openssl.OpenSSLImplementation">
> >
> >
> >  > certificateKeystoreFile="D:/ProgramFiles/ApacheSoftwareFoundation/tomcat-base-8080/conf/keystore-pkcs12.jks"
> >   certificateKeystorePassword="mypassword" 
> > certificateKeystoreAlias="myalias" />
> >
> > 
> >
> > This configuration works!  When I connect to the server, Firefox says
> > under technical details: Connection encrypted (TLS_AES_128_GCM_SHA256,
> > 128bit key, TLS 1.3).
> >
> > But when I try to specify the cipher suites like:  > protocols="TLSv1.3" ciphers="TLS_AES_128_GCM_SHA256">
> 
> You have to use OpenSSL cipher names in this case. Like this...
> 
> ciphers="HIGH:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-
> RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-
> SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-
> SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-
> AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:AES128-GCM-
> SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:!DSS">

This cipher suite works fine for TLSv1.2. However, I only want to use TLSv1.3 
with its cipher suites. 
I installed openssl 1.1.1c and if I type "openssl ciphers -s -tls1_3" openSSL 
will return
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
in exactly this spelling, with underscores, not with hyphens as in the other 
cipher suites. I tried it with hyphens in Tomcat - but
it does not work either.

Therefore, I guess Tomcat cannot interpret these cipher suites for TLS 1.3. So 
is this possibly a bug in Tomcat with openSSL 1.1.1c
and JDK 8 (again: I am not talking about JSSE here, it can only do TLS 1.2)?

Kind regards,
Jessica


smime.p7s
Description: S/MIME cryptographic signature

Problem with OpenSSL cipher suites -what's wrong with this configuration?

2019-08-07 Thread Alten, Jessica-Aileen 
Dear all,

I have a problem with the Tomcat 9.0.22 configuration for TLSv1.3 using
jdk8u222-b10_openj9-0.15.1 on Windows Server 2016. In principle TLSv1.3
works, but I want to specify the allowed cipher suites as well.

The relevant parts of server.xml are:
  
...



 



This configuration works!  When I connect to the server, Firefox says under
technical details: Connection encrypted (TLS_AES_128_GCM_SHA256, 128bit key,
TLS 1.3).

But when I try to specify the cipher suites like: 
Tomcat throws an exception and TLS does not work! Errror code in the browser
is: SSL_ERROR_RX_RECORD_TOO_LONG

That is the most simplified version, first I tried these three:
ciphers=""TLS_AES_128_GCM_SHA256,
TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256". Same result.

I know, Java JSSE 1.8 does not support TLSv1.3, but openSSL does and Tomcat
works with openSSL and TLSv1.3 as shown above.

The relevant part of the catalina log is:

07-Aug-2019 13:41:38.183 INFORMATION [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded APR
based Apache Tomcat Native library [1.2.23] using APR version [1.7.0].
07-Aug-2019 13:41:38.183 INFORMATION [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR
capabilities: IPv6 [true], sendfile [true], accept filters [false], random
[true].
07-Aug-2019 13:41:38.183 INFORMATION [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR/OpenSSL
configuration: useAprConnector [false], useOpenSSL [true]
07-Aug-2019 13:41:38.198 INFORMATION [main]
org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL
successfully initialized [OpenSSL 1.1.1c  28 May 2019]
07-Aug-2019 13:41:38.370 INFORMATION [main]
org.apache.coyote.AbstractProtocol.init Initialisiere
ProtocolHandler["http-nio-8080"]
07-Aug-2019 13:41:38.417 INFORMATION [main]
org.apache.coyote.http11.AbstractHttp11Protocol.configureUpgradeProtocol The
["https-openssl-apr-8181"] connector has been configured to support
negotiation to h2] via ALPN
07-Aug-2019 13:41:38.417 INFORMATION [main]
org.apache.coyote.AbstractProtocol.init Initialisiere
ProtocolHandler["https-openssl-apr-8181"] 07-Aug-2019 13:41:38.823 WARNUNG
[main] org.apache.tomcat.util.net.openssl.OpenSSLContext.init Fehler beim
initialisieren des SSL Contexts java.lang.Exception: Unable to configure
permitted SSL ciphers (error:1410D0B9:SSL
routines:SSL_CTX_set_cipher_list:no cipher match)
at org.apache.tomcat.jni.SSLContext.setCipherSuite(Native Method)
at
org.apache.tomcat.util.net.openssl.OpenSSLContext.init(OpenSSLContext.java:2
43)
at
org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:247
)
at
org.apache.tomcat.util.net.AprEndpoint.createSSLContext(AprEndpoint.java:403
)
at org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:369) 
at
org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint
.java:1124)
at
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1137)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:574)
at
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.
java:74)
at org.apache.catalina.connector.Connector.initInternal(Connector.java:980)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
at
org.apache.catalina.core.StandardService.initInternal(StandardService.java:5
33)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
at
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:105
9)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
at org.apache.catalina.startup.Catalina.load(Catalina.java:584)
at org.apache.catalina.startup.Catalina.load(Catalina.java:607)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:304)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474)


Can anybody help?

Kind regards,
Jessica



smime.p7s
Description: S/MIME cryptographic signature

RE: Context Dependency Injection with Tomcat 7.0 x / 8.0 x

2016-10-12 Thread Alten, Jessica-Aileen 
Like Andreas I would vote for Weld (http://weld.cdi-spec.org/) - it is the 
Reference Implementation of CDI for the Java EE platform. It is easy to 
install (read 
http://balusc.omnifaces.org/2013/10/how-to-install-cdi-in-tomcat.html) and has 
an outstanding documentation 
(http://docs.jboss.org/weld/reference/latest/en-US/html/).

Jessica

> -Original Message-
> From: Kiran Badi [mailto:ki...@poonam.org]
> Sent: Tuesday, October 11, 2016 5:31 AM
> To: Tomcat Users List 
> Subject: Re: Context Dependency Injection with Tomcat 7.0 x / 8.0 x
>
> Thanks Mark,Christoper, Andreas and Chris for reply. Please accept
> apologies for delayed response.
>
> Tomee is an option but I need to see if client is ok with it. They are very
> much in Tomcat and has most application deployed with Tomcat.
>
> Chris,I would be happy to go with Spring, however the client I have has few
> legacy projects and I need  to see if I can suggest them spring.
>
> Weld and openbeans seems to be good option I can explore.Thanks
>
>
>
> On Thu, Oct 6, 2016 at 6:02 AM, Mark Eggers
> 
> wrote:
>
> > Kiran,
> >
> > On 10/5/2016 5:15 PM, Kiran Badi wrote:
> > > Hi All,
> > >
> > > I wanted to check if their is a way to do CDI with Tomcat for 7x and 8x
> > > version as per JEE spec ?
> > >
> > > I have a project for which I wanted to use CDI the way spring does it.
> > >
> > > Appreciate if someone can suggest something.
> > >
> > >
> > > - Kiran
> > >
> >
> > Probably the easiest way to do this is to use TomEE:
> >
> > http://tomee.apache.org/
> >
> > . . . just my two cents
> > /mde/
> >
> >


smime.p7s
Description: S/MIME cryptographic signature

RE: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

2016-01-19 Thread Alten, Jessica-Aileen 
> We have used HTTP Analayzer for file upload via Internet Explorer-8.
> Following are the scenario observed. [...]

I've just came back from vacation and didn't followed the whole thread - but I 
think it is simply an IE 8 problem, see 
http://blogs.msdn.com/b/ieinternals/archive/2011/03/10/wininet-internet-explorer-file-download-and-upload-maximum-size-limits.aspx

IE 8 can't upload more than 2 GB.

Greetings
Jessica


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

RE: [ANN] Apache Tomcat Connectors 1.2.41 released

2015-08-26 Thread Alten, Jessica-Aileen 
 @Jessica: which CPU architecture are you using: x86 (32 Bit), x64 (64
 Bits) or even Itanium 64? Which OS version do you have? If you are
 willing to test, I can provide an example binary from which we might
 learn, how well it works and whether that type of build is suitable for
 others as well.

Windows Server 2008R2 (productive/staging), x64 architecture.

Installing different redistributables (vcredist.exe) is in fact really common 
under Windows. Some installations require lots of redistributables (x86 and/or 
x64) on the same server.

Your link is for the x86 version, the x64 architecture redistributable is
http://www.microsoft.com/en-us/download/details.aspx?id=14632.

Greetings,
Jessica

RE: Tomcat 8.0.23, Apache Commons 2.2: Object pool shared across Tomcat servers/clusters?

2015-08-26 Thread Alten, Jessica-Aileen 
 Currently, we have multiple Tomcat nodes running on a single or on
 different physical machines with each having its own object pool
 (consider we have a pool of java String object but not connection
 pool) i.e., an object pool per node. The requirement is to share this
 pool of objects across Tomcat nodes.

 Is there any such implementation that we can readily use to achieve
 this?

Another solution is the Infinispan data grid http://infinispan.org . It is 
released under the Apache 2.0 open source license. I'm integrating it into my 
application at the moment. I have the same requirements that you have. The 
documentation and the examples are extraordinary good, perhaps a little bit 
overwhelming.

Greetings,
Jessica

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

RE: [ANN] Apache Tomcat Connectors 1.2.41 released

2015-08-24 Thread Alten, Jessica-Aileen 
 The official position of the ASF is that we provide code, not
 binaries.

Sorry, I can't follow this argument - there are lots of binaries in the 
download area, even for Tomcat and the Httpd flagship.

 We'd love to provide Windows binaries for mod_jk, but they are a real
 pain in the neck to actually build: they require very specific build
 environment, and the library must be built in such a way that it's
 compatible with the web server in which it's running (e.g. httpd
 1.3/2.2/2.4 or IIS 5/6/7/8/9, proper architecture (32/63) and chipset
 (x86/x86-64/itanium/alpha). It's gotten to the point where it's tough
 to provide all of those combinations with any regularity.

I understand that it is difficult - perhaps too difficult for the developers of 
this module, but the average Windows admin or Java programmer should do this? ;)
There were binaries of this module at least for the last 10 years!
I'm very disappointed on this attitude. You are closing out the whole 
Windows/IIS world.

 Unfortunately, I don't believe they provide builds for the ISAPI
 redirector for IIS. If that's what you need... umm...

Umm - yes - this is what I need.

Greetings,
Jessica

RE: [ANN] Apache Tomcat Connectors 1.2.41 released

2015-08-24 Thread Alten, Jessica-Aileen 
 The Apache Tomcat Project is proud to announce the release of version
 1.2.41 of the Apache Tomcat Connectors.
 This version fixes one security issue (CVE-2014-8111) and a number of
 bugs found in previous releases.

 [...]

 Downloads:
 http://tomcat.apache.org/download-connectors.cgi

Is there a binary release for Windows scheduled?

Greetings,
Jessica

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

RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work

2014-04-15 Thread Alten, Jessica-Aileen 
Hi all,

the new tomcat-connectors-1.2.40-windows-x86_64-iis works with the localhost 
setting in workers.properties! Great! Many thanks to the developers! :-)

Regards,
Jessica


smime.p7s
Description: S/MIME cryptographic signature

RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work

2014-04-08 Thread Alten, Jessica-Aileen 
 Sorry, I don't know how Windows internally resolves localhost. What I
 wanted to say is, that the hosts file has not been modified on that
 system - by default it does not contain any entries. This seems to have
 changed since some Windows versions, as e.g. Windows Vista contains
 127.0.0.1   localhost and  ::1 localhost by default
 in its hosts file, but starting with Windows 7, the hosts file only
 contains comments by default, with the hint localhost name resolution
 is handled within DNS itself.

 I just wrote a small C# program to see how .Net resolves localhost:

 private static void Main(string[] args) {
 IPAddress[] addresses = Dns.GetHostAddresses(localhost);
 foreach (IPAddress a in addresses) {
 Console.WriteLine(a.ToString());
 }

 Console.ReadKey();
 }


 When I run it on the server machine, it prints the normal IPv4 and IPv6
 loopback addresses:
 ::1
 127.0.0.1


Perhaps this might be the reason why it doesn't work in my case - on our 
servers and workstations ipv6 is disabled, the registry setting is
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\TCPIP6\Parameters]
DisabledComponents=dword:00ff

See the discussion on 
http://social.technet.microsoft.com/Forums/en-US/d7bfc3f0-1ea7-43e9-aaae-7b1d5c0b5c51/how-to-disable-ipv6-in-registry?forum=windowsserver2008r2networking
 
about ff and 

I'll try to check my settings with the C# program.

Regards,
Jessica




smime.p7s
Description: S/MIME cryptographic signature

RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work

2014-04-08 Thread Alten, Jessica-Aileen 
 I'll try to check my settings with the C# program.

Ipv6 loopback is available:

127.0.0.1
::1

See http://support.microsoft.com/kb/929852

However, I believe the disabled ipv6 might put us on the right track.

Regards,
Jessica
 



smime.p7s
Description: S/MIME cryptographic signature

RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work

2014-04-08 Thread Alten, Jessica-Aileen 
 It may be interesting to see what happens if you add a line like this
 in the server's
 hosts file :
 
 127.0.0.1 localhost localtomcat
 
 and then try to use each of these names in your isapi configuration for
 the worker.host.

I tried the formerly commented out lines in the hosts file after a reboot:
127.0.0.1   localhost
::1 localhost

Unfortunately this doesn't work either: localhost doesn't work in the
workers.properties file. The error log is the same as the previous one.

Regards,
Jessica



smime.p7s
Description: S/MIME cryptographic signature

RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work

2014-04-07 Thread Alten, Jessica-Aileen 
Hi all,
I'm  stunned about the enormous response to my question and I'm so sorry about 
the long delay of my answer now - but there is a world outside with  household 
chores at the weekend. I'll try to answer the questions from the oldest to the 
youngest:

 Ok, another check in a command window (and I assume that you open this 
 command
 window *on the server itself* where mod_jk and Tomcat are running, right ?)

Definitively ;-) I stumbled on this problem on a server (Windows Server 2008 
R2), then tried it on my workstation (Windows 7) which has the same 
configuration for Tomcat and IIS (and and where it doesn't work either). On 
the server I had no logfile.

 test :
 1) telnet localhost 8009
 2) telnet 127.0.0.1 8009

With worker.ajp13w.host=localhost

1) No answer (windows telnet: black console; cygwin telnet: no action, new 
prompt)
2) No answer (windows telnet: black console; cygwin telnet: no action, new 
prompt)

With worker.ajp13w.host=127.0.0.1

1) No answer (windows telnet: black console; cygwin telnet: no action, new 
prompt)
2) No answer (windows telnet: black console; cygwin telnet: no action, new 
prompt)

telnet doesn't work at all, no connection to any server on the local pc, in 
the intranet or internet (perhaps a firewall/proxy/ntlm setting).

 Could this be an interaction between IPv4 and IPv6? Try:
 C: nslookup localhost

nslookup localhost
Server:  dns.xyz.local
Address:  a.b.c.d

Non-authoritative answer:
Name:localhost.domainname.local
Address:  127.0.0.1

 If only by curiosity, maybe Jessica-Aileen could try
 worker.ajp13w.host=localhost.

That doesn't make a difference. It doesn't work.

 Jessica-Aileen, can you enable mod_jk's DEBUG logging? It might be 
 instructive
 to see what it's trying to load when you give it localhost. I haven't 
 checked
 the code, but it might tell us what's going on with its name resolution.

See attachment. By the way: The description of prefer_ipv6 is unclear. I 
used  worker.ajp13w.prefer_ipv6=0, but the omission doesn't make a 
difference. It doesn't work either.

 For the OP's specific problem, she need to see how localhost is resolving.
 Most systems define it in the local hosts file, either /etc/hosts (*nix) 
 or
 c:\Windows\system32\etc\hosts.

There is _no_ _entry_ in the hosts file, it is commented out  - which is the 
_default_ for Windows! See 
http://serverfault.com/questions/4689/windows-7-localhost-name-resolution-is-handled-within-dns-itself-why

# localhost name resolution is handled within DNS itself.
#   127.0.0.1   localhost
#   ::1 localhost

Regards,
Jessica




isapi_redirect.log
Description: Binary data


smime.p7s
Description: S/MIME cryptographic signature

AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work

2014-04-03 Thread Alten, Jessica-Aileen 
 A bit guessing here :
 
 You have :
   worker.ajp13w.host=localhost
 
 and
 
   jk_open_socket::jk_connect.c (735): connect to 0.0.0.0:8009 failed
  (errno=49)
 
 is localhost == 0.0.0.0  ?
 
  From the point of view of mod_jk/isapi, should it not be 127.0.0.1 ?

Your answer points to the right direction.
0.0.0.0 means: any configured IPv4-Address on this computer, see

http://serverfault.com/questions/78048/whats-the-difference-between-ip-addre
ss-0-0-0-0-and-127-0-0-1

In principle this is ok at first. The Ajp13 Connector was configured in
server.xml to listen at any IPv4 address on port 8009 - which is the default
setting. But the connector can't find any suitable address.

The problem is: The new Tomcat-Connector can't parse
worker.ajp13w.host=localhost, instead localhost must be replaced with
127.0.0.1, this works!

In my eyes this is a big fat bug, because most documentation on workers use
localhost. localhost is actually the default for the host connection
directive.

The new worker directive prefer_ipv6 doesn't change this behavior.

Regards,
Jessica








smime.p7s
Description: S/MIME cryptographic signature

AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work

2014-04-03 Thread Alten, Jessica-Aileen 
 -Ursprüngliche Nachricht-
 Von: André Warnier [mailto:a...@ice-sa.com]
 Gesendet: Donnerstag, 3. April 2014 15:36
 An: Tomcat Users List
 Betreff: Re: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not
 work
 
 Alten, Jessica-Aileen wrote:
  A bit guessing here :
 
  You have :
worker.ajp13w.host=localhost
 
  and
 
jk_open_socket::jk_connect.c (735): connect to 0.0.0.0:8009
 failed
  (errno=49)
  is localhost == 0.0.0.0  ?
 
   From the point of view of mod_jk/isapi, should it not be
 127.0.0.1 ?
 
  Your answer points to the right direction.
  0.0.0.0 means: any configured IPv4-Address on this computer, see
 
  http://serverfault.com/questions/78048/whats-the-difference-between-
 ip
  -addre
  ss-0-0-0-0-and-127-0-0-1
 
  In principle this is ok at first. The Ajp13 Connector was configured
  in server.xml to listen at any IPv4 address on port 8009 - which is
  the default setting. But the connector can't find any suitable
 address.
 
  The problem is: The new Tomcat-Connector can't parse
  worker.ajp13w.host=localhost, instead localhost must be replaced
  with 127.0.0.1, this works!
 
  In my eyes this is a big fat bug, because most documentation on
  workers use localhost. localhost is actually the default for the
  host connection directive.
 
  The new worker directive prefer_ipv6 doesn't change this behavior.
 
 
 Hi.
 
 Can you please really check this ?
 
 Open a command window on that server, and do ping localhost.
 It should tell you what it understands by localhost.
 Copy and paste the result here :

ping localhost

Ping wird ausgeführt für xyz.uv.local [127.0.0.1] mit 32 Bytes Daten:
Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128
Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128
Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128
Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128

Ping-Statistik für 127.0.0.1:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms




smime.p7s
Description: S/MIME cryptographic signature

tomcat-connectors-1.2.39-windows-x86_64-iis does not work

2014-04-02 Thread Alten, Jessica-Aileen 
Hi all,

I have a problem with the new release of the tomcat-connector (1.2.39) for
64 Bit Windows (isapi_redirect.dll), binary download.
The older versions worked like a charm under Windows Server 2008 R2 64 Bit
and Windows 7 64 Bit, even in a loadbalancing configuration. But after
switching to the new 1.2.39 version, no connection between IIS and Tomcat
(6.0.39, 7.0.52) can be established. 

The isapi_redirect log says:
[Wed Apr 02 13:23:36.319 2014] [5676:2148] [info]
jk_open_socket::jk_connect.c (735): connect to 0.0.0.0:8009 failed
(errno=49)
[Wed Apr 02 13:23:36.319 2014] [5676:2148] [info]
ajp_connect_to_endpoint::jk_ajp_common.c (1019): Failed opening socket to
(0.0.0.0:8009) (errno=49)
[Wed Apr 02 13:23:36.319 2014] [5676:2148] [error]
ajp_send_request::jk_ajp_common.c (1659): (ajp13w) connecting to backend
failed. Tomcat is probably not started or is listening on the wrong port
(errno=49)
[Wed Apr 02 13:23:36.319 2014] [5676:2148] [info]
ajp_service::jk_ajp_common.c (2669): (ajp13w) sending request to tomcat
failed (recoverable), because of error during request sending (attempt=2)
[Wed Apr 02 13:23:36.319 2014] [5676:2148] [error]
ajp_service::jk_ajp_common.c (2689): (ajp13w) connecting to tomcat failed.
[Wed Apr 02 13:23:36.319 2014] [5676:2148] [info] service::jk_lb_worker.c
(1514): service failed, worker ajp13w is in error state
[Wed Apr 02 13:23:36.319 2014] [5676:2148] [info] service::jk_lb_worker.c
(1594): All tomcat instances are busy or in error state
[Wed Apr 02 13:23:36.319 2014] [5676:2148] [error] service::jk_lb_worker.c
(1599): All tomcat instances failed, no more workers left
[Wed Apr 02 13:23:36.319 2014] [5676:2148] [error]
HttpExtensionProc::jk_isapi_plugin.c (2327): service() failed with http
error 503


The worker configuration is: 
# workers.properties.minimal -
#
worker.list=wlb,jkstatus
#
worker.ajp13w.type=ajp13
worker.ajp13w.host=localhost
worker.ajp13w.port=8009
#
worker.wlb.type=lb
worker.wlb.balance_workers=ajp13w
#
worker.jkstatus.type=status
#

The configuration is a rudimentary version of the productive system
(concerning worker.wlb.type=lb), where three Tomcat instances are running
on a server.

The log file was absolutely clean (only init and terminate messages) before
version 1.2.39 and is clean again after switching back to version 1.2.37,
the connection between IIS and Tomcat is working, port 8009 works with
1.2.37. 
In both cases Tomcat is running and listening to the right port. I've
restarted the systems after changing the Dlls.

Can anybody help with this problem?

Thanks in advance,
Jessica



smime.p7s
Description: S/MIME cryptographic signature