You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Henri Gomez <he...@gmail.com> on 2007/04/23 12:26:11 UTC
More on i5/OS and some modifications needed
Hi to all,
I'm still working on i5/OS V5R4 port and I'm facing the following problem.
i5/OS is an EBCDIC system, but in V5R4, IBM decided, for modules
writer ease, to make all HTTP and APR routines works in UTF.
That's fine but all the native runtime functions still works in EBDIC.
So function like strcasecmp compare 2 strings in case unsensitive mode
but works in EBCDIC charsets and as consequence Content-Type !=
Content-type.
Could we use instead the apr_strnatcasecmp, for example in mod_jk.c
for apache 2 ?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Guenter Knauf <fu...@apache.org>.
Hi Henri,
we still need to take care of the change in jk_map_read_properties():
- if (jk_file_exists(f) != JK_TRUE)
+ if ((rc = jk_stat(f, &statbuf)) == -1)
otherwise we cant return time_t *modified since the statbuf isnt initialized.
Guen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Guenter Knauf <fu...@apache.org>.
Hi Henry,
in jk_util.h we have:
#define jk_stat(a, b) stat(a, b)
in jk_map.c we have now:
if (jk_stat(f, &statbuf) != -1)
return JK_FALSE;
previously in 1.2.22 code we had:
if ((rc = stat(f, &statbuf)) == -1)
return JK_FALSE;
am I missing something, or is the logic now inverted?
Guen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Henri Gomez <he...@gmail.com>.
Exact. I'll commit a fix asap
2007/4/25, Jean-Frederic <jf...@gmail.com>:
> On Wed, 2007-04-25 at 09:54 +0200, Henri Gomez wrote:
> > In jklog_cleanup I could see :
> >
> > static apr_status_t jklog_cleanup(void *d)
> > {
> > #ifdef AS400
> > main_log = NULL;
> > #endif
> >
> > d = NULL;
> > return APR_SUCCESS;
> > }
> >
> > Shouldn't it be *d = NULL ?
>
> I think that you should have:
> apr_pool_cleanup_register(p, &main_log, jklog_cleanup, jklog_cleanup);
> if you want to use *d = NULL; to set main_log to NULL.
>
> Cheers
>
> Jean-Frederic
>
> >
> > Also shouldn't we reset main_log and conf->log ?
> >
> >
> > 2007/4/24, Henri Gomez <he...@gmail.com>:
> > > It works ! great.
> > >
> > > Could I commit ?
> > >
> > > Also find a way to fix for i5/OS the HTTP 500 problem
> > >
> > > 2007/4/24, Henri Gomez <he...@gmail.com>:
> > > > You remove completly the apr_pool_cleanup_register(p, conf->log, jklog_cleanup,
> > > > jklog_cleanup) ?
> > > >
> > > > 2007/4/24, Rainer Jung <ra...@kippdata.de>:
> > > > > Great. I think I now understand the problem.
> > > > >
> > > > > Could you try this one relativ to your last change:
> > > > >
> > > > > Index: mod_jk.c
> > > > > ===================================================================
> > > > > --- mod_jk.c (revision 531926)
> > > > > +++ mod_jk.c (working copy)
> > > > > @@ -2539,11 +2539,7 @@
> > > > >
> > > > > static apr_status_t jklog_cleanup(void *d)
> > > > > {
> > > > > - /* set the main_log to NULL */
> > > > > -#ifdef AS400
> > > > > - main_log = null;
> > > > > -#endif
> > > > > -
> > > > > + /* set the log to NULL */
> > > > > d = NULL;
> > > > > return APR_SUCCESS;
> > > > > }
> > > > > @@ -2616,9 +2612,10 @@
> > > > > jkl->logger_private = flp;
> > > > > flp->jklogfp = conf->jklogfp;
> > > > > conf->log = jkl;
> > > > > - if (main_log == NULL)
> > > > > + if (main_log == NULL) {
> > > > > main_log = conf->log;
> > > > > - apr_pool_cleanup_register(p, conf->log, jklog_cleanup,
> > > > > jklog_cleanup);
> > > > > + apr_pool_cleanup_register(p, main_log, jklog_cleanup,
> > > > > jklog_cleanup);
> > > > > + }
> > > > > return 0;
> > > > > }
> > > > >
> > > > > The point is: when I added full virtual server support for all configs I
> > > > > changed the cleanup function to NULL the virtual server logger. It
> > > > > NULLed main_log before. But the only reason it should NULL a logger was
> > > > > the check for NULL in
> > > > >
> > > > > if (main_log == NULL)
> > > > > main_log = conf->log;
> > > > >
> > > > > So if main_log is set once, it never gets reset. This is bad, if the
> > > > > pool from which it got acquired is dead. So we actually need to register
> > > > > the log cleanup only for main_log, because otherwise main_log will
> > > > > always reference an outdated logger. conf->log will be overwritten
> > > > > during each init, no need to reset those.
> > > > >
> > > > > At least that's my theory for it. Could you test this patch?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Rainer
> > > > >
> > > > >
> > > > >
> > > > > Henri Gomez schrieb:
> > > > > > I made it works by adding main_log = NULL in jklog_cleanup
> > > > > >
> > > > > > static apr_status_t jklog_cleanup(void *d)
> > > > > > {
> > > > > > /* set the main_log to NULL */
> > > > > > d = NULL;
> > > > > > main_log = NULL;
> > > > > > return APR_SUCCESS;
> > > > > > }
> > > > > >
> > > > > > Don't forget that jk is initialized twice and on i5/OS in the same
> > > > > > thread, so may be the static var should be reset.
> > > > > >
> > > > > > What do you think of the patch ?
> > > > > >
> > > > > >
> > > > > > 2007/4/24, Rainer Jung <ra...@kippdata.de>:
> > > > > >> main_log is a static in mod_jk.c, which is initialized as NULL.
> > > > > >>
> > > > > >> It gets set inside open_jklog() which gets called once for every virtual
> > > > > >> server by jk_post_config() during server initialization.
> > > > > >>
> > > > > >> The first virtual server inherits its logger conf->log from its
> > > > > >> configuration to main_log. It also registers a cleanup handler which
> > > > > >> will NULL its conf->log, but that should not change main_log.
> > > > > >>
> > > > > >> main_log should never get reset.
> > > > > >>
> > > > > >> To find the problem, it would be best to first reduce the apache config
> > > > > >> to not use any virtual servers.
> > > > > >>
> > > > > >> You can log the value of main_log for debug purposes anywhere in
> > > > > >> mod_jk.c, because its a global static.
> > > > > >>
> > > > > >> Regards,
> > > > > >>
> > > > > >> Rainer
> > > > > >>
> > > > > >> Henri Gomez schrieb:
> > > > > >> > I'm looking for the exception in jk_log. It happen in ws_write right
> > > > > >> > now and I wonder what's the life cycle of main_log.
> > > > > >> >
> > > > > >> > On i5/OS, the init / post are done on the same thread (not the same on
> > > > > >> > Unixes).
> > > > > >> >
> > > > > >> > How is reset the main_log ?
> > > > > >> >
> > > > > >>
> > > > > >> ---------------------------------------------------------------------
> > > > > >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > > > > >> For additional commands, e-mail: dev-help@tomcat.apache.org
> > > > > >>
> > > > > >>
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > > > > > For additional commands, e-mail: dev-help@tomcat.apache.org
> > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > > > > For additional commands, e-mail: dev-help@tomcat.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Jean-Frederic <jf...@gmail.com>.
On Wed, 2007-04-25 at 09:54 +0200, Henri Gomez wrote:
> In jklog_cleanup I could see :
>
> static apr_status_t jklog_cleanup(void *d)
> {
> #ifdef AS400
> main_log = NULL;
> #endif
>
> d = NULL;
> return APR_SUCCESS;
> }
>
> Shouldn't it be *d = NULL ?
I think that you should have:
apr_pool_cleanup_register(p, &main_log, jklog_cleanup, jklog_cleanup);
if you want to use *d = NULL; to set main_log to NULL.
Cheers
Jean-Frederic
>
> Also shouldn't we reset main_log and conf->log ?
>
>
> 2007/4/24, Henri Gomez <he...@gmail.com>:
> > It works ! great.
> >
> > Could I commit ?
> >
> > Also find a way to fix for i5/OS the HTTP 500 problem
> >
> > 2007/4/24, Henri Gomez <he...@gmail.com>:
> > > You remove completly the apr_pool_cleanup_register(p, conf->log, jklog_cleanup,
> > > jklog_cleanup) ?
> > >
> > > 2007/4/24, Rainer Jung <ra...@kippdata.de>:
> > > > Great. I think I now understand the problem.
> > > >
> > > > Could you try this one relativ to your last change:
> > > >
> > > > Index: mod_jk.c
> > > > ===================================================================
> > > > --- mod_jk.c (revision 531926)
> > > > +++ mod_jk.c (working copy)
> > > > @@ -2539,11 +2539,7 @@
> > > >
> > > > static apr_status_t jklog_cleanup(void *d)
> > > > {
> > > > - /* set the main_log to NULL */
> > > > -#ifdef AS400
> > > > - main_log = null;
> > > > -#endif
> > > > -
> > > > + /* set the log to NULL */
> > > > d = NULL;
> > > > return APR_SUCCESS;
> > > > }
> > > > @@ -2616,9 +2612,10 @@
> > > > jkl->logger_private = flp;
> > > > flp->jklogfp = conf->jklogfp;
> > > > conf->log = jkl;
> > > > - if (main_log == NULL)
> > > > + if (main_log == NULL) {
> > > > main_log = conf->log;
> > > > - apr_pool_cleanup_register(p, conf->log, jklog_cleanup,
> > > > jklog_cleanup);
> > > > + apr_pool_cleanup_register(p, main_log, jklog_cleanup,
> > > > jklog_cleanup);
> > > > + }
> > > > return 0;
> > > > }
> > > >
> > > > The point is: when I added full virtual server support for all configs I
> > > > changed the cleanup function to NULL the virtual server logger. It
> > > > NULLed main_log before. But the only reason it should NULL a logger was
> > > > the check for NULL in
> > > >
> > > > if (main_log == NULL)
> > > > main_log = conf->log;
> > > >
> > > > So if main_log is set once, it never gets reset. This is bad, if the
> > > > pool from which it got acquired is dead. So we actually need to register
> > > > the log cleanup only for main_log, because otherwise main_log will
> > > > always reference an outdated logger. conf->log will be overwritten
> > > > during each init, no need to reset those.
> > > >
> > > > At least that's my theory for it. Could you test this patch?
> > > >
> > > > Regards,
> > > >
> > > > Rainer
> > > >
> > > >
> > > >
> > > > Henri Gomez schrieb:
> > > > > I made it works by adding main_log = NULL in jklog_cleanup
> > > > >
> > > > > static apr_status_t jklog_cleanup(void *d)
> > > > > {
> > > > > /* set the main_log to NULL */
> > > > > d = NULL;
> > > > > main_log = NULL;
> > > > > return APR_SUCCESS;
> > > > > }
> > > > >
> > > > > Don't forget that jk is initialized twice and on i5/OS in the same
> > > > > thread, so may be the static var should be reset.
> > > > >
> > > > > What do you think of the patch ?
> > > > >
> > > > >
> > > > > 2007/4/24, Rainer Jung <ra...@kippdata.de>:
> > > > >> main_log is a static in mod_jk.c, which is initialized as NULL.
> > > > >>
> > > > >> It gets set inside open_jklog() which gets called once for every virtual
> > > > >> server by jk_post_config() during server initialization.
> > > > >>
> > > > >> The first virtual server inherits its logger conf->log from its
> > > > >> configuration to main_log. It also registers a cleanup handler which
> > > > >> will NULL its conf->log, but that should not change main_log.
> > > > >>
> > > > >> main_log should never get reset.
> > > > >>
> > > > >> To find the problem, it would be best to first reduce the apache config
> > > > >> to not use any virtual servers.
> > > > >>
> > > > >> You can log the value of main_log for debug purposes anywhere in
> > > > >> mod_jk.c, because its a global static.
> > > > >>
> > > > >> Regards,
> > > > >>
> > > > >> Rainer
> > > > >>
> > > > >> Henri Gomez schrieb:
> > > > >> > I'm looking for the exception in jk_log. It happen in ws_write right
> > > > >> > now and I wonder what's the life cycle of main_log.
> > > > >> >
> > > > >> > On i5/OS, the init / post are done on the same thread (not the same on
> > > > >> > Unixes).
> > > > >> >
> > > > >> > How is reset the main_log ?
> > > > >> >
> > > > >>
> > > > >> ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > > > >> For additional commands, e-mail: dev-help@tomcat.apache.org
> > > > >>
> > > > >>
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > > > > For additional commands, e-mail: dev-help@tomcat.apache.org
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > > > For additional commands, e-mail: dev-help@tomcat.apache.org
> > > >
> > > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Henri Gomez <he...@gmail.com>.
In jklog_cleanup I could see :
static apr_status_t jklog_cleanup(void *d)
{
#ifdef AS400
main_log = NULL;
#endif
d = NULL;
return APR_SUCCESS;
}
Shouldn't it be *d = NULL ?
Also shouldn't we reset main_log and conf->log ?
2007/4/24, Henri Gomez <he...@gmail.com>:
> It works ! great.
>
> Could I commit ?
>
> Also find a way to fix for i5/OS the HTTP 500 problem
>
> 2007/4/24, Henri Gomez <he...@gmail.com>:
> > You remove completly the apr_pool_cleanup_register(p, conf->log, jklog_cleanup,
> > jklog_cleanup) ?
> >
> > 2007/4/24, Rainer Jung <ra...@kippdata.de>:
> > > Great. I think I now understand the problem.
> > >
> > > Could you try this one relativ to your last change:
> > >
> > > Index: mod_jk.c
> > > ===================================================================
> > > --- mod_jk.c (revision 531926)
> > > +++ mod_jk.c (working copy)
> > > @@ -2539,11 +2539,7 @@
> > >
> > > static apr_status_t jklog_cleanup(void *d)
> > > {
> > > - /* set the main_log to NULL */
> > > -#ifdef AS400
> > > - main_log = null;
> > > -#endif
> > > -
> > > + /* set the log to NULL */
> > > d = NULL;
> > > return APR_SUCCESS;
> > > }
> > > @@ -2616,9 +2612,10 @@
> > > jkl->logger_private = flp;
> > > flp->jklogfp = conf->jklogfp;
> > > conf->log = jkl;
> > > - if (main_log == NULL)
> > > + if (main_log == NULL) {
> > > main_log = conf->log;
> > > - apr_pool_cleanup_register(p, conf->log, jklog_cleanup,
> > > jklog_cleanup);
> > > + apr_pool_cleanup_register(p, main_log, jklog_cleanup,
> > > jklog_cleanup);
> > > + }
> > > return 0;
> > > }
> > >
> > > The point is: when I added full virtual server support for all configs I
> > > changed the cleanup function to NULL the virtual server logger. It
> > > NULLed main_log before. But the only reason it should NULL a logger was
> > > the check for NULL in
> > >
> > > if (main_log == NULL)
> > > main_log = conf->log;
> > >
> > > So if main_log is set once, it never gets reset. This is bad, if the
> > > pool from which it got acquired is dead. So we actually need to register
> > > the log cleanup only for main_log, because otherwise main_log will
> > > always reference an outdated logger. conf->log will be overwritten
> > > during each init, no need to reset those.
> > >
> > > At least that's my theory for it. Could you test this patch?
> > >
> > > Regards,
> > >
> > > Rainer
> > >
> > >
> > >
> > > Henri Gomez schrieb:
> > > > I made it works by adding main_log = NULL in jklog_cleanup
> > > >
> > > > static apr_status_t jklog_cleanup(void *d)
> > > > {
> > > > /* set the main_log to NULL */
> > > > d = NULL;
> > > > main_log = NULL;
> > > > return APR_SUCCESS;
> > > > }
> > > >
> > > > Don't forget that jk is initialized twice and on i5/OS in the same
> > > > thread, so may be the static var should be reset.
> > > >
> > > > What do you think of the patch ?
> > > >
> > > >
> > > > 2007/4/24, Rainer Jung <ra...@kippdata.de>:
> > > >> main_log is a static in mod_jk.c, which is initialized as NULL.
> > > >>
> > > >> It gets set inside open_jklog() which gets called once for every virtual
> > > >> server by jk_post_config() during server initialization.
> > > >>
> > > >> The first virtual server inherits its logger conf->log from its
> > > >> configuration to main_log. It also registers a cleanup handler which
> > > >> will NULL its conf->log, but that should not change main_log.
> > > >>
> > > >> main_log should never get reset.
> > > >>
> > > >> To find the problem, it would be best to first reduce the apache config
> > > >> to not use any virtual servers.
> > > >>
> > > >> You can log the value of main_log for debug purposes anywhere in
> > > >> mod_jk.c, because its a global static.
> > > >>
> > > >> Regards,
> > > >>
> > > >> Rainer
> > > >>
> > > >> Henri Gomez schrieb:
> > > >> > I'm looking for the exception in jk_log. It happen in ws_write right
> > > >> > now and I wonder what's the life cycle of main_log.
> > > >> >
> > > >> > On i5/OS, the init / post are done on the same thread (not the same on
> > > >> > Unixes).
> > > >> >
> > > >> > How is reset the main_log ?
> > > >> >
> > > >>
> > > >> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > > >> For additional commands, e-mail: dev-help@tomcat.apache.org
> > > >>
> > > >>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > > > For additional commands, e-mail: dev-help@tomcat.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: dev-help@tomcat.apache.org
> > >
> > >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Henri Gomez <he...@gmail.com>.
It works ! great.
Could I commit ?
Also find a way to fix for i5/OS the HTTP 500 problem
2007/4/24, Henri Gomez <he...@gmail.com>:
> You remove completly the apr_pool_cleanup_register(p, conf->log, jklog_cleanup,
> jklog_cleanup) ?
>
> 2007/4/24, Rainer Jung <ra...@kippdata.de>:
> > Great. I think I now understand the problem.
> >
> > Could you try this one relativ to your last change:
> >
> > Index: mod_jk.c
> > ===================================================================
> > --- mod_jk.c (revision 531926)
> > +++ mod_jk.c (working copy)
> > @@ -2539,11 +2539,7 @@
> >
> > static apr_status_t jklog_cleanup(void *d)
> > {
> > - /* set the main_log to NULL */
> > -#ifdef AS400
> > - main_log = null;
> > -#endif
> > -
> > + /* set the log to NULL */
> > d = NULL;
> > return APR_SUCCESS;
> > }
> > @@ -2616,9 +2612,10 @@
> > jkl->logger_private = flp;
> > flp->jklogfp = conf->jklogfp;
> > conf->log = jkl;
> > - if (main_log == NULL)
> > + if (main_log == NULL) {
> > main_log = conf->log;
> > - apr_pool_cleanup_register(p, conf->log, jklog_cleanup,
> > jklog_cleanup);
> > + apr_pool_cleanup_register(p, main_log, jklog_cleanup,
> > jklog_cleanup);
> > + }
> > return 0;
> > }
> >
> > The point is: when I added full virtual server support for all configs I
> > changed the cleanup function to NULL the virtual server logger. It
> > NULLed main_log before. But the only reason it should NULL a logger was
> > the check for NULL in
> >
> > if (main_log == NULL)
> > main_log = conf->log;
> >
> > So if main_log is set once, it never gets reset. This is bad, if the
> > pool from which it got acquired is dead. So we actually need to register
> > the log cleanup only for main_log, because otherwise main_log will
> > always reference an outdated logger. conf->log will be overwritten
> > during each init, no need to reset those.
> >
> > At least that's my theory for it. Could you test this patch?
> >
> > Regards,
> >
> > Rainer
> >
> >
> >
> > Henri Gomez schrieb:
> > > I made it works by adding main_log = NULL in jklog_cleanup
> > >
> > > static apr_status_t jklog_cleanup(void *d)
> > > {
> > > /* set the main_log to NULL */
> > > d = NULL;
> > > main_log = NULL;
> > > return APR_SUCCESS;
> > > }
> > >
> > > Don't forget that jk is initialized twice and on i5/OS in the same
> > > thread, so may be the static var should be reset.
> > >
> > > What do you think of the patch ?
> > >
> > >
> > > 2007/4/24, Rainer Jung <ra...@kippdata.de>:
> > >> main_log is a static in mod_jk.c, which is initialized as NULL.
> > >>
> > >> It gets set inside open_jklog() which gets called once for every virtual
> > >> server by jk_post_config() during server initialization.
> > >>
> > >> The first virtual server inherits its logger conf->log from its
> > >> configuration to main_log. It also registers a cleanup handler which
> > >> will NULL its conf->log, but that should not change main_log.
> > >>
> > >> main_log should never get reset.
> > >>
> > >> To find the problem, it would be best to first reduce the apache config
> > >> to not use any virtual servers.
> > >>
> > >> You can log the value of main_log for debug purposes anywhere in
> > >> mod_jk.c, because its a global static.
> > >>
> > >> Regards,
> > >>
> > >> Rainer
> > >>
> > >> Henri Gomez schrieb:
> > >> > I'm looking for the exception in jk_log. It happen in ws_write right
> > >> > now and I wonder what's the life cycle of main_log.
> > >> >
> > >> > On i5/OS, the init / post are done on the same thread (not the same on
> > >> > Unixes).
> > >> >
> > >> > How is reset the main_log ?
> > >> >
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > >> For additional commands, e-mail: dev-help@tomcat.apache.org
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: dev-help@tomcat.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Henri Gomez <he...@gmail.com>.
You remove completly the apr_pool_cleanup_register(p, conf->log, jklog_cleanup,
jklog_cleanup) ?
2007/4/24, Rainer Jung <ra...@kippdata.de>:
> Great. I think I now understand the problem.
>
> Could you try this one relativ to your last change:
>
> Index: mod_jk.c
> ===================================================================
> --- mod_jk.c (revision 531926)
> +++ mod_jk.c (working copy)
> @@ -2539,11 +2539,7 @@
>
> static apr_status_t jklog_cleanup(void *d)
> {
> - /* set the main_log to NULL */
> -#ifdef AS400
> - main_log = null;
> -#endif
> -
> + /* set the log to NULL */
> d = NULL;
> return APR_SUCCESS;
> }
> @@ -2616,9 +2612,10 @@
> jkl->logger_private = flp;
> flp->jklogfp = conf->jklogfp;
> conf->log = jkl;
> - if (main_log == NULL)
> + if (main_log == NULL) {
> main_log = conf->log;
> - apr_pool_cleanup_register(p, conf->log, jklog_cleanup,
> jklog_cleanup);
> + apr_pool_cleanup_register(p, main_log, jklog_cleanup,
> jklog_cleanup);
> + }
> return 0;
> }
>
> The point is: when I added full virtual server support for all configs I
> changed the cleanup function to NULL the virtual server logger. It
> NULLed main_log before. But the only reason it should NULL a logger was
> the check for NULL in
>
> if (main_log == NULL)
> main_log = conf->log;
>
> So if main_log is set once, it never gets reset. This is bad, if the
> pool from which it got acquired is dead. So we actually need to register
> the log cleanup only for main_log, because otherwise main_log will
> always reference an outdated logger. conf->log will be overwritten
> during each init, no need to reset those.
>
> At least that's my theory for it. Could you test this patch?
>
> Regards,
>
> Rainer
>
>
>
> Henri Gomez schrieb:
> > I made it works by adding main_log = NULL in jklog_cleanup
> >
> > static apr_status_t jklog_cleanup(void *d)
> > {
> > /* set the main_log to NULL */
> > d = NULL;
> > main_log = NULL;
> > return APR_SUCCESS;
> > }
> >
> > Don't forget that jk is initialized twice and on i5/OS in the same
> > thread, so may be the static var should be reset.
> >
> > What do you think of the patch ?
> >
> >
> > 2007/4/24, Rainer Jung <ra...@kippdata.de>:
> >> main_log is a static in mod_jk.c, which is initialized as NULL.
> >>
> >> It gets set inside open_jklog() which gets called once for every virtual
> >> server by jk_post_config() during server initialization.
> >>
> >> The first virtual server inherits its logger conf->log from its
> >> configuration to main_log. It also registers a cleanup handler which
> >> will NULL its conf->log, but that should not change main_log.
> >>
> >> main_log should never get reset.
> >>
> >> To find the problem, it would be best to first reduce the apache config
> >> to not use any virtual servers.
> >>
> >> You can log the value of main_log for debug purposes anywhere in
> >> mod_jk.c, because its a global static.
> >>
> >> Regards,
> >>
> >> Rainer
> >>
> >> Henri Gomez schrieb:
> >> > I'm looking for the exception in jk_log. It happen in ws_write right
> >> > now and I wonder what's the life cycle of main_log.
> >> >
> >> > On i5/OS, the init / post are done on the same thread (not the same on
> >> > Unixes).
> >> >
> >> > How is reset the main_log ?
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Rainer Jung <ra...@kippdata.de>.
Great. I think I now understand the problem.
Could you try this one relativ to your last change:
Index: mod_jk.c
===================================================================
--- mod_jk.c (revision 531926)
+++ mod_jk.c (working copy)
@@ -2539,11 +2539,7 @@
static apr_status_t jklog_cleanup(void *d)
{
- /* set the main_log to NULL */
-#ifdef AS400
- main_log = null;
-#endif
-
+ /* set the log to NULL */
d = NULL;
return APR_SUCCESS;
}
@@ -2616,9 +2612,10 @@
jkl->logger_private = flp;
flp->jklogfp = conf->jklogfp;
conf->log = jkl;
- if (main_log == NULL)
+ if (main_log == NULL) {
main_log = conf->log;
- apr_pool_cleanup_register(p, conf->log, jklog_cleanup,
jklog_cleanup);
+ apr_pool_cleanup_register(p, main_log, jklog_cleanup,
jklog_cleanup);
+ }
return 0;
}
The point is: when I added full virtual server support for all configs I
changed the cleanup function to NULL the virtual server logger. It
NULLed main_log before. But the only reason it should NULL a logger was
the check for NULL in
if (main_log == NULL)
main_log = conf->log;
So if main_log is set once, it never gets reset. This is bad, if the
pool from which it got acquired is dead. So we actually need to register
the log cleanup only for main_log, because otherwise main_log will
always reference an outdated logger. conf->log will be overwritten
during each init, no need to reset those.
At least that's my theory for it. Could you test this patch?
Regards,
Rainer
Henri Gomez schrieb:
> I made it works by adding main_log = NULL in jklog_cleanup
>
> static apr_status_t jklog_cleanup(void *d)
> {
> /* set the main_log to NULL */
> d = NULL;
> main_log = NULL;
> return APR_SUCCESS;
> }
>
> Don't forget that jk is initialized twice and on i5/OS in the same
> thread, so may be the static var should be reset.
>
> What do you think of the patch ?
>
>
> 2007/4/24, Rainer Jung <ra...@kippdata.de>:
>> main_log is a static in mod_jk.c, which is initialized as NULL.
>>
>> It gets set inside open_jklog() which gets called once for every virtual
>> server by jk_post_config() during server initialization.
>>
>> The first virtual server inherits its logger conf->log from its
>> configuration to main_log. It also registers a cleanup handler which
>> will NULL its conf->log, but that should not change main_log.
>>
>> main_log should never get reset.
>>
>> To find the problem, it would be best to first reduce the apache config
>> to not use any virtual servers.
>>
>> You can log the value of main_log for debug purposes anywhere in
>> mod_jk.c, because its a global static.
>>
>> Regards,
>>
>> Rainer
>>
>> Henri Gomez schrieb:
>> > I'm looking for the exception in jk_log. It happen in ws_write right
>> > now and I wonder what's the life cycle of main_log.
>> >
>> > On i5/OS, the init / post are done on the same thread (not the same on
>> > Unixes).
>> >
>> > How is reset the main_log ?
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Henri Gomez <he...@gmail.com>.
I made it works by adding main_log = NULL in jklog_cleanup
static apr_status_t jklog_cleanup(void *d)
{
/* set the main_log to NULL */
d = NULL;
main_log = NULL;
return APR_SUCCESS;
}
Don't forget that jk is initialized twice and on i5/OS in the same
thread, so may be the static var should be reset.
What do you think of the patch ?
2007/4/24, Rainer Jung <ra...@kippdata.de>:
> main_log is a static in mod_jk.c, which is initialized as NULL.
>
> It gets set inside open_jklog() which gets called once for every virtual
> server by jk_post_config() during server initialization.
>
> The first virtual server inherits its logger conf->log from its
> configuration to main_log. It also registers a cleanup handler which
> will NULL its conf->log, but that should not change main_log.
>
> main_log should never get reset.
>
> To find the problem, it would be best to first reduce the apache config
> to not use any virtual servers.
>
> You can log the value of main_log for debug purposes anywhere in
> mod_jk.c, because its a global static.
>
> Regards,
>
> Rainer
>
> Henri Gomez schrieb:
> > I'm looking for the exception in jk_log. It happen in ws_write right
> > now and I wonder what's the life cycle of main_log.
> >
> > On i5/OS, the init / post are done on the same thread (not the same on
> > Unixes).
> >
> > How is reset the main_log ?
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Rainer Jung <ra...@kippdata.de>.
main_log is a static in mod_jk.c, which is initialized as NULL.
It gets set inside open_jklog() which gets called once for every virtual
server by jk_post_config() during server initialization.
The first virtual server inherits its logger conf->log from its
configuration to main_log. It also registers a cleanup handler which
will NULL its conf->log, but that should not change main_log.
main_log should never get reset.
To find the problem, it would be best to first reduce the apache config
to not use any virtual servers.
You can log the value of main_log for debug purposes anywhere in
mod_jk.c, because its a global static.
Regards,
Rainer
Henri Gomez schrieb:
> I'm looking for the exception in jk_log. It happen in ws_write right
> now and I wonder what's the life cycle of main_log.
>
> On i5/OS, the init / post are done on the same thread (not the same on
> Unixes).
>
> How is reset the main_log ?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Henri Gomez <he...@gmail.com>.
I'm looking for the exception in jk_log. It happen in ws_write right
now and I wonder what's the life cycle of main_log.
On i5/OS, the init / post are done on the same thread (not the same on Unixes).
How is reset the main_log ?
2007/4/24, Henri Gomez <he...@gmail.com>:
> checked that assbackwards is 0 on i5/OS
>
> 2007/4/24, Rainer Jung <ra...@kippdata.de>:
> > Hi Henri,
> >
> > > - Another annoying problem is the HTTP 500 error in SOAP mode. It
> > > seems the sent_bodyct flag is not set in Apache 2 side, which is
> > > strange since I got reply from Tomcat (HTTP 500 in HEADER and
> > > SOAPFault in BODY).
> > >
> > > Since the sent_bodyct should be set inside Apache 2.x, it may be
> > > something specific to i5/OS IBM implementation of Apache 2.0. I'm
> > > still looking for informations from Rochester Labs.
> > >
> > > Do you know where the sent_bodyct is set in Apache 2.x, it will be
> > > usefull to diagnose problem with IBMers ?
> >
> > include/httpd.h
> >
> > /** A structure that represents the current request */
> > struct request_rec {
> > ...
> > /** byte count in stream is for body */
> > apr_off_t sent_bodyct;
> > ...
> >
> > Initialization in server/protocol.c:
> >
> > Value set to 0 in request_rec *ap_read_request(conn_rec *conn)
> >
> > During request processing the value gets set to 1 in
> > modules/http/http_protocol.c.
> >
> > AP_CORE_DECLARE_NONSTD(apr_status_t) ap_http_header_filter(ap_filter_t
> > *f, apr_bucket_brigade *b)
> > ...
> > if (r->assbackwards) {
> > r->sent_bodyct = 1;
> > ap_remove_output_filter(f);
> > return ap_pass_brigade(f->next, b);
> > }
> > ...
> > (further equest processing)
> > ...
> > if (r->header_only) {
> > apr_brigade_destroy(b);
> > ctx->headers_sent = 1;
> > return OK;
> > }
> >
> > r->sent_bodyct = 1; /* Whatever follows is real body stuff... */
> > ...
> >
> > assbackwards is documented as:
> >
> > /** HTTP/0.9, "simple" request (e.g. GET /foo\n w/no headers) */
> > int assbackwards;
> >
> > Regards,
> >
> > Rainer
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Henri Gomez <he...@gmail.com>.
checked that assbackwards is 0 on i5/OS
2007/4/24, Rainer Jung <ra...@kippdata.de>:
> Hi Henri,
>
> > - Another annoying problem is the HTTP 500 error in SOAP mode. It
> > seems the sent_bodyct flag is not set in Apache 2 side, which is
> > strange since I got reply from Tomcat (HTTP 500 in HEADER and
> > SOAPFault in BODY).
> >
> > Since the sent_bodyct should be set inside Apache 2.x, it may be
> > something specific to i5/OS IBM implementation of Apache 2.0. I'm
> > still looking for informations from Rochester Labs.
> >
> > Do you know where the sent_bodyct is set in Apache 2.x, it will be
> > usefull to diagnose problem with IBMers ?
>
> include/httpd.h
>
> /** A structure that represents the current request */
> struct request_rec {
> ...
> /** byte count in stream is for body */
> apr_off_t sent_bodyct;
> ...
>
> Initialization in server/protocol.c:
>
> Value set to 0 in request_rec *ap_read_request(conn_rec *conn)
>
> During request processing the value gets set to 1 in
> modules/http/http_protocol.c.
>
> AP_CORE_DECLARE_NONSTD(apr_status_t) ap_http_header_filter(ap_filter_t
> *f, apr_bucket_brigade *b)
> ...
> if (r->assbackwards) {
> r->sent_bodyct = 1;
> ap_remove_output_filter(f);
> return ap_pass_brigade(f->next, b);
> }
> ...
> (further equest processing)
> ...
> if (r->header_only) {
> apr_brigade_destroy(b);
> ctx->headers_sent = 1;
> return OK;
> }
>
> r->sent_bodyct = 1; /* Whatever follows is real body stuff... */
> ...
>
> assbackwards is documented as:
>
> /** HTTP/0.9, "simple" request (e.g. GET /foo\n w/no headers) */
> int assbackwards;
>
> Regards,
>
> Rainer
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Jean-Frederic <jf...@gmail.com>.
On Wed, 2007-05-16 at 10:17 +0200, Henri Gomez wrote:
> 2007/4/24, Henri Gomez <he...@gmail.com>:
> > 2007/4/24, Rainer Jung <ra...@kippdata.de>:
> > > The flag is about the response body. We send the response back via a
> > > webserver specific method. It's ws_write() ind mod_jk.c.
> > >
> > > ws_write() calls e.g. ap_rwrite() which should in my opinion set
> > > sent_bodyct. I'm careful about that, because I don't fully understand
> > > the filter architecture involved.
The ap_http_header_filter sets the sent_bodyct.
If I get it right ap_http_header_filter is called by ap_pass_brigade
that is called by ap_rwrite in ws_write()
In 1.3 it is set in ap_send_http_header() that we call in mod_jk.c
(ws_start_response).
> > >
> > > But ws_write() also contains iSeries specific code. Maybe some of those
> > > methods fail. You can log p->r->sent_bodyct inside ws_write and also add
> > > some debug log to find out, if it stopps prematurely. Especially
> > > ap_change_response_body_xlate() does not seem to be part of standard
> > > apache code. No idea, if that has an interaction bug with filters.
> >
> > No more, we're is AS400_UTF8 mode so the ws_write in i5/OS and Linux
> > is the same...
> >
>
> Did you heard about problem with sent_bodyct problem on others platform ?
>
> BTW, what about the BZ 41563
> (http://marc.info/?l=tomcat-dev&m=117089564901077&w=2) and proposed
> patch ?
+1 to apply it.
Cheers
Jean-Frederic
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Henri Gomez <he...@gmail.com>.
2007/4/24, Henri Gomez <he...@gmail.com>:
> 2007/4/24, Rainer Jung <ra...@kippdata.de>:
> > The flag is about the response body. We send the response back via a
> > webserver specific method. It's ws_write() ind mod_jk.c.
> >
> > ws_write() calls e.g. ap_rwrite() which should in my opinion set
> > sent_bodyct. I'm careful about that, because I don't fully understand
> > the filter architecture involved.
> >
> > But ws_write() also contains iSeries specific code. Maybe some of those
> > methods fail. You can log p->r->sent_bodyct inside ws_write and also add
> > some debug log to find out, if it stopps prematurely. Especially
> > ap_change_response_body_xlate() does not seem to be part of standard
> > apache code. No idea, if that has an interaction bug with filters.
>
> No more, we're is AS400_UTF8 mode so the ws_write in i5/OS and Linux
> is the same...
>
Did you heard about problem with sent_bodyct problem on others platform ?
BTW, what about the BZ 41563
(http://marc.info/?l=tomcat-dev&m=117089564901077&w=2) and proposed
patch ?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Henri Gomez <he...@gmail.com>.
2007/4/24, Rainer Jung <ra...@kippdata.de>:
> The flag is about the response body. We send the response back via a
> webserver specific method. It's ws_write() ind mod_jk.c.
>
> ws_write() calls e.g. ap_rwrite() which should in my opinion set
> sent_bodyct. I'm careful about that, because I don't fully understand
> the filter architecture involved.
>
> But ws_write() also contains iSeries specific code. Maybe some of those
> methods fail. You can log p->r->sent_bodyct inside ws_write and also add
> some debug log to find out, if it stopps prematurely. Especially
> ap_change_response_body_xlate() does not seem to be part of standard
> apache code. No idea, if that has an interaction bug with filters.
No more, we're is AS400_UTF8 mode so the ws_write in i5/OS and Linux
is the same...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Rainer Jung <ra...@kippdata.de>.
The flag is about the response body. We send the response back via a
webserver specific method. It's ws_write() ind mod_jk.c.
ws_write() calls e.g. ap_rwrite() which should in my opinion set
sent_bodyct. I'm careful about that, because I don't fully understand
the filter architecture involved.
But ws_write() also contains iSeries specific code. Maybe some of those
methods fail. You can log p->r->sent_bodyct inside ws_write and also add
some debug log to find out, if it stopps prematurely. Especially
ap_change_response_body_xlate() does not seem to be part of standard
apache code. No idea, if that has an interaction bug with filters.
Regards,
Rainer
Henri Gomez schrieb:
> On my Linux test box, sent_body is allways set.
>
> Did there is some default configuration in Apache 2.0 to flush header
> automatically ?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Henri Gomez <he...@gmail.com>.
On my Linux test box, sent_body is allways set.
Did there is some default configuration in Apache 2.0 to flush header
automatically ?
2007/4/24, Henri Gomez <he...@gmail.com>:
> Ok, just add some log in mod_jk.c and see :
>
> if (rc > 0) {^M
> /* If tomcat returned no body and the status is not OK,^M
> let apache handle the error code */^M
> jk_log(xconf->log, JK_LOG_INFO, "sent_bodyct=%d status=%d
> header_only=%d" , r->sent_bodyct, r->status, r->header_only);
> if (!r->sent_bodyct && r->status >= HTTP_BAD_REQUEST) {^M
>
>
> SOAP reply (HTTP 200)
>
> [Tue Apr 24 11:57:48 2007] [5833:0273] [debug] jk_ajp_common.c (1043):
> received from ajp13 pos=0 len=4 max=8192
> [Tue Apr 24 11:57:48 2007] [5833:0273] [debug] jk_ajp_common.c (1043):
> 0000 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -
> ................
> [Tue Apr 24 11:57:48 2007] [5833:0273] [debug] jk_ajp_common.c (1043):
> received from ajp13 pos=0 len=4 max=8192
> [Tue Apr 24 11:57:48 2007] [5833:0273] [debug] jk_ajp_common.c (1043):
> 0000 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -
> ................
> [Tue Apr 24 11:57:48 2007] [5833:0273] [debug] jk_ajp_common.c (1043):
> received from ajp13 pos=0 len=2 max=8192
> [Tue Apr 24 11:57:48 2007] [5833:0273] [debug] jk_ajp_common.c (1043):
> 0000 05 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -
> ................
> [Tue Apr 24 11:57:48 2007] [5833:0273] [debug] jk_ajp_common.c (1506):
> AJP13 protocol: Reuse is OK
> [Tue Apr 24 11:57:48 2007] [5833:0273] [debug] jk_ajp_common.c (2286):
> recycling connection pool slot=0 for worker soa-850
> [Tue Apr 24 11:57:48 2007] [5833:0273] [info] mod_jk.c (2224):
> sent_bodyct=0 status=200 header_only=0
> [Tue Apr 24 11:57:48 2007] [5833:0273] [debug] mod_jk.c (2233):
> Service finished with status=200 for worker=soa-850
>
> SOAP FAULT (HTTP 500)
>
> [Tue Apr 24 11:55:27 2007] [5833:0024] [debug] jk_ajp_common.c (1043):
> received from ajp13 pos=0 len=4 max=8192
> [Tue Apr 24 11:55:27 2007] [5833:0024] [debug] jk_ajp_common.c (1043):
> 0000 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -
> ................
> [Tue Apr 24 11:55:27 2007] [5833:0024] [debug] jk_ajp_common.c (1043):
> received from ajp13 pos=0 len=4 max=8192
> [Tue Apr 24 11:55:27 2007] [5833:0024] [debug] jk_ajp_common.c (1043):
> 0000 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -
> ................
> [Tue Apr 24 11:55:27 2007] [5833:0024] [debug] jk_ajp_common.c (1043):
> received from ajp13 pos=0 len=2 max=8192
> [Tue Apr 24 11:55:27 2007] [5833:0024] [debug] jk_ajp_common.c (1043):
> 0000 05 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -
> ................
> [Tue Apr 24 11:55:27 2007] [5833:0024] [debug] jk_ajp_common.c (1506):
> AJP13 protocol: Reuse is OK
> [Tue Apr 24 11:55:27 2007] [5833:0024] [debug] jk_ajp_common.c (2286):
> recycling connection pool slot=0 for worker soa-850
> [Tue Apr 24 11:55:27 2007] [5833:0024] [info] mod_jk.c (2224):
> sent_bodyct=0 status=500 header_only=0
> [Tue Apr 24 11:55:27 2007] [5833:0024] [info] mod_jk.c (2226): No
> body with status=500 for worker=soa-850
>
> It's strange but the sent_body is never set, so when HTTP 500 is
> encountered, we think we got no BODY from Tomcat and fall back to
> Apache 500 error.
>
> Any idea ?
>
> 2007/4/24, Rainer Jung <ra...@kippdata.de>:
> > Hi Henri,
> >
> > > - Another annoying problem is the HTTP 500 error in SOAP mode. It
> > > seems the sent_bodyct flag is not set in Apache 2 side, which is
> > > strange since I got reply from Tomcat (HTTP 500 in HEADER and
> > > SOAPFault in BODY).
> > >
> > > Since the sent_bodyct should be set inside Apache 2.x, it may be
> > > something specific to i5/OS IBM implementation of Apache 2.0. I'm
> > > still looking for informations from Rochester Labs.
> > >
> > > Do you know where the sent_bodyct is set in Apache 2.x, it will be
> > > usefull to diagnose problem with IBMers ?
> >
> > include/httpd.h
> >
> > /** A structure that represents the current request */
> > struct request_rec {
> > ...
> > /** byte count in stream is for body */
> > apr_off_t sent_bodyct;
> > ...
> >
> > Initialization in server/protocol.c:
> >
> > Value set to 0 in request_rec *ap_read_request(conn_rec *conn)
> >
> > During request processing the value gets set to 1 in
> > modules/http/http_protocol.c.
> >
> > AP_CORE_DECLARE_NONSTD(apr_status_t) ap_http_header_filter(ap_filter_t
> > *f, apr_bucket_brigade *b)
> > ...
> > if (r->assbackwards) {
> > r->sent_bodyct = 1;
> > ap_remove_output_filter(f);
> > return ap_pass_brigade(f->next, b);
> > }
> > ...
> > (further equest processing)
> > ...
> > if (r->header_only) {
> > apr_brigade_destroy(b);
> > ctx->headers_sent = 1;
> > return OK;
> > }
> >
> > r->sent_bodyct = 1; /* Whatever follows is real body stuff... */
> > ...
> >
> > assbackwards is documented as:
> >
> > /** HTTP/0.9, "simple" request (e.g. GET /foo\n w/no headers) */
> > int assbackwards;
> >
> > Regards,
> >
> > Rainer
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Henri Gomez <he...@gmail.com>.
Ok, just add some log in mod_jk.c and see :
if (rc > 0) {^M
/* If tomcat returned no body and the status is not OK,^M
let apache handle the error code */^M
jk_log(xconf->log, JK_LOG_INFO, "sent_bodyct=%d status=%d
header_only=%d" , r->sent_bodyct, r->status, r->header_only);
if (!r->sent_bodyct && r->status >= HTTP_BAD_REQUEST) {^M
SOAP reply (HTTP 200)
[Tue Apr 24 11:57:48 2007] [5833:0273] [debug] jk_ajp_common.c (1043):
received from ajp13 pos=0 len=4 max=8192
[Tue Apr 24 11:57:48 2007] [5833:0273] [debug] jk_ajp_common.c (1043):
0000 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -
................
[Tue Apr 24 11:57:48 2007] [5833:0273] [debug] jk_ajp_common.c (1043):
received from ajp13 pos=0 len=4 max=8192
[Tue Apr 24 11:57:48 2007] [5833:0273] [debug] jk_ajp_common.c (1043):
0000 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -
................
[Tue Apr 24 11:57:48 2007] [5833:0273] [debug] jk_ajp_common.c (1043):
received from ajp13 pos=0 len=2 max=8192
[Tue Apr 24 11:57:48 2007] [5833:0273] [debug] jk_ajp_common.c (1043):
0000 05 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -
................
[Tue Apr 24 11:57:48 2007] [5833:0273] [debug] jk_ajp_common.c (1506):
AJP13 protocol: Reuse is OK
[Tue Apr 24 11:57:48 2007] [5833:0273] [debug] jk_ajp_common.c (2286):
recycling connection pool slot=0 for worker soa-850
[Tue Apr 24 11:57:48 2007] [5833:0273] [info] mod_jk.c (2224):
sent_bodyct=0 status=200 header_only=0
[Tue Apr 24 11:57:48 2007] [5833:0273] [debug] mod_jk.c (2233):
Service finished with status=200 for worker=soa-850
SOAP FAULT (HTTP 500)
[Tue Apr 24 11:55:27 2007] [5833:0024] [debug] jk_ajp_common.c (1043):
received from ajp13 pos=0 len=4 max=8192
[Tue Apr 24 11:55:27 2007] [5833:0024] [debug] jk_ajp_common.c (1043):
0000 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -
................
[Tue Apr 24 11:55:27 2007] [5833:0024] [debug] jk_ajp_common.c (1043):
received from ajp13 pos=0 len=4 max=8192
[Tue Apr 24 11:55:27 2007] [5833:0024] [debug] jk_ajp_common.c (1043):
0000 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -
................
[Tue Apr 24 11:55:27 2007] [5833:0024] [debug] jk_ajp_common.c (1043):
received from ajp13 pos=0 len=2 max=8192
[Tue Apr 24 11:55:27 2007] [5833:0024] [debug] jk_ajp_common.c (1043):
0000 05 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -
................
[Tue Apr 24 11:55:27 2007] [5833:0024] [debug] jk_ajp_common.c (1506):
AJP13 protocol: Reuse is OK
[Tue Apr 24 11:55:27 2007] [5833:0024] [debug] jk_ajp_common.c (2286):
recycling connection pool slot=0 for worker soa-850
[Tue Apr 24 11:55:27 2007] [5833:0024] [info] mod_jk.c (2224):
sent_bodyct=0 status=500 header_only=0
[Tue Apr 24 11:55:27 2007] [5833:0024] [info] mod_jk.c (2226): No
body with status=500 for worker=soa-850
It's strange but the sent_body is never set, so when HTTP 500 is
encountered, we think we got no BODY from Tomcat and fall back to
Apache 500 error.
Any idea ?
2007/4/24, Rainer Jung <ra...@kippdata.de>:
> Hi Henri,
>
> > - Another annoying problem is the HTTP 500 error in SOAP mode. It
> > seems the sent_bodyct flag is not set in Apache 2 side, which is
> > strange since I got reply from Tomcat (HTTP 500 in HEADER and
> > SOAPFault in BODY).
> >
> > Since the sent_bodyct should be set inside Apache 2.x, it may be
> > something specific to i5/OS IBM implementation of Apache 2.0. I'm
> > still looking for informations from Rochester Labs.
> >
> > Do you know where the sent_bodyct is set in Apache 2.x, it will be
> > usefull to diagnose problem with IBMers ?
>
> include/httpd.h
>
> /** A structure that represents the current request */
> struct request_rec {
> ...
> /** byte count in stream is for body */
> apr_off_t sent_bodyct;
> ...
>
> Initialization in server/protocol.c:
>
> Value set to 0 in request_rec *ap_read_request(conn_rec *conn)
>
> During request processing the value gets set to 1 in
> modules/http/http_protocol.c.
>
> AP_CORE_DECLARE_NONSTD(apr_status_t) ap_http_header_filter(ap_filter_t
> *f, apr_bucket_brigade *b)
> ...
> if (r->assbackwards) {
> r->sent_bodyct = 1;
> ap_remove_output_filter(f);
> return ap_pass_brigade(f->next, b);
> }
> ...
> (further equest processing)
> ...
> if (r->header_only) {
> apr_brigade_destroy(b);
> ctx->headers_sent = 1;
> return OK;
> }
>
> r->sent_bodyct = 1; /* Whatever follows is real body stuff... */
> ...
>
> assbackwards is documented as:
>
> /** HTTP/0.9, "simple" request (e.g. GET /foo\n w/no headers) */
> int assbackwards;
>
> Regards,
>
> Rainer
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Rainer Jung <ra...@kippdata.de>.
Hi Henri,
> - Another annoying problem is the HTTP 500 error in SOAP mode. It
> seems the sent_bodyct flag is not set in Apache 2 side, which is
> strange since I got reply from Tomcat (HTTP 500 in HEADER and
> SOAPFault in BODY).
>
> Since the sent_bodyct should be set inside Apache 2.x, it may be
> something specific to i5/OS IBM implementation of Apache 2.0. I'm
> still looking for informations from Rochester Labs.
>
> Do you know where the sent_bodyct is set in Apache 2.x, it will be
> usefull to diagnose problem with IBMers ?
include/httpd.h
/** A structure that represents the current request */
struct request_rec {
...
/** byte count in stream is for body */
apr_off_t sent_bodyct;
...
Initialization in server/protocol.c:
Value set to 0 in request_rec *ap_read_request(conn_rec *conn)
During request processing the value gets set to 1 in
modules/http/http_protocol.c.
AP_CORE_DECLARE_NONSTD(apr_status_t) ap_http_header_filter(ap_filter_t
*f, apr_bucket_brigade *b)
...
if (r->assbackwards) {
r->sent_bodyct = 1;
ap_remove_output_filter(f);
return ap_pass_brigade(f->next, b);
}
...
(further equest processing)
...
if (r->header_only) {
apr_brigade_destroy(b);
ctx->headers_sent = 1;
return OK;
}
r->sent_bodyct = 1; /* Whatever follows is real body stuff... */
...
assbackwards is documented as:
/** HTTP/0.9, "simple" request (e.g. GET /foo\n w/no headers) */
int assbackwards;
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Henri Gomez <he...@gmail.com>.
Hi to all,
I commited on the changes to make jk works on i5/OS V5R4 (didn't test
anymore on previous release since we upgraded to V5R4).
I still see 2 problems :
- Call to jk_logger still generate thread exceptions, so I temporary
fix that by using printf instead of l->log in jk_log() (jk_util.c).
/*
* MCH errors encountered on i5/OS (V5R3/V5R4) when using jk_logger,
use the JOBLOB QPRINT instead for now
*/
#ifdef AS400
printf("%s\n", buf);
#else
l->log(l, level, buf);
#endif
- Another annoying problem is the HTTP 500 error in SOAP mode. It
seems the sent_bodyct flag is not set in Apache 2 side, which is
strange since I got reply from Tomcat (HTTP 500 in HEADER and
SOAPFault in BODY).
if (rc > 0) {
/* If tomcat returned no body and the status is not OK,
let apache handle the error code */
if (!r->sent_bodyct && r->status >= HTTP_BAD_REQUEST) {
jk_log(xconf->log, JK_LOG_INFO, "No body with status=%d"
" for worker=%s",
r->status, worker_name);
JK_TRACE_EXIT(xconf->log);
return r->status;
}
....
[Tue Apr 24 10:04:33 2007] [5620:0259] [debug] jk_ajp_common.c (603):
status = 500
[Tue Apr 24 10:04:33 2007] [5620:0259] [debug] jk_ajp_common.c (610):
Number of headers is = 1
[Tue Apr 24 10:04:33 2007] [5620:0259] [debug] jk_ajp_common.c (666):
Header[0] [Content-Type] = [text/xml;charset=utf-8]
[Tue Apr 24 10:04:33 2007] [5620:0259] [debug] jk_ajp_common.c (1043):
received from ajp13 pos=0 len=456 max=8192
....
[Tue Apr 24 10:04:33 2007] [5620:0259] [debug] mod_jk.c (446): written
452 out of 452
[Tue Apr 24 10:04:33 2007] [5620:0259] [debug] jk_ajp_common.c (1043):
received from ajp13 pos=0 len=4 max=8192
....
[Tue Apr 24 10:04:33 2007] [5620:0259] [debug] jk_ajp_common.c (1043):
0000 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -
[Tue Apr 24 10:04:33 2007] [5620:0259] [debug] jk_ajp_common.c (1043):
received from ajp13 pos=0 len=4 max=8192
[Tue Apr 24 10:04:33 2007] [5620:0259] [debug] jk_ajp_common.c (1043):
0000 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -
[Tue Apr 24 10:04:33 2007] [5620:0259] [debug] jk_ajp_common.c (1043):
received from ajp13 pos=0 len=2 max=8192
[Tue Apr 24 10:04:33 2007] [5620:0259] [debug] jk_ajp_common.c (1043):
0000 05 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -
[Tue Apr 24 10:04:33 2007] [5620:0259] [debug] jk_ajp_common.c (1506):
AJP13 protocol: Reuse is OK
[Tue Apr 24 10:04:33 2007] [5620:0259] [debug] jk_ajp_common.c (2286):
recycling connection pool slot=0 for worker xylos-soa-850
[Tue Apr 24 10:04:33 2007] [5620:0259] [info] mod_jk.c (2225): No
body with status=500 for worker=xylos-soa-850
Since the sent_bodyct should be set inside Apache 2.x, it may be
something specific to i5/OS IBM implementation of Apache 2.0. I'm
still looking for informations from Rochester Labs.
Do you know where the sent_bodyct is set in Apache 2.x, it will be
usefull to diagnose problem with IBMers ?
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Henri Gomez <he...@gmail.com>.
Works on progress, I'll made a jk_stat for AS400_UTF8 only
2007/4/23, Guenter Knauf <fu...@apache.org>:
> Hi Henri,
> suggestion (otherwise we would also have 2 unused vars rc and ptr on all non-AS400 platforms):
>
> int jk_file_exists(const char *f)
> {
> if (f) {
> struct stat st;
> int rc;
> #ifdef AS400
> #define S_IFREG _S_IFREG
> char *ptr;
> /**
> * i5/OS V5R4 expect filename in ASCII for fopen but required them in EBCDIC for stat()
> */
> #ifdef AS400_UTF8
> ptr = (char *)malloc(strlen(f) + 1);
> jk_ascii2ebcdic((char *)f, ptr);
> rc = stat(ptr, &st);
> free(ptr);
> #else /* AS400_UTF8 */
> rc = stat(f, &st);
> #endif /* AS400_UTF8 */
> #else /* AS400 */
> rc = stat(f, &st);
> #endif /* AS400 */
> if ((0 == rc) && (st.st_mode & S_IFREG))
> return JK_TRUE;
> }
>
> return JK_FALSE;
> }
>
>
> Guenter.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Guenter Knauf <fu...@apache.org>.
Hi Henri,
suggestion (otherwise we would also have 2 unused vars rc and ptr on all non-AS400 platforms):
int jk_file_exists(const char *f)
{
if (f) {
struct stat st;
int rc;
#ifdef AS400
#define S_IFREG _S_IFREG
char *ptr;
/**
* i5/OS V5R4 expect filename in ASCII for fopen but required them in EBCDIC for stat()
*/
#ifdef AS400_UTF8
ptr = (char *)malloc(strlen(f) + 1);
jk_ascii2ebcdic((char *)f, ptr);
rc = stat(ptr, &st);
free(ptr);
#else /* AS400_UTF8 */
rc = stat(f, &st);
#endif /* AS400_UTF8 */
#else /* AS400 */
rc = stat(f, &st);
#endif /* AS400 */
if ((0 == rc) && (st.st_mode & S_IFREG))
return JK_TRUE;
}
return JK_FALSE;
}
Guenter.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Guenter Knauf <fu...@apache.org>.
Hi Henri,
> I can adapt some by defines (allready commited) but others require
> more code (to be commited) and of course code less readable...
you may be able to reduce some ifdefs in jk_utils.c with f.e.:
#ifdef AS400
#define S_IFREG _S_IFREG
#endif
> BTW, I will replace call to stat() by calls to jk_file_exists
I believe that doesnt work; if you remove the stat() call then further down the lines:
if (modified)
*modified = statbuf.st_mtime;
cant work since statbuf isnt then populated.
Guenter.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Henri Gomez <he...@gmail.com>.
2007/4/23, Guenter Knauf <fu...@apache.org>:
> Hi,
> > My question will be, could we make APR mandatory, even for Apache 1.3 or
> > IIS ?
> -1 from my side; APR cant be used on NetWare with Apache 1.3 / Netscape due to other lib version APR depends on. This would again break my just fixed things with AP13 mod_jk and the Netscape connectors...
> isnt it possible that we just do some more defines as Jean-Frederic already suggested, f.e. something similar to apr_compat.h, apu_compat.h? Probably into a separate header?
I can adapt some by defines (allready commited) but others require
more code (to be commited) and of course code less readable...
BTW, I will replace call to stat() by calls to jk_file_exists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Guenter Knauf <fu...@apache.org>.
Hi,
> My question will be, could we make APR mandatory, even for Apache 1.3 or
> IIS ?
-1 from my side; APR cant be used on NetWare with Apache 1.3 / Netscape due to other lib version APR depends on. This would again break my just fixed things with AP13 mod_jk and the Netscape connectors...
isnt it possible that we just do some more defines as Jean-Frederic already suggested, f.e. something similar to apr_compat.h, apu_compat.h? Probably into a separate header?
Guenter.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Henri Gomez <he...@gmail.com>.
i5/OS V5R4 show me more and more subtilities :
When designing Apache module, APR/HTTP make use of UTF8.
Some of the i5/OS apis like inet_addr() or stat() need EBCDIC strings,
but others need
ASCII like ... fopen().
So may realize why I'll be happy to see an fully APR based jk
implementation (and I'm ready to work on it).
My question will be, could we make APR mandatory, even for Apache 1.3 or IIS ?
Le 23/04/07, Henri Gomez<he...@gmail.com> a écrit :
> Le 23/04/07, Remy Maucherat<re...@apache.org> a écrit :
> > Henri Gomez wrote:
> > > Bonne idée.
> > >
> > > Maintenant le loup c'est dans l'ouverture de fichier
> > > workers.properties car là aussi fopen bosse sur de ... l'EBCDIC.
> > >
> > > Putain pourquoi on n'utilise pas carrement APR pour tout ce qui est
> > > I/O dans mod_jk ?
> >
> > On se calme, on se calme :)
>
> Oups, sorry :-)
>
> I think it was a private email :)
>
> BTW, using APR for all I/O operation on mod_jk could make code easier
> and much more readable without all the #idef .... #endif
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Henri Gomez <he...@gmail.com>.
Le 23/04/07, Remy Maucherat<re...@apache.org> a écrit :
> Henri Gomez wrote:
> > Bonne idée.
> >
> > Maintenant le loup c'est dans l'ouverture de fichier
> > workers.properties car là aussi fopen bosse sur de ... l'EBCDIC.
> >
> > Putain pourquoi on n'utilise pas carrement APR pour tout ce qui est
> > I/O dans mod_jk ?
>
> On se calme, on se calme :)
Oups, sorry :-)
I think it was a private email :)
BTW, using APR for all I/O operation on mod_jk could make code easier
and much more readable without all the #idef .... #endif
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Remy Maucherat <re...@apache.org>.
Henri Gomez wrote:
> Bonne idée.
>
> Maintenant le loup c'est dans l'ouverture de fichier
> workers.properties car là aussi fopen bosse sur de ... l'EBCDIC.
>
> Putain pourquoi on n'utilise pas carrement APR pour tout ce qui est
> I/O dans mod_jk ?
On se calme, on se calme :)
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Henri Gomez <he...@gmail.com>.
Bonne idée.
Maintenant le loup c'est dans l'ouverture de fichier
workers.properties car là aussi fopen bosse sur de ... l'EBCDIC.
Putain pourquoi on n'utilise pas carrement APR pour tout ce qui est
I/O dans mod_jk ?
2007/4/23, Jean-Frederic <jf...@gmail.com>:
> On Mon, 2007-04-23 at 12:26 +0200, Henri Gomez wrote:
> > Hi to all,
> >
> > I'm still working on i5/OS V5R4 port and I'm facing the following problem.
> >
> > i5/OS is an EBCDIC system, but in V5R4, IBM decided, for modules
> > writer ease, to make all HTTP and APR routines works in UTF.
> >
> > That's fine but all the native runtime functions still works in EBDIC.
> >
> > So function like strcasecmp compare 2 strings in case unsensitive mode
> > but works in EBCDIC charsets and as consequence Content-Type !=
> > Content-type.
> >
> > Could we use instead the apr_strnatcasecmp, for example in mod_jk.c
> > for apache 2 ?
>
> Better use something like:
> #ifdef AS400_UTF8
> #define strcasecmp(a,b) apr_strnatcasecmp(a,b)
> #endif
>
> Cheers
>
> Jean-Frederic
>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: More on i5/OS and some modifications needed
Posted by Jean-Frederic <jf...@gmail.com>.
On Mon, 2007-04-23 at 12:26 +0200, Henri Gomez wrote:
> Hi to all,
>
> I'm still working on i5/OS V5R4 port and I'm facing the following problem.
>
> i5/OS is an EBCDIC system, but in V5R4, IBM decided, for modules
> writer ease, to make all HTTP and APR routines works in UTF.
>
> That's fine but all the native runtime functions still works in EBDIC.
>
> So function like strcasecmp compare 2 strings in case unsensitive mode
> but works in EBCDIC charsets and as consequence Content-Type !=
> Content-type.
>
> Could we use instead the apr_strnatcasecmp, for example in mod_jk.c
> for apache 2 ?
Better use something like:
#ifdef AS400_UTF8
#define strcasecmp(a,b) apr_strnatcasecmp(a,b)
#endif
Cheers
Jean-Frederic
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org