You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Martin Stolk <ma...@uplearning.nl> on 2014/06/10 13:49:56 UTC
Working mod_jk related to loglevel with wildfly?
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.
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.
Can anyone help me where to find a solution?
Martin Stolk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Working mod_jk related to loglevel with wildfly?
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014-06-25 11:57 GMT+04:00 Martin Stolk <ma...@uplearning.nl>:
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Working mod_jk related to loglevel with wildfly?
Posted by Martin Stolk <ma...@uplearning.nl>.
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.stolk@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_toasted@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 <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
/mde/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTl2BDAAoJEEFGbsYNeTwtQQEIAKVkJDQ4BDSsijLIxzQLX98B
5bGLcWQr794euBMiCh/6sVqD5PjNPwHhKYcbaGRl+GMauLFxvPikODVqQD+y9C+8
k5ZrAbC+nXTQxsNDY8NvzphHLApHjrJIRzHUBRDNDP+0ptgMBKCA46kkWAvq8eXZ
WRsHQ0LvffV9U+yXkA3+gbJgHB0w9YuCz+7nvaCzW9nH2CyRpaxZgY1B2NqBwnM5
Xca9XeosQWBgfIkS3HQz6csyZT/7aAPoTED5fq/+vMtmN2nw13rNSxIZklCL8Qwq
xcMjtNSsNuyqmPofa75aczDZc/iJ8yYuYSRNGPn4Yoa5GNmzOmEiBDV5nen/0WI=
=4QYn
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Working mod_jk related to loglevel with wildfly?
Posted by Martin Stolk <ma...@uplearning.nl>.
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_toasted@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 <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
/mde/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTl2BDAAoJEEFGbsYNeTwtQQEIAKVkJDQ4BDSsijLIxzQLX98B
5bGLcWQr794euBMiCh/6sVqD5PjNPwHhKYcbaGRl+GMauLFxvPikODVqQD+y9C+8
k5ZrAbC+nXTQxsNDY8NvzphHLApHjrJIRzHUBRDNDP+0ptgMBKCA46kkWAvq8eXZ
WRsHQ0LvffV9U+yXkA3+gbJgHB0w9YuCz+7nvaCzW9nH2CyRpaxZgY1B2NqBwnM5
Xca9XeosQWBgfIkS3HQz6csyZT/7aAPoTED5fq/+vMtmN2nw13rNSxIZklCL8Qwq
xcMjtNSsNuyqmPofa75aczDZc/iJ8yYuYSRNGPn4Yoa5GNmzOmEiBDV5nen/0WI=
=4QYn
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Working mod_jk related to loglevel with wildfly?
Posted by Mark Eggers <it...@yahoo.com.INVALID>.
-----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 <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
/mde/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTl2BDAAoJEEFGbsYNeTwtQQEIAKVkJDQ4BDSsijLIxzQLX98B
5bGLcWQr794euBMiCh/6sVqD5PjNPwHhKYcbaGRl+GMauLFxvPikODVqQD+y9C+8
k5ZrAbC+nXTQxsNDY8NvzphHLApHjrJIRzHUBRDNDP+0ptgMBKCA46kkWAvq8eXZ
WRsHQ0LvffV9U+yXkA3+gbJgHB0w9YuCz+7nvaCzW9nH2CyRpaxZgY1B2NqBwnM5
Xca9XeosQWBgfIkS3HQz6csyZT/7aAPoTED5fq/+vMtmN2nw13rNSxIZklCL8Qwq
xcMjtNSsNuyqmPofa75aczDZc/iJ8yYuYSRNGPn4Yoa5GNmzOmEiBDV5nen/0WI=
=4QYn
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Working mod_jk related to loglevel with wildfly?
Posted by André Warnier <aw...@ice-sa.com>.
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 <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 ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Working mod_jk related to loglevel with wildfly?
Posted by Mark Eggers <it...@yahoo.com.INVALID>.
-----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 <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
/mde/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTlzUHAAoJEEFGbsYNeTwtcL8IAIl4MPqMH9mvNZVOYT9b3vXS
4GcNMSRjv8BbizQYq+KkK4Q2vro7sE7MdTwKyepEhET1LWFrcWtIFHiLkm7PJebU
nlrA0n6LgsP2bzrdzvfmiZ8BgezjuU0Jp73EYa2JsK3CpLJFRz4Rjd2HGxwjm9lv
qnGUgetudnceQgcNroFq9IOvyv85zImOdG19wiHU2BXDhoHNrW72lNl3HtdCE3I0
vG8tC6uC/99cIlcSJZUCkcsGfddVhPkoNAPV4qoR9+InUV1TmLiniFwH40jQ3fb3
4iuVsW1pAjIugOoaIMXp2aF/f64URyRjMjUY3zk/W0VUJamPAM85iiR0OYMv5O0=
=/Knt
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Working mod_jk related to loglevel with wildfly?
Posted by André Warnier <aw...@ice-sa.com>.
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 <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 unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Working mod_jk related to loglevel with wildfly?
Posted by André Warnier <aw...@ice-sa.com>.
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 <form> send a POST, or a GET request ?
>
> Can anyone help me where to find a solution?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org