tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Eggers <>
Subject Re: Working mod_jk related to loglevel with wildfly?
Date Tue, 10 Jun 2014 19:45:07 GMT
Hash: SHA1

On 6/10/2014 12:35 PM, André Warnier wrote:
> Mark Eggers wrote:
>> 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 "" 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 <form> 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 its AJP implementation).
>> If Firefly does not work, then the issue might be with Firefly's 
>> configuration (or Firefly and Wicket).
>> If neither work, then that's a puzzle.
>> . . . . just my (coffee-less) 2 cents
> Now wait, Firefly ? Is that linked to the coffee-less state ?

No, probably too much Netflix.

Wildfly it is.

. . . 2 cents now with more coffee

Version: GnuPG v1.4.13 (MingW32)
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message