Re: Severe performance issues on images

[Jim Lindqvist]

Hi Christopher,

Thank you for your insights and sorry for a late reply.

This specific issue seemed do be because of limited bandwidth at the data
centre and it had now been fixed.
We are having some other problem as well, but these seem to come from
inefficient modules at the moment and we are investigating at full pace.


> What is the JkMount directive(s) that you are trying to undo with
> JkUnMount?

JkMount /* customer


> Whenever you turn off /Tomcat/ they get fast again? Do you just have
> to stop Tomcat or do you have to de-configure it in httpd.conf?

Only stopping Tomcat is required. This would correspond with the bandwidth
issue.


> Wait, you have a server with 64GiB of RAM? Cool. And it serves images
> for a living? Weird.

It is both cool and weird. :P
The reason for 64Gb is basically that when things break down, more ram and
cpu delays the problem. We are looking for ways to reduce memory usage.


> Up. Grade.

We are looking into it, but 7.0.26 seems to be associated with this Ubuntu
version.
Is it a huge difference? I really don't want to rock this boat any more
that absolutely necessary.


Again, thank you for your time and insights!


Best Regards


Jim




On 24 June 2014 14:45, Christopher Schultz 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Jim,
>
> On 6/23/14, 4:21 PM, Jim Lindqvist wrote:
> > I have I server with Apache and Tomcat through jk_mod and the
> > perfonrmance is awful. This is mostly confined to images as far as
> > I know, but it is hard to tell.
> >
> > The images are served from Apache with the help of the following
> > lines: # Serve static content from /resources and /data using
> > Apache instead of Tomcat worker Alias /resources
> > /var/lib/tomcat7/webapps/customer/resources JkUnMount /resources/*
> > customer Alias /data /var/lib/tomcat7/webapps/customer/data
> > JkUnMount /data/* customer
>
> What is the JkMount directive(s) that you are trying to undo with
> JkUnMount?
>
> > It seems that whenever Tomcat is running, Apache grinds to almost
> > standstill, but whenever I tun off apache images seems to spring to
> > life again.
>
> Whenever you turn off /Tomcat/ they get fast again? Do you just have
> to stop Tomcat or do you have to de-configure it in httpd.conf?
>
> > I could really use some input. I feel like I have tries all the
> > settings I can find, but any changes seems to make the situation
> > worse and it doesn't get better when I turn the settings back.
>
> Can you give us some performance numbers? How have you tested?
>
> > All the guides I can find focus on servers from 64Mb - 512Mb, but I
> > can get up to 64Gb and some serious processing power. I don't mind
> > using a less than perfect configuration as long as it works.
>
> Wait, you have a server with 64GiB of RAM? Cool. And it serves images
> for a living? Weird.
>
> > This is the output from version.sh: Using CATALINA_BASE:
> > /usr/share/tomcat7 Using CATALINA_HOME:   /usr/share/tomcat7 Using
> > CATALINA_TMPDIR: /usr/share/tomcat7/temp Using JRE_HOME:
> > /usr/lib/jvm/java-7-oracle Using CLASSPATH:
> >
> /usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-juli.jar
> >
> >
> Server version: Apache Tomcat/7.0.26
>
> Up. Grade.
>
> What version of Apache httpd? What version of mod_jk? What is your
> mod_jk configuration (workers.properties)?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJTqXMGAAoJEBzwKT+lPKRYPhkP+wV2ecvTUrKUy+r/B1fYfXxQ
> rpczIZfYXpYnRlz9dOFtd5H1H6fuxa851Biwk7tCiC+tB1OJl8sY1OFHzX5AzheH
> dty5n1jIzZgIOF+fURgkMvz7Ukx8gOFD5uxttt02ZzsYeKtJWeTWm7yviPa09LYv
> bu9k7d11WQNAF1R83HPfJhkELV7kT/vAAGkFLfVq/d83EsjUx8kSzyqJu1WDw1T6
> AzBKxJh4+JN4+zayymfF0HsHWL/VfwyYiQAAnwd7NpeWEmtpgUEy9heEze0Y1le0
> 8zCBhIkcLTyKU+ipZIW4av2k6vIuPhrgzjx2GuizRqXHTiqFmfFt3T8RPdEcPPyB
> UqYqIxgtNxWFA6pzNDdoQI5KKY920TSpdACBr8HBQBUQpSIuUjns+bXDAKdAkLQd
> UiqDz8cSxXVJnmyshv+ZIK16hkU9xfalqYB7LoqPgBdCESnJHUYssNT6SfTScLRC
> jeCyvELYv0aSaeKX/9PlC3D3bmU5L+FS06bRxmF2N8Q8YPFVRrw8mWYaIA2HFcwm
> LbJEoVEYGZcE1qoh4hoqp/bzfjXWiJ8i9+4ldqsKHakVfyCxnmbHoiDjoZABE4kk
> fzOWIEapbjVshHr1FdPo/xyb2HIzgUPqTgZwdf0bM5MabY2aUzOKRETgL8z8b8Ck
> vTOtBPphAfBnDrX5bUkm
> =6/W1
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

CVE-2014-0224

[Jeffrey Janner]

Does anyone know of a way to mitigate this vulnerability until the latest 
OpenSSL patch can be applied to the Native Libraries?
Perhaps limiting the cipher list to the list of strongest ciphers available 
that are supported by the major browsers?
Is there a listing somewhere of the cipher lists supported by those browsers?

Jeffrey Janner
Sr. Network Administrator
jeffrey.jan...@polydyne.com
PolyDyne Software Inc.
Main:   512.343.9100
Direct:  512.583.8930

 [cid:image002.png@01CC0FB7.4FF43CE0]

Speed, Intelligence & Savings in Sourcing

WsSessionListener closes WebSocket Session on unprotected endpoint

[Robert Winch]

= Description

I believe I may be experiencing a bug in Tomcat or simply misinterpreting
JSR 356. Any thoughts on how to resolve the issue or if I a bug should be
created would be welcome. To reproduce:

1) Authenticate to the application over HTTP. In my instance I am using
Spring Security which overrides the HttpServletRequest using an
HttpServletRequestWrapper

2) Open a WebSocket connection over an "unprotected endpoint"

3) Wait for the HttpSession to timeout while using the WebSocket connection.

4) When the HttpSession times out, the WebSocket connection is closed by
WsSessionListener

JSR 356 states

"If the websocket endpoint is not a protected resource, ... the user
identity ... *may* become invalid...without the websocket implementation
needing to close the connection". The full excerpt can be found below:

> In the case where a websocket endpoint is a protected resource in the web
> application (see Chapter 8), that is to say, requires an authorized user
to
> access it, then the websocket implementation must ensure that the
websocket
> endpoint does not remain connected to its peer after the underlying
> implementation has decided the authenticated identity is no longer valid.
> [WSC-7.2-3] This may happen, for example, if the user logs out of the
containing
> web application, or if the authentication times out or is invalidated for
some
> other reason.
>
> On the other hand, if the websocket endpoint is not a protected resource
in the
> web application, then the user identity under which an opening handshake
> established the connection may become invalid or change during the
operation of
> the websocket without the websocket implementation needing to close the
> connection.

Should the WebSocket connection be closed when the session expires in this
instance? Perhaps this is just that I am misunderstanding the JSR which
states *may* instead of *must*. I'm not sure that is the case since a must
in this phrasing does not make much sense. For what it is worth, Jetty does
not close the connection in this instance.

 Another point of interest is that we get a NullPointerException in the
WsServerContainer when unregistering the session. Is this a possible bug
since it is logged at SEVERE?

= Complete Example

You can find a complete example on github [1]. The steps to reproduce are:

1) Clone the repository and use the wssessionlistener branch or download
from [2]

2) Ensure you have installed Maven and run "mvn tomcat7:run"

3) Visit http://localhost:8080/spring-websocket-portfolio/traditional/

4) Authenticate with the username "fabrice" and the password "fab123"

5) Wait 1 minute (the session is set to expire in a minute)

6) The WebSocket session will be closed We also see the following
stacktraces in the terminal. For a formatted version of the stack see the
linked gist [3].

Jun 25, 2014 11:34:19 AM org.apache.catalina.session.StandardSession expire
SEVERE: Session event listener threw exception
java.lang.NullPointerException
at
org.apache.tomcat.websocket.server.WsServerContainer.unregisterAuthenticatedSession(WsServerContainer.java:367)
at
org.apache.tomcat.websocket.server.WsServerContainer.unregisterSession(WsServerContainer.java:344)
at
org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSession.java:494)
at org.apache.tomcat.websocket.WsSession.doClose(WsSession.java:417)
at org.apache.tomcat.websocket.WsSession.close(WsSession.java:394)
at
org.apache.tomcat.websocket.server.WsServerContainer.closeAuthenticatedSession(WsServerContainer.java:377)
at
org.apache.tomcat.websocket.server.WsSessionListener.sessionDestroyed(WsSessionListener.java:40)
at
org.apache.catalina.session.StandardSession.expire(StandardSession.java:808)
at
org.apache.catalina.session.StandardSession.isValid(StandardSession.java:658)
at
org.apache.catalina.session.ManagerBase.processExpires(ManagerBase.java:534)
at
org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase.java:519)
at
org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1352)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1530)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1519)
at java.lang.Thread.run(Thread.java:744)

11:34:20 [clientOutboundChannel-9] WebSocketServerSockJsSession -
Terminating connection after failure to send message to client.
java.lang.IllegalArgumentException: Cannot send message after connection
closed.
at org.springframework.util.Assert.isTrue(Assert.java:65)
at
org.springframework.web.socket.adapter.AbstractWebSocketSession.sendMessage(AbstractWebSocketSession.java:97)
at
org.springframework.web.socket.sockjs.transport.session.WebSocketServerSockJsSession.writeFra

Re: Getting host name inside tomcat realm implementation

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 6/25/14, 10:39 AM, Mark Thomas wrote:
> On 25/06/2014 15:35, Christopher Schultz wrote:
>> Konstantin,
>> 
>> On 6/25/14, 5:23 AM, Konstantin Kolinko wrote:
>>> 2014-06-24 21:09 GMT+04:00 Neeraj Sinha 
>>> :
 I am using form based authentication (tomcat 7.0.34) and I 
 have the implementation of custom realm class which extends 
 RealmBase class. Inside the getPrincipal() method 
 implementation, I am calling backend service to save some
 login details. I need to pass host name to backend (I have 2 
 applications running under different hosts connected to same 
 DB, so to know the login source of user). Hosts are
 configured in server.xml.
 
 Any help/links/URL much appreciated.
>> 
>>> A Realm is just a DAO class used by Authenticator valves. The 
>>> idea is that a Realm can be shared between web applications
>>> (by placing it at the Host or Engine level). If you want access
>>> to the request, you should implement an Authenticator.
>> 
>>> There have been some discussions on changing APIs of 
>>> Authenticators and Realms to be more friendly for extension,
>>> but nobody came up with a specific idea.
>> 
>> I have some code laying around for extending RealmBase to allow 
>> changes to the password-derivation algorithm, but it wouldn't 
>> change the public API of the Realm class in a way that wasn't 
>> backward-compatible.
>> 
>> Changing Realm to include additional information (i.e. the 
>> request) would break that API. I can't imagine we'd change that
>> API for Tomcat 7 and it's getting pretty late for Tomcat 8 (8.0.9
>> was just voted "stable").
> 
> See the release notes for which APIs may change and how. For Realm,
> we can add new methods and deprecate existing ones but we can't
> change or remove existing methods.

Understood.

For the same of argument, let's say that we add a new method:

  public boolean authenticate(String username, String password,
HttpServletRequest request)

Since it's not abstract, it's backward-compatible, at least from a
build and runtime perspective (e.g. no NoSuchMethodError will occur).

However, if we add that method, it makes sense that we might use it.
And if a client has overridden authenticate(String username,String
password) then their method doesn't get called anymore.

Adding a method like setRequest(HttpServletRequest) would be
reasonable, except that Realm objects are shared and expected to be
threadsafe, so that's not going to work.

For securityfilter, what "we" implemented (before my involvement) was
a second interface (with a method that includes HttpServletRequest)
that could be optionally implemented. If the second interface was
implemented by the Realm, then the alternative method was invoked. If
the optional interface was not implemented, then we called the "old"
method.

The above is really the only good way I can think of off the top of my
head to provide extra information to the Realm in a completely
backward-compatible way.

A bad way I can think of would be to provide the extra information as
a thread local variable that the Realm implementation can sniff. I
feel like using threadlocal in this way is simply a lazy way to avoid
passing objects in the traditional way (i.e. on the stack).

There is also the complexity introduced by the fact that there are
different authenticate() methods for every type of authentication
(basic/form, digest, and SSL). That means that we basically need 4
flavors of the same method(s) with extra data being passed-into the
method.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTquFMAAoJEBzwKT+lPKRYp+8P/RqN5Dhs31ijnLCqIl5rfPK+
UAgtUueapxSU2yMGHC8u9Lh95uhfWhnHXMo+3LDNDlgM/mF0K0Otad9wNot2BN+C
8wCqvkthHkX6nOVulDghnCtmlBTOVDcdQbzuzJxxeitEwfho/iQnZsFfB4xZN5ID
sK13CYSVjWB+eSz7esLNGX6SfG6QK1UWktaVlgbvHho9ezCDNo45Elg5+xVAYsBl
snPgqDgeIypBBuRe6EcUB8wxy5/Mfqq7hwQBWb1mGYq7Plu3vvtyP4Ng2G1jp5tk
awhlE86FhSHlNhW6s2l2dVs3JCNcn6albMvr04kxGaKMoMQGkHWLSk+D+vF/JDHX
mwn4NKb7gfzOqcDaNeOOe8yqEhAeSKIBpzvQKL9yjW3kmKFcuH9ihp9ETZbXM8IQ
+ejyEH/JP8NcdhgjKSW6rVKhq1eQhSAnjahQbFg2C6yL0pGbR35wlrAE+xR0eb2x
nG2ombckvsopBtbAS0SnKnybSk+kDvFujpeWYL6F4cPBYcRCZLYa9bWe77ewVmXk
FJZg98g5Vu+E8qDFs32zUlAsQShlxFX+1CIhi+riUx06IeahVAxLwZlo61nbAn3K
8TmvtK/eKle76XoF+2aI0nHLUiuAsGJZaQ39svPs2TEFK0L3MRJVhBLp+b8u5qGo
2yKirH7okrznvxWajst6
=9iw2
-END PGP SIGNATURE-

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

Re: Getting host name inside tomcat realm implementation

[Mark Thomas]

On 25/06/2014 15:35, Christopher Schultz wrote:
> Konstantin,
> 
> On 6/25/14, 5:23 AM, Konstantin Kolinko wrote:
>> 2014-06-24 21:09 GMT+04:00 Neeraj Sinha 
>> :
>>> I am using form based authentication (tomcat 7.0.34) and I
>>> have the implementation of custom realm class which extends
>>> RealmBase class. Inside the getPrincipal() method
>>> implementation, I am calling backend service to save some login
>>> details. I need to pass host name to backend (I have 2
>>> applications running under different hosts connected to same
>>> DB, so to know the login source of user). Hosts are configured
>>> in server.xml.
>>> 
>>> Any help/links/URL much appreciated.
> 
>> A Realm is just a DAO class used by Authenticator valves. The
>> idea is that a Realm can be shared between web applications (by
>> placing it at the Host or Engine level). If you want access to
>> the request, you should implement an Authenticator.
> 
>> There have been some discussions on changing APIs of 
>> Authenticators and Realms to be more friendly for extension, but 
>> nobody came up with a specific idea.
> 
> I have some code laying around for extending RealmBase to allow 
> changes to the password-derivation algorithm, but it wouldn't
> change the public API of the Realm class in a way that wasn't 
> backward-compatible.
> 
> Changing Realm to include additional information (i.e. the
> request) would break that API. I can't imagine we'd change that API
> for Tomcat 7 and it's getting pretty late for Tomcat 8 (8.0.9 was
> just voted "stable").

See the release notes for which APIs may change and how. For Realm, we
can add new methods and deprecate existing ones but we can't change or
remove existing methods.

Mark

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

Re: Getting host name inside tomcat realm implementation

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Konstantin,

On 6/25/14, 5:23 AM, Konstantin Kolinko wrote:
> 2014-06-24 21:09 GMT+04:00 Neeraj Sinha
> :
>> I am using form based authentication (tomcat 7.0.34) and I have
>> the implementation of custom realm class which extends RealmBase
>> class. Inside the getPrincipal() method implementation, I am
>> calling backend service to save some login details. I need to
>> pass host name to backend (I have 2 applications running under
>> different hosts connected to same DB, so to know the login source
>> of user). Hosts are configured in server.xml.
>> 
>> Any help/links/URL much appreciated.
> 
> A Realm is just a DAO class used by Authenticator valves. The idea
> is that a Realm can be shared between web applications (by placing
> it at the Host or Engine level). If you want access to the request,
> you should implement an Authenticator.
> 
> There have been some discussions on changing APIs of
> Authenticators and Realms to be more friendly for extension, but
> nobody came up with a specific idea.

I have some code laying around for extending RealmBase to allow
changes to the password-derivation algorithm, but it wouldn't change
the public API of the Realm class in a way that wasn't
backward-compatible.

Changing Realm to include additional information (i.e. the request)
would break that API. I can't imagine we'd change that API for Tomcat
7 and it's getting pretty late for Tomcat 8 (8.0.9 was just voted
"stable").

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTqt4/AAoJEBzwKT+lPKRY/eMP/jdZbi9EjpgEbjVwT8Luk8WJ
vqKCwwMovOsWadNAxCgusQnteaGqHTTK4a3hIMCzg0BdKWFKIPQ3RkWj6yMrbBEN
9ETJlMCmn6WrnZM60ii6Rbh8A1IHeYL6MyZnWyCsxe1cklMymkpylwSu0oiKAqj5
nbklA/CUorh4vTCwxJ72ELGeN+G4ubHPE6JLj+rFb21ou5QDakHzZtXA7mCHECQk
CUQ/lZlnvc7ZolsyAnX6R1XU8u5eB7HGeGVTnm87CMT4KviInBjlPHnJ7bVXgg10
5iUO6eyjTE7lG2ZKxApPDOZ9r4mJ7E2Naj6HuJxRb2ur7/PppQboRXCjW9u0Tw2F
4BAq+P99qeCwblCbMJj0+icZklHK9vLzKp3OthXFQt0pDWgZ2cwnYDpMbscI56nM
cXPj2W1DAcv3o6hiEbqTgxZ+IO4W8B68L8XQE6sMJkUYAGVSDLPmFb00bFi4bRYU
G2UE+JuoU407U4by5WNJlU7diyQHZ8Ei4p45DbYhQUwsKCG19S05LDaFVnle+Jrk
4hax0tKtcYEqPvO0uohICCiL/Mv8KjQN8E+qdTnGQ4UnajpcxU5QAH4H2n1uy2NA
E5Vq5vsT67NCmdHlYm1IsBFzsCIJDcEkmAoBG/iixYRhSvjADEcTQ3cztOpFLH5s
dddwVbBWFme2TX+LPRhv
=JGaU
-END PGP SIGNATURE-

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

Re: Working mod_jk related to loglevel with wildfly?

[Konstantin Kolinko]

2014-06-25 11:57 GMT+04:00 Martin Stolk :
> Hello,
>
> Sorry for the delay, I was busy but i also did some more testing. The result 
> from those tests is that is works oke if the apache/mod_jk are on the same 
> server as wildfly.
> In my original situation apache/mod_jk are on server one and wildfly on 
> server two. So perhaps it is related to mod_jk. Are the options I can try? I 
> don't think it is a timeout because the page is returning but with 
> semi-colons.
>

You shall try to find, what layer is responsible for this behaviour.

Consider
1. Inspecting the HTTP traffic
E.g. with Wireshark.

2. Debugging
http://wiki.apache.org/tomcat/FAQ/Developing#Debugging

3. Try different versions. Did you use the same versions in both
configurations that you tried?

4. Does it work with other sample web applications?

Best regards,
Konstantin Kolinko

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

Re: Getting host name inside tomcat realm implementation

[Konstantin Kolinko]

2014-06-24 21:09 GMT+04:00 Neeraj Sinha :
> I am using form based authentication (tomcat 7.0.34) and I have the
> implementation of custom realm class which extends RealmBase class. Inside
> the getPrincipal() method implementation, I am calling backend service to
> save some login details. I need to pass host name to backend (I have 2
> applications running under different hosts connected to same DB, so to know
> the login source of user). Hosts are configured in server.xml.
>
> Any help/links/URL much appreciated.

A Realm is just a DAO class used by Authenticator valves. The idea is
that a Realm can be shared between web applications (by placing it at
the Host or Engine level). If you want access to the request, you
should implement an Authenticator.

There have been some discussions on changing APIs of Authenticators
and Realms to be more friendly for extension, but nobody came up with
a specific idea.

Best regards,
Konstantin Kolinko

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

RE: Working mod_jk related to loglevel with wildfly?

[Martin Stolk]

Hello,

Sorry for the delay, I was busy but i also did some more testing. The result 
from those tests is that is works oke if the apache/mod_jk are on the same 
server as wildfly. 
In my original situation apache/mod_jk are on server one and wildfly on server 
two. So perhaps it is related to mod_jk. Are the options I can try? I don't 
think it is a timeout because the page is returning but with semi-colons.



-Oorspronkelijk bericht-
Van: Martin Stolk [mailto:martin.st...@uplearning.nl] 
Verzonden: dinsdag 10 juni 2014 21:57
Aan: Tomcat Users List
Onderwerp: RE: Working mod_jk related to loglevel with wildfly?

Yes I also think it's related to de ajp connector in wildfly. 
This afternoon i tested with mod_proxy and that shows the same problem. Thans 
for the clear explanation.


-Oorspronkelijk bericht-
Van: Mark Eggers [mailto:its_toas...@yahoo.com.INVALID]
Verzonden: dinsdag 10 juni 2014 21:45
Aan: Tomcat Users List
Onderwerp: Re: Working mod_jk related to loglevel with wildfly?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 6/10/2014 12:35 PM, André Warnier wrote:
> Mark Eggers wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>> 
>> On 6/10/2014 8:29 AM, André Warnier wrote:
>>> André Warnier wrote:
 Martin Stolk wrote:
> 
> Hello,
> 
> We are migrating our applications from tomcat to wildfly.
> We are using mod_= jk (1.2.40) to connect apache to the wildfly 
> ajp port.
> 
> When using tomcat there are no problems, but with wilfdly there is 
> a strang= e behavior in our application.
 It is a bit of a puzzle then, why you are asking for help here. 
 Would "http://wildfly.org/gethelp/"; not be a better place to start 
 ?
 
> Our application is written in java (wicket) and when entering a 
> search form= every field fills with a semi-colon after entering 
> the find button. When i= set the JkLogLevel to trace or debug the 
> problems remains but less frequen= tly and not in every form. I 
> also tried different
> ForwardURI** JkOptions, but that make no difference.
 I can't think of a reason off-hand why this should ever make any 
 difference. It would seem that the first thing to look at, is what 
 this "Find" button in the form really does.  Is it just a "submit"
 button, or does it call something (some javascript perhaps) ? Does 
 the  send a POST, or a GET request ?
 
> Can anyone help me where to find a solution?
> 
>>> Ok, I'll bite again. As I understand the issue, you have the 
>>> following schema :
>>> 
>>> B + BA <-HTTP-> A + M <-AJP-> E + EA
>>> 
>>> where :
>>> 
>>> - B is the browser - BA is the "application" in the browser.
>>> That can be pure HTML, or HTML + javascript, or a Java Applet, or 
>>> whatever - A is the Apache httpd front-end - M is the mod_jk module 
>>> running inside Apache httpd - E is the Servlet Engine (Tomcat or
>>> Wildfly) - EA is the java application running inside of E
>>> 
>>> and we assume that the only element which varies is E, which is 
>>> either Tomcat or Wildfly.
>>> 
>>> You say that when E is Tomcat, everything works fine. But when E is 
>>> Wildfly, strange things happen.
>>> 
>>> Given that B + BA are the same and would send the same HTTP requests 
>>> in both cases to A, - there is no reason why A would do anything 
>>> different when E is Wildfly, than when E is Tomcat.
>>> A does not even know which Servlet Engine E is being used. - there 
>>> is no reason why M would do anything different when E is Wildfly, 
>>> than when E is Tomcat. M does not even know which Servlet Engine E 
>>> is being used. It just knows that it is talking to an AJP connector 
>>> of a webserver, and that it needs to "translate" the HTTP request, 
>>> to an AJP request, before forwarding it.
>>> 
>>> The only impact that I can think of, of changing the mod_jk 
>>> loglevel, is to make mod_jk perhaps a little bit slower, because it 
>>> has to log more. (But we should be talking of at most milliseconds 
>>> here).
>>> 
>>> So, on the face of it, logically, I would think that if there is a 
>>> problem when E is Wildfly, the problem must be with Wildfly, or with 
>>> how Wildfly is running the EA application.
>>> 
>>> Or else, our premise is wrong, and BA is not exactly the same in 
>>> both cases, and does not send exactly the same thing to A.
>>> But since BA "comes from" E + EA originally, that would also mean 
>>> that the problem is with Wildfly + the EA application.
>>> 
>>> So I would still go to the Wildfly support list, present the same 
>>> case as you did above, and ask them if they have a clue as to what 
>>> may be happening.
>> 
>> 
>> To extend André's excellent examination . . . .
>> 
>> It would be nice if you could remove A + M from the equation. In 
>> other words:
>> 
>> B + BA <-HTTP-> E + EA
>> 
>> Then vary E (Wildfly or Tomcat).
>> 
>> If both work, then the issue might be with Firefly's AJP 
>> configuration (or i