Re: More on i5/OS and some modifications needed
On Wed, 2007-05-16 at 10:17 +0200, Henri Gomez wrote: > 2007/4/24, Henri Gomez <[EMAIL PROTECTED]>: > > 2007/4/24, Rainer Jung <[EMAIL PROTECTED]>: > > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More on i5/OS and some modifications needed
2007/4/24, Henri Gomez <[EMAIL PROTECTED]>: 2007/4/24, Rainer Jung <[EMAIL PROTECTED]>: > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More on i5/OS and some modifications needed
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More on i5/OS and some modifications needed
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More on i5/OS and some modifications needed
Exact. I'll commit a fix asap
2007/4/25, Jean-Frederic <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>:
> > It works ! great.
> >
> > Could I commit ?
> >
> > Also find a way to fix for i5/OS the HTTP 500 problem
> >
> > 2007/4/24, Henri Gomez <[EMAIL PROTECTED]>:
> > > You remove completly the apr_pool_cleanup_register(p, conf->log,
jklog_cleanup,
> > > jklog_cleanup) ?
> > >
> > > 2007/4/24, Rainer Jung <[EMAIL PROTECTED]>:
> > > > 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 <[EMAIL PROTECTED]>:
> > > > >> 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: [EMAIL PROTECTED]
> > > > >
Re: More on i5/OS and some modifications needed
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 <[EMAIL PROTECTED]>:
> > It works ! great.
> >
> > Could I commit ?
> >
> > Also find a way to fix for i5/OS the HTTP 500 problem
> >
> > 2007/4/24, Henri Gomez <[EMAIL PROTECTED]>:
> > > You remove completly the apr_pool_cleanup_register(p, conf->log,
> > > jklog_cleanup,
> > > jklog_cleanup) ?
> > >
> > > 2007/4/24, Rainer Jung <[EMAIL PROTECTED]>:
> > > > 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 <[EMAIL PROTECTED]>:
> > > > >> 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: [EMAIL PROTECTED]
> > > > >> For additional co
Re: More on i5/OS and some modifications needed
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 <[EMAIL PROTECTED]>:
It works ! great.
Could I commit ?
Also find a way to fix for i5/OS the HTTP 500 problem
2007/4/24, Henri Gomez <[EMAIL PROTECTED]>:
> You remove completly the apr_pool_cleanup_register(p, conf->log,
jklog_cleanup,
> jklog_cleanup) ?
>
> 2007/4/24, Rainer Jung <[EMAIL PROTECTED]>:
> > 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 <[EMAIL PROTECTED]>:
> > >> 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: [EMAIL PROTECTED]
> > >> For additional commands, e-mail: [EMAIL PROTECTED]
> > >>
> > >>
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: More on i5/OS and some modifications needed
It works ! great.
Could I commit ?
Also find a way to fix for i5/OS the HTTP 500 problem
2007/4/24, Henri Gomez <[EMAIL PROTECTED]>:
You remove completly the apr_pool_cleanup_register(p, conf->log, jklog_cleanup,
jklog_cleanup) ?
2007/4/24, Rainer Jung <[EMAIL PROTECTED]>:
> 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 <[EMAIL PROTECTED]>:
> >> 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: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: More on i5/OS and some modifications needed
You remove completly the apr_pool_cleanup_register(p, conf->log, jklog_cleanup,
jklog_cleanup) ?
2007/4/24, Rainer Jung <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>:
>> 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: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: More on i5/OS and some modifications needed
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 <[EMAIL PROTECTED]>:
>> 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: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: More on i5/OS and some modifications needed
2007/4/24, Rainer Jung <[EMAIL PROTECTED]>: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More on i5/OS and some modifications needed
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 <[EMAIL PROTECTED]>:
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: More on i5/OS and some modifications needed
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More on i5/OS and some modifications needed
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More on i5/OS and some modifications needed
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 <[EMAIL PROTECTED]>:
checked that assbackwards is 0 on i5/OS
2007/4/24, Rainer Jung <[EMAIL PROTECTED]>:
> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: More on i5/OS and some modifications needed
checked that assbackwards is 0 on i5/OS
2007/4/24, Rainer Jung <[EMAIL PROTECTED]>:
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: More on i5/OS and some modifications needed
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 <[EMAIL PROTECTED]>:
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):
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):
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):
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):
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):
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):
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 <[EMAIL PROTECTED]>:
> 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: [EMAIL PROTECTED]
>
Re: More on i5/OS and some modifications needed
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):
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):
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):
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):
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):
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):
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 <[EMAIL PROTECTED]>:
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: More on i5/OS and some modifications needed
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: More on i5/OS and some modifications needed
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):
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):
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):
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: More on i5/OS and some modifications needed
Works on progress, I'll made a jk_stat for AS400_UTF8 only
2007/4/23, Guenter Knauf <[EMAIL PROTECTED]>:
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: More on i5/OS and some modifications needed
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: More on i5/OS and some modifications needed
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More on i5/OS and some modifications needed
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More on i5/OS and some modifications needed
2007/4/23, Guenter Knauf <[EMAIL PROTECTED]>: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More on i5/OS and some modifications needed
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<[EMAIL PROTECTED]> a écrit : Le 23/04/07, Remy Maucherat<[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More on i5/OS and some modifications needed
Le 23/04/07, Remy Maucherat<[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More on i5/OS and some modifications needed
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More on i5/OS and some modifications needed
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 <[EMAIL PROTECTED]>: 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More on i5/OS and some modifications needed
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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
