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 <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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
