|
Home > Archive > IIS Server > August 2005 > IIS logs only Redirect DLL
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
IIS logs only Redirect DLL
|
|
| Björn Andersen 2005-08-29, 5:59 pm |
| Hello,
we got Tomcats behind our IIS6-Cluster. They are connected via the
jk2-isapi-connector.
When users request a mapped file, like all *.jsp 's, only the name of the
redirection dll (isapi-filter) is logged.
So it's something like:
2005-08-29 12:26:47 GET /jakarta/isapi_redirector2.dll - - 195.93.60.138
HTTP/1.0 Mozilla/4.0+
(compatible;+MSIE+6.0;+AOL+9.0;+Windows+NT+5.1;+SV1;+.NET+CLR+1.1.4322) -
200 27958
instead of
2005-08-29 12:26:47 GET /myapp/start/index.jsp - - 195.93.60.138 HTTP/1.0
Mozilla/4.0+
(compatible;+MSIE+6.0;+AOL+9.0;+Windows+NT+5.1;+SV1;+.NET+CLR+1.1.4322) -
200 27958
what would be the original Request.
And we need the original request in out logs to build acceptable webstats.
We are not sure why IIS is showing this behaviour and replaces the Request,
or even if maybe it is the filter itself that replaces it. But we need to
get back to the original requests in the W3C-Extended logs.
How can we solve this problem?
Bjoern
P.s.: It is not practicable to configure the Tomcats to do W3C logging have
the logs joined distinct before doing the statistics. This would be an
administration nightmare.
| |
| Dennis Black 2005-08-29, 5:59 pm |
| BJoern,
You cannot get the URL JSP file or Servlet path from IIS Logs. From
IIS's perspective the URL is handled by isapi_redirector.dll and it does
not know what happens next.
One solution is to write a Servlet Filter in Tomcat that does the actual
logging. Refer to http://java.sun.com/developer/JDCTe...001/tt0626.html
I see that you are using JK2. How is that working for you. We had JK2
DLL in our IIS but every once in a while IIS would generate a 404 error.
This was so sporadic that we never were able to reproduce it when we
wanted but was enough to create a headache. We finally switched back to
JK1 and it has been running fine since then.
Björn Andersen wrote:
> Hello,
>
> we got Tomcats behind our IIS6-Cluster. They are connected via the
> jk2-isapi-connector.
> When users request a mapped file, like all *.jsp 's, only the name of the
> redirection dll (isapi-filter) is logged.
> So it's something like:
>
> 2005-08-29 12:26:47 GET /jakarta/isapi_redirector2.dll - - 195.93.60.138
> HTTP/1.0 Mozilla/4.0+
> (compatible;+MSIE+6.0;+AOL+9.0;+Windows+NT+5.1;+SV1;+.NET+CLR+1.1.4322) -
> 200 27958
>
> instead of
>
> 2005-08-29 12:26:47 GET /myapp/start/index.jsp - - 195.93.60.138 HTTP/1.0
> Mozilla/4.0+
> (compatible;+MSIE+6.0;+AOL+9.0;+Windows+NT+5.1;+SV1;+.NET+CLR+1.1.4322) -
> 200 27958
>
> what would be the original Request.
>
> And we need the original request in out logs to build acceptable webstats.
> We are not sure why IIS is showing this behaviour and replaces the Request,
> or even if maybe it is the filter itself that replaces it. But we need to
> get back to the original requests in the W3C-Extended logs.
> How can we solve this problem?
>
> Bjoern
>
> P.s.: It is not practicable to configure the Tomcats to do W3C logging have
> the logs joined distinct before doing the statistics. This would be an
> administration nightmare.
>
>
| |
| Björn Andersen 2005-08-29, 5:59 pm |
| Hi Dennis,
Is there realy no way? Hard to believe. I understand that the isapi somehow
rewrites the URL to the DLL, but there are still events processed in the
iis - or no log would be written at all. Neither could that IIS pass the
auth-information to the dll/tomcat (which it does) at this point - Auth is a
much later event. Why can't the isapi write the real request back as soon as
it's got controll over the request?
Another aproach would be to have a custom isapi-logger priorized above the
jk2 which does W3C logging (would lack of executiontime, but thats not too
important). Not the best, but maybe a workaround?
If you got no suggestions on the IIS side, how is the W3C logging done in
the TCs? we got a pool of 19 application contexts, so we would need a
logging in the server, not the applications itself. But prefereably one log
per application. You know of any code/configsamples?
yes, we have the jk2 in use in a small farm, 2 frontend IIS (wlbs) with 6
backend tomcats (jk2-loadbalancer). We have not jet heared from our
customers about these 404 errors you describe. For us, the jk2 works like a
charm and it's sad to see they stopped dev on it. jk(1) din't work half as
good for us. If you are using such a similar constellation to ours, how do
you do your logs / webstats then?
Bjoern
"Dennis Black" <db@dbnospam.com> schrieb im Newsbeitrag
news:OZEzl7JrFHA.2924@TK2MSFTNGP10.phx.gbl...[vbcol=seagreen]
> BJoern,
>
> You cannot get the URL JSP file or Servlet path from IIS Logs. From IIS's
> perspective the URL is handled by isapi_redirector.dll and it does not
> know what happens next.
>
> One solution is to write a Servlet Filter in Tomcat that does the actual
> logging. Refer to
> http://java.sun.com/developer/JDCTe...001/tt0626.html
>
> I see that you are using JK2. How is that working for you. We had JK2 DLL
> in our IIS but every once in a while IIS would generate a 404 error. This
> was so sporadic that we never were able to reproduce it when we wanted but
> was enough to create a headache. We finally switched back to JK1 and it
> has been running fine since then.
>
>
>
>
> Björn Andersen wrote:
| |
| Dennis Black 2005-08-29, 5:59 pm |
| Björn Andersen wrote:
> Hi Dennis,
>
> Is there realy no way? Hard to believe. I understand that the isapi somehow
> rewrites the URL to the DLL, but there are still events processed in the
> iis - or no log would be written at all. Neither could that IIS pass the
> auth-information to the dll/tomcat (which it does) at this point - Auth is a
> much later event. Why can't the isapi write the real request back as soon as
> it's got controll over the request?
>
Well, if you find a way, please post is here.
Which Auth are you talking about - Http Simple Auth? I have never done
this with with IIS. I don't even know if I can make IIS ask for
Authentication for a Tomcat resource like 'MyProtectedFile.jsp'
> Another aproach would be to have a custom isapi-logger priorized above the
> jk2 which does W3C logging (would lack of executiontime, but thats not too
> important). Not the best, but maybe a workaround?
Yes, this should work however, you may not be able to write the IIS log.
You will have to write it to a different file.
>
> If you got no suggestions on the IIS side, how is the W3C logging done in
> the TCs? we got a pool of 19 application contexts, so we would need a
> logging in the server, not the applications itself. But prefereably one log
> per application. You know of any code/configsamples?
>
Well, in our case we have written a Servlet Filter that logs into a
database using Log4J. The sink for Log4J is not IIS log, which does not
contain anything anyway.
| |
| Björn Andersen 2005-08-29, 5:59 pm |
| Hi,
> Which Auth are you talking about - Http Simple Auth? I have never done
> this with with IIS. I don't even know if I can make IIS ask for
> Authentication for a Tomcat resource like 'MyProtectedFile.jsp'
We do both, simple auth and windows integrated. Then we pass the
authenticated user via the jk2 to to TCs. works fine.
Of cause we can't pin security to a file, because the files are not actually
there.
So Authentification works well (Who is the user), but authorization (is he
allowed to do this) not.
> Yes, this should work however, you may not be able to write the IIS log.
> You will have to write it to a different file.
yes, of cause. These would then replace the IIS logs.
> Well, in our case we have written a Servlet Filter that logs into a
> database using Log4J. The sink for Log4J is not IIS log, which does not
> contain anything anyway.
well, in our case, it can't be iis log, because the iis is on physically
different machines, and a cluster anyway.
But we would have to merge the logs because for performance, we serve static
content (pics and html) from the iis and only dynamic content is mapped to
the TCs.
can you supply code examples for the filter? shouldn't be too hard to give
Log4J a file target instead of a DB.
thanks
Bjoern
| |
| Dennis Black 2005-08-29, 5:59 pm |
| Here is the code for the Filter and modifications to web.xml file.
---------- MODIFICATIONS TO WEB.XML FILE in TOMCAT --------
<filter>
<filter-name>WebLogger</filter-name>
<filter-class>com.ita.webapp.util.WebLogger</filter-class>
</filter>
<filter-mapping>
<filter-name>WebLogger</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
-----------------------------------------------------------
---------- SERVLET FILTER CODE ----------------------------
public class WebLogger implements Filter{
public WebLogger() {
}
private void logRequest(Connection dbConn, ServletRequest request,
ServletResponse response) throws SQLException{
ExWebLog logger = new ExWebLog(dbConn);
HttpServletRequest httpRequest = (HttpServletRequest)request;
logger.setM_ipAddress(request.getRemoteAddr());
logger.setM_referer(httpRequest.getHeader("referer"));
logger.setM_hostName(httpRequest.getHeader("host"));
logger.setM_requestTime(new Timestamp(System.currentTimeMillis()));
logger.setM_sessionId(httpRequest.getSession().getId());
String params = httpRequest.getQueryString();
if(params == null){
params = "";
}else{
params = "?" + params;
}
logger.setM_urlPath(httpRequest.getRequestURI() + params);
logger.insert();
}
/**
* init
*
* @param filterConfig FilterConfig
*/
public void init(FilterConfig filterConfig){
}
/**
* doFilter
*
* @param servletRequest ServletRequest
* @param servletResponse ServletResponse
* @param filterChain FilterChain
*/
public void doFilter(ServletRequest request, ServletResponse
response, FilterChain filterChain){
Connection dbConn;
try{
dbConn = ConnectionPool.getInstance().getConnection();
}
catch(SQLException ex){
return;
}
try{
logRequest(dbConn, request, response);
}catch(Exception ex){
LoggingFW.log(LoggingFW.ERROR, this, ex.getMessage(), ex);
}finally{
ConnectionPool.getInstance().returnConnection(dbConn);
}
try{
filterChain.doFilter(request, response);
}
catch(ServletException ex1){
LoggingFW.log(LoggingFW.ERROR, this, ex1.getMessage(), ex1);
}
catch(IOException ex1){
LoggingFW.log(LoggingFW.ERROR, this, ex1.getMessage(), ex1);
}
}
/**
* destroy
*/
public void destroy(){
}
}
| |
| David Wang [Msft] 2005-08-30, 2:55 am |
| This behavior completely depends on the implementation of the redirector.
My understanding of how the various Tomcat ISAPI redirectors work is that
they have two pieces -- an ISAPI Filter component and an ISAPI Extension
component. Based on your configuration, whenever the ISAPI Filter sees an
URL and/or resource extension that maps to what should be processed by
Tomcat, it "steals that request" from IIS in some fashion.
Some redirectors steal the request be rewriting the URL to point at the
ISAPI Extension, which actually performs the stealing of the request,
proxies the request to Tomcat, and generates the response. Others use
SF_NOTIFY_READ_RAW_DATA to buffer the incoming response and generate the
proxied request.
Depending on how the request is stolen, the ISAPI Filter is also responsible
for fixing back up the log file entry. Rewriting the URL to ISAPI Extension
is a preferable approach which plays nicely on IIS6 without requiring IIS5
Compatibility Mode, but since it steals the request by changing the URL IIS
ultimately processes, the filter is obviously responsible to fix up the IIS
log file entry since from IIS perspective, the ISAPI DLL actually handled
the request.
Thus, I consider it a bug in the redirector ISAPI Filter for failing to do
this -- you should feel free to file a bug against the appropriate party
responsible for supporting your ISAPI redirector.
--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Dennis Black" <db@dbnospam.com> wrote in message
news:OZEzl7JrFHA.2924@TK2MSFTNGP10.phx.gbl...
BJoern,
You cannot get the URL JSP file or Servlet path from IIS Logs. From
IIS's perspective the URL is handled by isapi_redirector.dll and it does
not know what happens next.
One solution is to write a Servlet Filter in Tomcat that does the actual
logging. Refer to http://java.sun.com/developer/JDCTe...001/tt0626.html
I see that you are using JK2. How is that working for you. We had JK2
DLL in our IIS but every once in a while IIS would generate a 404 error.
This was so sporadic that we never were able to reproduce it when we
wanted but was enough to create a headache. We finally switched back to
JK1 and it has been running fine since then.
Björn Andersen wrote:
> Hello,
>
> we got Tomcats behind our IIS6-Cluster. They are connected via the
> jk2-isapi-connector.
> When users request a mapped file, like all *.jsp 's, only the name of the
> redirection dll (isapi-filter) is logged.
> So it's something like:
>
> 2005-08-29 12:26:47 GET /jakarta/isapi_redirector2.dll - - 195.93.60.138
> HTTP/1.0 Mozilla/4.0+
>
(compatible;+MSIE+6.0;+AOL+9.0;+Windows+NT+5.1;+SV1;+.NET+CLR+1.1.4322) -
> 200 27958
>
> instead of
>
> 2005-08-29 12:26:47 GET /myapp/start/index.jsp - - 195.93.60.138
HTTP/1.0
> Mozilla/4.0+
>
(compatible;+MSIE+6.0;+AOL+9.0;+Windows+NT+5.1;+SV1;+.NET+CLR+1.1.4322) -
> 200 27958
>
> what would be the original Request.
>
> And we need the original request in out logs to build acceptable webstats.
> We are not sure why IIS is showing this behaviour and replaces the
Request,
> or even if maybe it is the filter itself that replaces it. But we need to
> get back to the original requests in the W3C-Extended logs.
> How can we solve this problem?
>
> Bjoern
>
> P.s.: It is not practicable to configure the Tomcats to do W3C logging
have
> the logs joined distinct before doing the statistics. This would be an
> administration nightmare.
>
>
| |
| Dennis Black 2005-08-30, 8:13 am |
| David,
Thanks for the insight. Unfortunately, Tomcat is open-source, which
means you can't report a bug. You have to download the code and fix it
yourself :-)
David Wang [Msft] wrote:
> This behavior completely depends on the implementation of the redirector.
>
> My understanding of how the various Tomcat ISAPI redirectors work is that
> they have two pieces -- an ISAPI Filter component and an ISAPI Extension
> component. Based on your configuration, whenever the ISAPI Filter sees an
> URL and/or resource extension that maps to what should be processed by
> Tomcat, it "steals that request" from IIS in some fashion.
>
> Some redirectors steal the request be rewriting the URL to point at the
> ISAPI Extension, which actually performs the stealing of the request,
> proxies the request to Tomcat, and generates the response. Others use
> SF_NOTIFY_READ_RAW_DATA to buffer the incoming response and generate the
> proxied request.
>
> Depending on how the request is stolen, the ISAPI Filter is also responsible
> for fixing back up the log file entry. Rewriting the URL to ISAPI Extension
> is a preferable approach which plays nicely on IIS6 without requiring IIS5
> Compatibility Mode, but since it steals the request by changing the URL IIS
> ultimately processes, the filter is obviously responsible to fix up the IIS
> log file entry since from IIS perspective, the ISAPI DLL actually handled
> the request.
>
> Thus, I consider it a bug in the redirector ISAPI Filter for failing to do
> this -- you should feel free to file a bug against the appropriate party
> responsible for supporting your ISAPI redirector.
>
| |
| David Wang [Msft] 2005-08-31, 2:52 am |
| Well, that's rather unfortunate... guess the itch will have to be annoying
enough for someone to scratch it... and don't know how long that would take.
:-)
--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Dennis Black" <db@dbnospam.com> wrote in message
news:O4EUKSUrFHA.3216@TK2MSFTNGP12.phx.gbl...
David,
Thanks for the insight. Unfortunately, Tomcat is open-source, which
means you can't report a bug. You have to download the code and fix it
yourself :-)
David Wang [Msft] wrote:
> This behavior completely depends on the implementation of the redirector.
>
> My understanding of how the various Tomcat ISAPI redirectors work is that
> they have two pieces -- an ISAPI Filter component and an ISAPI Extension
> component. Based on your configuration, whenever the ISAPI Filter sees an
> URL and/or resource extension that maps to what should be processed by
> Tomcat, it "steals that request" from IIS in some fashion.
>
> Some redirectors steal the request be rewriting the URL to point at the
> ISAPI Extension, which actually performs the stealing of the request,
> proxies the request to Tomcat, and generates the response. Others use
> SF_NOTIFY_READ_RAW_DATA to buffer the incoming response and generate the
> proxied request.
>
> Depending on how the request is stolen, the ISAPI Filter is also
responsible
> for fixing back up the log file entry. Rewriting the URL to ISAPI
Extension
> is a preferable approach which plays nicely on IIS6 without requiring IIS5
> Compatibility Mode, but since it steals the request by changing the URL
IIS
> ultimately processes, the filter is obviously responsible to fix up the
IIS
> log file entry since from IIS perspective, the ISAPI DLL actually handled
> the request.
>
> Thus, I consider it a bug in the redirector ISAPI Filter for failing to do
> this -- you should feel free to file a bug against the appropriate party
> responsible for supporting your ISAPI redirector.
>
|
|
|
|
|