Re: getting the request that created the session
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Leon,
On 4/29/13 12:55 PM, Leon Rosenberg wrote:
However, in my case, I am developing a library that is used by
others in their projects (http://moskito.anotheria.net). It comes
already with 8 filters and this is a lot.
If you want the effect of the filters without the stack trace(s), you
could implement your filters somewhat differently (but still implement
the Filter interface, so they can be used separately if desired) and
then wrap them into a single compound-filter... something like this:
public class SourceIPSessionFilter
implements Filter, RequestSetUp
{
public void doFilter(ServletRequest request,
ServletResponse response,
FilterChain chain)
{
setUpRequest(request);
chain.doFilter(request, response);
}
public void setUpRequest(ServletRequest request)
{
HttpSession session =
((HttpServletRequest)request).getSession(false);
if(null != session)
session.setAttribute(SOURCE_IP, request.getRemoteAddr());
}
}
public class MetaFilter
implements Filter
{
private ListSetUpFilter subFilters;
public void doFilter(ServletRequest request,
ServletResponse response,
FilterChain chain)
{
for(SetUpFilter f : subFilters)
f.setUpRequest(request);
chain.doFilter(request, response);
}
}
Obviously, this is a small glimpse into what you can do -- maybe you
want set up and tear down filters, and maybe those that do both,
etc. But the point is that you call a method that /returns/ before the
filter chain is invoked. Instead of a classic interceptor pattern,
it's more like a phased-interceptor where the first phase runs
separately from the second phase.
Implementing the individual filters as formal Filters as well as your
other customized interface allows your users to use them in either
way: with the MetaFilter to reduce stack trace clutter or individually
so they can .. I dunno.. have more control or maybe they like long
stack traces.
One more thought: stack-trace length is really irrelevant. Honestly, I
think you are coding-around something that is totally unnecessary.
Stack traces for web applications are notoriously long -- sometimes
dozens and into the hundreds of calls (especially using Weblogic in my
experience). I wouldn't kill yourself over trying to reduce your
users' stack traces from 50 nested method calls to 42... nobody is
going to notice.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJRf9FUAAoJEBzwKT+lPKRYrkYP/3bBl19qVqgrfUTBAcsYxPR0
fZr+TLjL1qahymcstMyx0PMKpwV1syq2zJNHhAu/5vH0y5W+cu9IZIqiXdY48pSm
PEizqzQ37Mbnf+HbE57HU2rDwT1ZrgM80oLIWU22OGKxWf0XNuDsfpsZ/ksbm7gt
P5XIk/qEamrszJsNGF5qys4jaGaVV4btIi0+QCKD7CMRn8z+jGFZZOiScrQ0bdJZ
Ngnv6ljBx0Dqt6PlkLzJBteC8/FBaTaY/LighSQLXt1A7pKZz/WHhiucozmJ6ZQN
ae6klVr6AY0EQ/tRdGsZbbmlRIRuwlVhYASUbQ2bMaqeh9OtQIwpQAlUuqCR1jKj
s/9703NNUL7xicQ4RmU5JNF8iRJNmvu5h9GkKHNByGbi2y9JqbhVGXcp6i07zt9J
qqWCY0Km+3rzinRwZ38eEKjHI+Idl1WdqUMuPBxjXEqsMUFa+GFo0tS8Obvsg4Nl
H5qFVb2J0XyLlVbBMd+fbS/mncOMcnpDGU1lZjxWeBPL0yrXRpz+P5b45rJio5zi
VXMtUO0OYthjekmadA8QSTEapGbxvgxXHO2W7TfrfJizDeeORMxL/rgGkHlOTzuG
UUzLs/ek++VBzjOyTk6KXFqUMOSBbwRbIlX7k7hmP/uVyo2aef3uHNBjwI/Tkt3Z
iHTcuysdAyHbNlkf6cY5
=nXLy
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: getting the request that created the session
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Leon, On 4/27/13 5:08 PM, Leon Rosenberg wrote: is there any possibility to get the first request from a session (or any request from a session) from the HttpSessionListener. Background, I want to count sessions by top level domains. I'm doing it now in a combination of filter and listener. Filter for new sessions, putting a mark for already counted sessions, and listener for destroyed session. However, I would like to get rid of the Filter, if its possible somehow. For that, I need to get user's ip adress somehow. Back to the original issue: tracking sessions. How often do you need to search these sessions for where they came from? Perhaps it's enough to just mark each session with the first IP address you knew about. I mean, how often does someone change IP addresses during their session (under normal circumstances... yes, proxies can play games, but it's probably not going to matter for your uses, here). Once you've marked each session, you could use JMX to enumerate the sessions and then search for whatever you want. That might be a better pattern for lots of different session-manipulation strategies, anyway. As for this particular requirement (TLDs for session-creation), that's a fairly narrow requirement that most people aren't going to have... so they aren't going to enable that Filter. If they don't enable it, it doesn't appear in the stack trace. Are you suggesting that you'd enable this filter by default? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRf9NGAAoJEBzwKT+lPKRYky4QAJo3Lnw95VUQdaNHWZe+9lKM 8xvsPJ2mwi9QOML+IFGYG9cxpKVF5MT2W632V6IVlght5LGX98+mKmXTsT7Dzr0k gVBKf8Fa4QGlhsEY3AXlTzIxpuFOAWj/iNT15osBTSV6g6aaUXB4QOmKfsLhJL4B 1IC5o5Q0KR5pHIL/g7zWDCZLph+HrarW5xhVwFyBqWkAusjOz9lqlzsFdd6J6zf5 bBWCwD6OQ7JpCsOEyvJ/7i9NXF2gq3a+V9o2exfCWsh7A+ESzYKJLCU3swZRu15x NbNLDr3TBRmNkEXSIcoBH2Jl5mv1rpp69KfZDUjZQQZHXESIl+wNbpaOj4BqdSxp QGPI4UYJ7E1to1GSqLhXF3OE0TGcrCsctVTAy1eGGbEeO/aik4PC3zmjCSPx42k+ xNz09uO+GUyyY5jC3qmNgBz+9qfdYmC2CHruEJwQVrZRPYWyNKjxo6ceA76xC16I LCGTQrA3888UfmS2L0cZ7KFlbkwPMI0I1lQtK72OOeLSJ+mrMaGW8d45rrbOaYR5 2UC//e18IdYZCVbw4RYsybaiNZ24U6rpkfPMA012b1CKHSlpcsDMdEfag/LxM2tk W4UaDYbbd9rf5Sy+r8a1iyYBYBcMZ27vTdsgPPdenoYefFd7ODwNvaUAEnMgU/DE DSu2GTToTojiQvG7grAv =eHuL -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: getting the request that created the session
Leo Donahue - RDSA IT wrote: ___ From: Leon Rosenberg [rosenberg.l...@gmail.com] Subject: Re: getting the request that created the session would ServletRequestListener being notified prior to any Filter execution? According to the docs, yes. A ServletRequest is defined as coming into scope of a web application when it is about to enter the first servlet or filter of the web application, and as going out of scope as it exits the last servlet or the first filter in the chain. http://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequestListener.html Leon, I apologise for insisting, but your initial post said : Background, I want to count sessions by top level domains... It was probably politically a bad idea to start by saying that I agreed with Martin. ;-) But if the above is really your final purpose, and the final purpose is more important than the way in which you get to it, would it not be simpler and more efficient to do this by processing the server's access log, rather than going through all you're going through right now ? Tomcat's AccessLog Valve is indeed specific to Tomcat. But webserver access logs exist on all webservers, and they tend to have the same general format, and contain the same general information (which you can generally also choose yourself). And the programs to read and process them already exist and are widely used. And they do provide an analysis that shows unique users and/or sessions, based on the client's IP (with some filtering already possible and tunable, such as avoiding to count your own admin accesses e.g.). And they will resolve the IP's to domains and provide a break-down by domain etc. Have you looked at one such outputs already ? (If not, I can send you a link to an example, privately) I understand that it is less interesting to do it this way than through Request Listeners etc., but if the end result is what really matters.. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: getting the request that created the session
Hello Andre, On Mon, Apr 29, 2013 at 10:13 AM, André Warnier a...@ice-sa.com wrote: Leon, I apologise for insisting, but your initial post said : Background, I want to count sessions by top level domains... Yes, but @Runtime. Means that I want to know how many sessions from each tld are active _now_. Parsing http log continuously and instantly would be an overkill in my opinion. And I don't see a way to see a session expiry in access log ;-) kind regards Leon
Re: getting the request that created the session
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Leon, On 4/29/13 9:05 AM, Leon Rosenberg wrote: Hello Andre, On Mon, Apr 29, 2013 at 10:13 AM, André Warnier a...@ice-sa.com wrote: Leon, I apologise for insisting, but your initial post said : Background, I want to count sessions by top level domains... Yes, but @Runtime. Means that I want to know how many sessions from each tld are active _now_. Parsing http log continuously and instantly would be an overkill in my opinion. And I don't see a way to see a session expiry in access log ;-) So your initial implementation was a Filter that marked each HttpSession with the origin IP address (so you could get the TLD of the user) and then a Listener to keep track of the sessions? What's wrong with that? Output for http://localhost:8080/moskitodemo/mui/mskShowAllProducers: Request 1 created /moskitodemo/mui/mskShowAllProducers Session created 4B842C774B30EE7886CC7243758C7D38 Request 2 created /moskitodemo/mui/mskCSS Session? true Session 4B842C774B30EE7886CC7243758C7D38 new? true Request 3 created /moskitodemo/img/moskito_webui_logo.gif Session? true Session 4B842C774B30EE7886CC7243758C7D38 new? true Request 4 created /moskitodemo/js/wz_tooltip.js Session? true Session 4B842C774B30EE7886CC7243758C7D38 new? true Request 5 created /moskitodemo/js/jquery-1.4.min.js Session? true Session 4B842C774B30EE7886CC7243758C7D38 new? true Request 6 created /moskitodemo/js/function.js Session? true Session 4B842C774B30EE7886CC7243758C7D38 new? true Request 6 destroyed /moskitodemo/js/function.js Request 5 destroyed /moskitodemo/js/jquery-1.4.min.js Request 4 destroyed /moskitodemo/js/wz_tooltip.js Request 3 destroyed /moskitodemo/img/moskito_webui_logo.gif That does appear a little odd to me. Can you show an HTTP protocol trace of that interaction? I'd be interested to see what request was what and exactly what it held (and whether they were keepalives, etc.). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRfnpjAAoJEBzwKT+lPKRYp1AP/15ijJOAxMkT8ZvVLm3r8jb8 w30OVaIOerFINsE3DL74mngd8pcNR/d2SQoYkMLM3oT42Z/p/Qufy9sLfuti9vkR RAYq9Q0PUmUGTGilWL3eraEqPfXUo1ZVQrC3W9MyvzGraq1sIaJqqWb8fm/N3z9d n0LHenBcjmt8OfySFWSQ8uTfSjdE+KhO0Nqca0sMIUQsGjbrklVwgkyJ8F+auLaY CwS4gSR7I6i785ITNu2XHnGeQLQRonYPTQHiXueEniBKbvCQp4In4antwpPVihrO 2oTUHP2eORe+WvRrUzHDkuZRFhXIHKI5NWuN7HtLsy0xLDgZVJRBys78GI0ulCrG M1KYEpkQFXgHFCZdV3foRkW9XNcCBKdX4ExjZcjoE1pLL2yk5sAePrWeYNS9Bfv0 JKLwdI8J+ofnmJc2ZJazYmA+Ig7PAG74sa02j3izEuRV8B4saUc7mJvUkXusc/qC +qxwQY779ucf77LCY5OIvN/KZU1NOsrDrIrUYyFgjK5m8r7PIvRg8l77z1Bh74na n70/3dTNWmYC1w5WW1WLEUyXJXcrPeQsijWbfnoY8sBvVvLbxOvb/w5dU7WiwxdD 3wxOYNc4TQoaAVsoMS9xs1V1+llxVZXDW/cJeBlgotCNoZNYk8MAZhsuHw1PkyqF FgADHu45Qxy/bKZbEN7S =HgoD -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: getting the request that created the session
Leon Rosenberg wrote: Hello Andre, On Mon, Apr 29, 2013 at 10:13 AM, André Warnier a...@ice-sa.com wrote: Leon, I apologise for insisting, but your initial post said : Background, I want to count sessions by top level domains... Yes, but @Runtime. Means that I want to know how many sessions from each tld are active _now_. Ok then, right. But you didn't really specify that in your initial requirements. Parsing http log continuously and instantly would be an overkill in my opinion. Agreed. And I don't see a way to see a session expiry in access log ;-) Ok, I give up. I was just making sure that you did get the correct meaning of my initial suggestion. ..although, when I think about it again : - under Unix/Linux, there is a command tail -f filename, which continuously watches for any lines added to a file and displays them. It doesn't seem to be very intensive in terms of resources used. - and on the other hand, you probably have a session expiration timeout. So you could in theory say that you note the start of a session, and then update this each time there is a new access to that same session. And then periodically, you go through your table and for each session which you haven't seen since some time = the session timeout, you consider it expired. At which time of course I don't know if this is any simpler than the solution which you are exploring right now. ;-) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: getting the request that created the session
On Mon, Apr 29, 2013 at 3:49 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Leon, So your initial implementation was a Filter that marked each HttpSession with the origin IP address (so you could get the TLD of the user) and then a Listener to keep track of the sessions? What's wrong with that? It seemed to complicated. I now could strip it down to 1 file, that is both HttpSession and ServletRequest- Listener: http://svn.anotheria.net/opensource/moskito/trunk/moskito-web/java/net/anotheria/moskito/web/session/SessionByTldListener.java The drawback is, I can count only from second request, because the session is created later. And I don't want to create sessions on all requests. I'm thinking about moving (duplicating) the call in requestDestroyed. Output for http://localhost:8080/moskitodemo/mui/mskShowAllProducers: Request 1 created /moskitodemo/mui/mskShowAllProducers Session created 4B842C774B30EE7886CC7243758C7D38 Request 2 created /moskitodemo/mui/mskCSS Session? true Session 4B842C774B30EE7886CC7243758C7D38 new? true Request 3 created /moskitodemo/img/moskito_webui_logo.gif Session? true Session 4B842C774B30EE7886CC7243758C7D38 new? true Request 4 created /moskitodemo/js/wz_tooltip.js Session? true Session 4B842C774B30EE7886CC7243758C7D38 new? true Request 5 created /moskitodemo/js/jquery-1.4.min.js Session? true Session 4B842C774B30EE7886CC7243758C7D38 new? true Request 6 created /moskitodemo/js/function.js Session? true Session 4B842C774B30EE7886CC7243758C7D38 new? true Request 6 destroyed /moskitodemo/js/function.js Request 5 destroyed /moskitodemo/js/jquery-1.4.min.js Request 4 destroyed /moskitodemo/js/wz_tooltip.js Request 3 destroyed /moskitodemo/img/moskito_webui_logo.gif That does appear a little odd to me. Can you show an HTTP protocol trace of that interaction? I'd be interested to see what request was what and exactly what it held (and whether they were keepalives, etc.). The request that occur simultaneously in chrome(only) are pictures and js, replied with 304: 1. Request URL: http://localhost:8080/moskitodemo/js/wz_tooltip.js 2. Request Method: GET 3. Status Code: 304 Not Modified 4. Request Headersview source 1. Accept: */* 2. Accept-Encoding: gzip,deflate,sdch 3. Accept-Language: en-US,en;q=0.8 4. Cache-Control: max-age=0 5. Connection: keep-alive 6. Cookie: JSESSIONID=71474A695869D2494E2135CBCEAF 7. Host: localhost:8080 8. If-Modified-Since: Sat, 27 Apr 2013 21:49:44 GMT 9. If-None-Match: W/35082-1367099384000 10. Referer: http://localhost:8080/moskitodemo/mui/mskShowAllProducers 11. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.65 Safari/537.36 5. Response Headersview source 1. Date: Mon, 29 Apr 2013 14:24:36 GMT 2. ETag: W/35082-1367099384000 3. Server: Apache-Coyote/1.1 Even, the requests are keepalived they look to me as if they were executed parallel. At least from the chrome timeline. But its hard to tell without further investigation. You can check yourself: http://server04.test.anotheria.net:8080/moskitodemo/mui/mskShowAllProducers The TestListener code: http://svn.anotheria.net/opensource/moskito/trunk/moskito-web/java/net/anotheria/moskito/web/session/TestListener.java regards Leon - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRfnpjAAoJEBzwKT+lPKRYp1AP/15ijJOAxMkT8ZvVLm3r8jb8 w30OVaIOerFINsE3DL74mngd8pcNR/d2SQoYkMLM3oT42Z/p/Qufy9sLfuti9vkR RAYq9Q0PUmUGTGilWL3eraEqPfXUo1ZVQrC3W9MyvzGraq1sIaJqqWb8fm/N3z9d n0LHenBcjmt8OfySFWSQ8uTfSjdE+KhO0Nqca0sMIUQsGjbrklVwgkyJ8F+auLaY CwS4gSR7I6i785ITNu2XHnGeQLQRonYPTQHiXueEniBKbvCQp4In4antwpPVihrO 2oTUHP2eORe+WvRrUzHDkuZRFhXIHKI5NWuN7HtLsy0xLDgZVJRBys78GI0ulCrG M1KYEpkQFXgHFCZdV3foRkW9XNcCBKdX4ExjZcjoE1pLL2yk5sAePrWeYNS9Bfv0 JKLwdI8J+ofnmJc2ZJazYmA+Ig7PAG74sa02j3izEuRV8B4saUc7mJvUkXusc/qC +qxwQY779ucf77LCY5OIvN/KZU1NOsrDrIrUYyFgjK5m8r7PIvRg8l77z1Bh74na n70/3dTNWmYC1w5WW1WLEUyXJXcrPeQsijWbfnoY8sBvVvLbxOvb/w5dU7WiwxdD 3wxOYNc4TQoaAVsoMS9xs1V1+llxVZXDW/cJeBlgotCNoZNYk8MAZhsuHw1PkyqF FgADHu45Qxy/bKZbEN7S =HgoD -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: getting the request that created the session
On Mon, Apr 29, 2013 at 9:54 AM, André Warnier a...@ice-sa.com wrote: - under Unix/Linux, there is a command tail -f filename, which continuously watches for any lines added to a file and displays them. It doesn't seem to be very intensive in terms of resources used. - and on the other hand, you probably have a session expiration timeout. So you could in theory say that you note the start of a session, and then update this each time there is a new access to that same session. And then periodically, you go through your table and for each session which you haven't seen since some time = the session timeout, you consider it expired. At which time of course I don't know if this is any simpler than the solution which you are exploring right now. ;-) With all respect, I have to say that looks like a lot of I/O right there and a huge hit in performance and I would assume this would hit memory in a bad way as well, but please correct/enlighten me. Also, I'm following this thread, because I have filter in place for similar reason, keeping track of new sessions created, expiring, etc..., and filter meets my need 100% and don't see why one would want to 'avoid' using a filter. Yes, I was looking at the performance of 'filter' and all that i'm doing in 'filter' on 'every request', but in retrospect, I don't see my filter implementation being much of an hinderance in performance. I have to take another look though and confirm what I'm saying here.
Re: getting the request that created the session
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Leon, On 4/29/13 10:36 AM, Leon Rosenberg wrote: On Mon, Apr 29, 2013 at 3:49 PM, Christopher Schultz ch...@christopherschultz.net wrote: Leon, So your initial implementation was a Filter that marked each HttpSession with the origin IP address (so you could get the TLD of the user) and then a Listener to keep track of the sessions? What's wrong with that? It seemed to complicated. I now could strip it down to 1 file, that is both HttpSession and ServletRequest- Listener: http://svn.anotheria.net/opensource/moskito/trunk/moskito-web/java/net/anotheria/moskito/web/session/SessionByTldListener.java Note that, although this is a single class, you might get two separate objects created by Tomcat: one as the ServletContextListener and one as the HttpSessionListener. How do you attach the listeners to the webapp? Via web.xml or some other way? I don't know what the container does if a listener implements more than one interface... I've never personally cared about such a scenario. The drawback is, I can count only from second request, because the session is created later. And I don't want to create sessions on all requests. I'm thinking about moving (duplicating) the call in requestDestroyed. Well, you only care about requests that actually create sessions, so the first request is not really relevant. Or do you mean that the request listener gets the event /before/ the session is created. Hmm. The request that occur simultaneously in chrome(only) are pictures and js, replied with 304: 1. Request URL: http://localhost:8080/moskitodemo/js/wz_tooltip.js 2. Request Method: GET 3. Status Code: 304 Not Modified 4. Request Headersview source 1. Accept: */* 2. Accept-Encoding: gzip,deflate,sdch 3. Accept-Language: en-US,en;q=0.8 4. Cache-Control: max-age=0 5. Connection: keep-alive 6. Cookie: JSESSIONID=71474A695869D2494E2135CBCEAF 7. Host: localhost:8080 8. If-Modified-Since: Sat, 27 Apr 2013 21:49:44 GMT 9. If-None-Match: W/35082-1367099384000 10. Referer: http://localhost:8080/moskitodemo/mui/mskShowAllProducers 11. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.65 Safari/537.36 5. Response Headersview source 1. Date: Mon, 29 Apr 2013 14:24:36 GMT 2. ETag: W/35082-1367099384000 3. Server: Apache-Coyote/1.1 Even, the requests are keepalived they look to me as if they were executed parallel. At least from the chrome timeline. But its hard to tell without further investigation. Yeah, you might have to use a packet-sniffer. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRfomfAAoJEBzwKT+lPKRY89cQAJjLc/xH++tfrNubd9eE+3s3 UKI5prfRYogHXsXzUG/sB1GS2Gpii+6Qtzuen+/9eHp9zfirKWpWFhk2yPQi1MTz oyXQmrXOlYtKwg9iX7FQnkrHfzXbT3Qx5vzrHemf4uwOBhZ9SyutzJsomeHi8Ev0 B7VMZoKz+APyDLQvCyEYKrJpFwtTcD18RaknUKQzgYxFafh98jL6J0icyv3gq9JW MJdl1VSgY0SdkoYitAmDE4Z0qQ9pV6QbS7z4W0VBC9UzxwsG6c+c94ncz3G4WKaa mTNvY7SO/PR/z7FNbfo9AO6pvCZ+5SGnxoQ6C99BdJ/Eo8F78tSVR36H7IC5gNKz rDJN5tLkCIRcWz3KHeqstL4EnB7FyO838bSamKdOExAEa5+zZCREf8T9D4L6dcCb s+bxB+j/fJKSIRXkfiqNozIJ+uwPmr1P/vEqiWEjEVdMJEo2ByTK4Jnx8FJcAi99 sgVLK0fTH+7J85sSArF2zatZO8LxPE860rNR2CbU/NeeXI1MhxlJnGgPd6jIuOtA 8QA17rilYIOWp4icQOqubS2j4g3HmpgMDGnoD59DDJRN5odUPQEDzYYD04XjjeQp VZFSUdThfxSIzp4CBLmHXTiHXMkgflu5MF0aq0oa6T0eU6SNXkoAr7TC4wB/sHNR 2JCE36iSziLeIJHKTgmQ =W8Ia -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: getting the request that created the session
On Mon, Apr 29, 2013 at 10:54 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Even, the requests are keepalived they look to me as if they were executed parallel. At least from the chrome timeline. But its hard to tell without further investigation. Yeah, you might have to use a packet-sniffer. definitely sounds like overkill. how much code you need to write for such a thing, all because one would want to avoid using a filter???
Re: getting the request that created the session
Hello Howard, the sniffer thing has nothing to do with original topic, I was just wandering that some requests were having session marked as new, which actually shouldn't be the case. Or in other word, the naive understanding of session.isNew method is that it should only return true once. But it did to it multiple times. The was strange, and christopher and myself were talking about investigating it further. Back to your question, filter is ok, too many filters are making stack traces fuller than needed, and the order of the filter could be a problem. Listener is asked _before_ anything happens. regards Leon On Mon, Apr 29, 2013 at 4:59 PM, Howard W. Smith, Jr. smithh032...@gmail.com wrote: On Mon, Apr 29, 2013 at 10:54 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Even, the requests are keepalived they look to me as if they were executed parallel. At least from the chrome timeline. But its hard to tell without further investigation. Yeah, you might have to use a packet-sniffer. definitely sounds like overkill. how much code you need to write for such a thing, all because one would want to avoid using a filter???
Re: getting the request that created the session
On Mon, Apr 29, 2013 at 4:54 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Leon, On 4/29/13 10:36 AM, Leon Rosenberg wrote: On Mon, Apr 29, 2013 at 3:49 PM, Christopher Schultz ch...@christopherschultz.net wrote: Leon, So your initial implementation was a Filter that marked each HttpSession with the origin IP address (so you could get the TLD of the user) and then a Listener to keep track of the sessions? What's wrong with that? It seemed to complicated. I now could strip it down to 1 file, that is both HttpSession and ServletRequest- Listener: http://svn.anotheria.net/opensource/moskito/trunk/moskito-web/java/net/anotheria/moskito/web/session/SessionByTldListener.java Note that, although this is a single class, you might get two separate objects created by Tomcat: one as the ServletContextListener and one as the HttpSessionListener. How do you attach the listeners to the webapp? Via web.xml or some other way? one entry in the web.xml for now. It works at least in tomcat 7, but I haven't tested it further. Its also the same object (now). But you are right, I will make the counting part static ;-). I don't know what the container does if a listener implements more than one interface... I've never personally cared about such a scenario. The drawback is, I can count only from second request, because the session is created later. And I don't want to create sessions on all requests. I'm thinking about moving (duplicating) the call in requestDestroyed. Well, you only care about requests that actually create sessions, so the first request is not really relevant. Or do you mean that the request listener gets the event /before/ the session is created. Hmm. Exactly. Its also logical to me, that this happens this way, because at the moment of request creation of the first request noone called getSession(true) yet. regards Leon The request that occur simultaneously in chrome(only) are pictures and js, replied with 304: 1. Request URL: http://localhost:8080/moskitodemo/js/wz_tooltip.js 2. Request Method: GET 3. Status Code: 304 Not Modified 4. Request Headersview source 1. Accept: */* 2. Accept-Encoding: gzip,deflate,sdch 3. Accept-Language: en-US,en;q=0.8 4. Cache-Control: max-age=0 5. Connection: keep-alive 6. Cookie: JSESSIONID=71474A695869D2494E2135CBCEAF 7. Host: localhost:8080 8. If-Modified-Since: Sat, 27 Apr 2013 21:49:44 GMT 9. If-None-Match: W/35082-1367099384000 10. Referer: http://localhost:8080/moskitodemo/mui/mskShowAllProducers 11. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.65 Safari/537.36 5. Response Headersview source 1. Date: Mon, 29 Apr 2013 14:24:36 GMT 2. ETag: W/35082-1367099384000 3. Server: Apache-Coyote/1.1 Even, the requests are keepalived they look to me as if they were executed parallel. At least from the chrome timeline. But its hard to tell without further investigation. Yeah, you might have to use a packet-sniffer. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRfomfAAoJEBzwKT+lPKRY89cQAJjLc/xH++tfrNubd9eE+3s3 UKI5prfRYogHXsXzUG/sB1GS2Gpii+6Qtzuen+/9eHp9zfirKWpWFhk2yPQi1MTz oyXQmrXOlYtKwg9iX7FQnkrHfzXbT3Qx5vzrHemf4uwOBhZ9SyutzJsomeHi8Ev0 B7VMZoKz+APyDLQvCyEYKrJpFwtTcD18RaknUKQzgYxFafh98jL6J0icyv3gq9JW MJdl1VSgY0SdkoYitAmDE4Z0qQ9pV6QbS7z4W0VBC9UzxwsG6c+c94ncz3G4WKaa mTNvY7SO/PR/z7FNbfo9AO6pvCZ+5SGnxoQ6C99BdJ/Eo8F78tSVR36H7IC5gNKz rDJN5tLkCIRcWz3KHeqstL4EnB7FyO838bSamKdOExAEa5+zZCREf8T9D4L6dcCb s+bxB+j/fJKSIRXkfiqNozIJ+uwPmr1P/vEqiWEjEVdMJEo2ByTK4Jnx8FJcAi99 sgVLK0fTH+7J85sSArF2zatZO8LxPE860rNR2CbU/NeeXI1MhxlJnGgPd6jIuOtA 8QA17rilYIOWp4icQOqubS2j4g3HmpgMDGnoD59DDJRN5odUPQEDzYYD04XjjeQp VZFSUdThfxSIzp4CBLmHXTiHXMkgflu5MF0aq0oa6T0eU6SNXkoAr7TC4wB/sHNR 2JCE36iSziLeIJHKTgmQ =W8Ia -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: getting the request that created the session
Leon, On Mon, Apr 29, 2013 at 11:02 AM, Leon Rosenberg rosenberg.l...@gmail.comwrote: Hello Howard, the sniffer thing has nothing to do with original topic, I was just wandering that some requests were having session marked as new, which actually shouldn't be the case. Or in other word, the naive understanding of session.isNew method is that it should only return true once. But it did to it multiple times. The was strange, and christopher and myself were talking about investigating it further. Okay/understood. Back to your question, filter is ok, too many filters are making stack traces fuller than needed, and the order of the filter could be a problem. Listener is asked _before_ anything happens. Good point(s). About how many filters are you trying to consolidate by using this approach? I have seen recommendations of adding filters for file types, filters for login/session-management, etc... I have taken those concepts and put those in one filter which I have implemented and maintain and have done my best to ensure that it is 'thread-safe' as well. Some months ago, I reported an issue to tomcat JIRA/issue list, and those guys shot down my filter and said that it is not thread-safe. Since then, I have made some code changes in the filter and related sources (referenced by the filter), and did my best to make sure it is more threadsafe, even did some research on thread-safe filters (when injecting via CDI), etc... also, I am using OmniFaces gzip filter. To my knowledge, that is 2 filters in my app, that I see in stacktrace, when I have issues to troubleshoot/debug. When I am debugging, I often wonder why 'filter' show up all the time in stacktrace, but then of course, I have to remember that every user/HTTP request has to pass through the filter. So, okay, moving forward, ignore the fact that the (only) filter(s i have in my app) showed up in the stacktrace. regards Leon On Mon, Apr 29, 2013 at 4:59 PM, Howard W. Smith, Jr. smithh032...@gmail.com wrote: On Mon, Apr 29, 2013 at 10:54 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Even, the requests are keepalived they look to me as if they were executed parallel. At least from the chrome timeline. But its hard to tell without further investigation. Yeah, you might have to use a packet-sniffer. definitely sounds like overkill. how much code you need to write for such a thing, all because one would want to avoid using a filter???
Re: getting the request that created the session
Hello Howard et al, On Mon, Apr 29, 2013 at 5:55 PM, Howard W. Smith, Jr. smithh032...@gmail.com wrote: Leon, On Mon, Apr 29, 2013 at 11:02 AM, Leon Rosenberg rosenberg.l...@gmail.comwrote: Back to your question, filter is ok, too many filters are making stack traces fuller than needed, and the order of the filter could be a problem. Listener is asked _before_ anything happens. Good point(s). About how many filters are you trying to consolidate by using this approach? I have seen recommendations of adding filters for file types, filters for login/session-management, etc... I have taken those concepts and put those in one filter which I have implemented and maintain and have done my best to ensure that it is 'thread-safe' as well. Some months ago, I reported an issue to tomcat JIRA/issue list, and those guys shot down my filter and said that it is not thread-safe. Since then, I have made some code changes in the filter and related sources (referenced by the filter), and did my best to make sure it is more threadsafe, even did some research on thread-safe filters (when injecting via CDI), etc... also, I am using OmniFaces gzip filter. To my knowledge, that is 2 filters in my app, that I see in stacktrace, when I have issues to troubleshoot/debug. When I am debugging, I often wonder why 'filter' show up all the time in stacktrace, but then of course, I have to remember that every user/HTTP request has to pass through the filter. So, okay, moving forward, ignore the fact that the (only) filter(s i have in my app) showed up in the stacktrace. Whether you want to have multiple filters or not is a decision based on your coding guidelines, architectural principles and what not. Since you are the only user of your filters, it's free to you to use as many (or few) filter as possible. Personally I would like to separate by concerns and have multiple filters, because it makes it easier to use, maintain and test. But this is personal opinion. However, in my case, I am developing a library that is used by others in their projects (http://moskito.anotheria.net). It comes already with 8 filters ( http://server04.test.anotheria.net:8080/moskitodemo/mui/mskShowProducersByCategory?pCategory=filter) and this is a lot. Of course the end user (developer) only chooses the filters he needs, and not everyone needs everything. However, since its a lib, you don't want it to show up in your stack traces every request, you'd rather forget, that you have it at all. Therefore I'm trying to choose a less visible approach ;-) Also it's easier to add one listener to web.xml as to add a listener AND a filter. And I need the listener, to know when sessions expire anyway ;-) But again, your situation is obviously different from mine ;-) But if you want to count sessions and all the other funny stuff, give moskito a chance: https://confluence.opensource.anotheria.net/display/MSK/HowTo+embed+MoSKito+WebUI+into+a+maven+built+war https://confluence.opensource.anotheria.net/display/MSK/Integration+Guide regards Leon regards Leon On Mon, Apr 29, 2013 at 4:59 PM, Howard W. Smith, Jr. smithh032...@gmail.com wrote: On Mon, Apr 29, 2013 at 10:54 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Even, the requests are keepalived they look to me as if they were executed parallel. At least from the chrome timeline. But its hard to tell without further investigation. Yeah, you might have to use a packet-sniffer. definitely sounds like overkill. how much code you need to write for such a thing, all because one would want to avoid using a filter???
Re: getting the request that created the session
On Mon, Apr 29, 2013 at 12:55 PM, Leon Rosenberg rosenberg.l...@gmail.comwrote: Whether you want to have multiple filters or not is a decision based on your coding guidelines, architectural principles and what not. Since you are the only user of your filters, it's free to you to use as many (or few) filter as possible. Personally I would like to separate by concerns and have multiple filters, because it makes it easier to use, maintain and test. But this is personal opinion. However, in my case, I am developing a library that is used by others in their projects (http://moskito.anotheria.net). It comes already with 8 filters ( http://server04.test.anotheria.net:8080/moskitodemo/mui/mskShowProducersByCategory?pCategory=filter ) and this is a lot. Of course the end user (developer) only chooses the filters he needs, and not everyone needs everything. However, since its a lib, you don't want it to show up in your stack traces every request, you'd rather forget, that you have it at all. Therefore I'm trying to choose a less visible approach ;-) Also it's easier to add one listener to web.xml as to add a listener AND a filter. And I need the listener, to know when sessions expire anyway ;-) But again, your situation is obviously different from mine ;-) But if you want to count sessions and all the other funny stuff, give moskito a chance: https://confluence.opensource.anotheria.net/display/MSK/HowTo+embed+MoSKito+WebUI+into+a+maven+built+war https://confluence.opensource.anotheria.net/display/MSK/Integration+Guide Agreed-and-understood on all points. I am definitely interested in a better approach to managing/monitoring sessions in my web app (that is why i find this thread interesting), but ATM, my current session-management/monitoring implementation meets /my/ requirements. If/when I get a moment (or some bandwidth), I may take a look at your what you have developed. Thanks. regards, Howard
Re: getting the request that created the session
Martin Gainty wrote: org.apache.catalina.valves.RemoteIPValve getRemoteIpHeader? Martin ... Date: Sat, 27 Apr 2013 23:08:31 +0200 Subject: getting the request that created the session From: rosenberg.l...@gmail.com To: users@tomcat.apache.org Hi, is there any possibility to get the first request from a session (or any request from a session) from the HttpSessionListener. Background, I want to count sessions by top level domains. I'm doing it now in a combination of filter and listener. Filter for new sessions, putting a mark for already counted sessions, and listener for destroyed session. However, I would like to get rid of the Filter, if its possible somehow. For that, I need to get user's ip adress somehow. For once, I find myself more or less in agreement with Marting here. I am not sure that I understand exactly what you are trying to do, but just in case : If your plan is to get rid of the filter : If you set up an access log, you will get an access log file, which you can configure to include the client's IP address. Than you can process that file off-line to extract whatever information you want, without using up additional Tomcat resources. There are even various programs available that will do this processing for you and generate nice tables and graphs etc. without further programming (webalizer, awstats and similar). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: getting the request that created the session
Hello Konstantin, thank you for your reply. Background, I want to count sessions by top level domains. I'm doing it now in a combination of filter and listener. Filter for new sessions, putting a mark for already counted sessions, and listener for destroyed session. However, I would like to get rid of the Filter, if its possible somehow. For that, I need to get user's ip adress somehow. Just two ideas: 1. You can use javax.servlet.ServletRequestListener instead of a filter. 2. There is HttpSession.isNew() method. So you mean that I can basically perform the same checks I do in a filter in a servletrequestlistener, checking if there is an attached session, if it's new, and where it comes from. I haven't found it in the spec (or didn't search hard enough, at least haven't found it in listener section), would ServletRequestListener being notified prior to any Filter execution? regards Leon Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: getting the request that created the session
2013/4/28 Martin Gainty mgai...@hotmail.com org.apache.catalina.valves.RemoteIPValve getRemoteIpHeader? Martin Thanks but I would like to stay container independent here. regards Leon
Re: getting the request that created the session
Answering my own email :-)
On Sun, Apr 28, 2013 at 6:07 PM, Leon Rosenberg rosenberg.l...@gmail.comwrote:
Hello Konstantin,
thank you for your reply.
Background, I want to count sessions by top level domains. I'm doing it
now
in a combination of filter and listener. Filter for new sessions,
putting a
mark for already counted sessions, and listener for destroyed session.
However, I would like to get rid of the Filter, if its possible somehow.
For that, I need to get user's ip adress somehow.
Just two ideas:
1. You can use javax.servlet.ServletRequestListener instead of a filter.
2. There is HttpSession.isNew() method.
So you mean that I can basically perform the same checks I do in a filter
in a servletrequestlistener, checking if there is an attached session, if
it's new, and where it comes from.
I haven't found it in the spec (or didn't search hard enough, at least
haven't found it in listener section), would ServletRequestListener being
notified prior to any Filter execution?
So i made a combined HttpSessionListener and ServletRequestListener.
Advantages vs. Filter/Listener solution: only one class needed.
Disadvantage: Only second request is seen, because first request is
sessionless.
HttpSession.isNew() doesn't do what I'd expect it to do, in fact multiple
requests come in with same session and new status, so I will need to
synchronize on session object.
Here a small test listener:
public class TestListener implements HttpSessionListener,
ServletRequestListener{
private AtomicLong counter = new AtomicLong(0);
@Override
public void sessionCreated(HttpSessionEvent se) {
System.out.println(Session created +se.getSession().getId());
}
@Override
public void requestDestroyed(ServletRequestEvent sre) {
System.out.println(Request +((HttpServletRequest)
sre.getServletRequest()).getAttribute(___requestId___)+ destroyed +
((HttpServletRequest) sre.getServletRequest()).getRequestURI());
}
@Override
public void requestInitialized(ServletRequestEvent sre) {
long requestId = counter.incrementAndGet();
System.out.println(Request +requestId+ created
+((HttpServletRequest)sre.getServletRequest()).getRequestURI());
((HttpServletRequest)sre.getServletRequest()).setAttribute(___requestId___,
requestId);
HttpSession session =
((HttpServletRequest)sre.getServletRequest()).getSession(false);
System.out.println(Session? + (session!=null));
if (session!=null){
System.out.println(Session +session.getId()+ new? +session.isNew());
}
}
Output for http://localhost:8080/moskitodemo/mui/mskShowAllProducers:
Request 1 created /moskitodemo/mui/mskShowAllProducers
Session created 4B842C774B30EE7886CC7243758C7D38
Request 2 created /moskitodemo/mui/mskCSS
Session? true
Session 4B842C774B30EE7886CC7243758C7D38 new? true
Request 3 created /moskitodemo/img/moskito_webui_logo.gif
Session? true
Session 4B842C774B30EE7886CC7243758C7D38 new? true
Request 4 created /moskitodemo/js/wz_tooltip.js
Session? true
Session 4B842C774B30EE7886CC7243758C7D38 new? true
Request 5 created /moskitodemo/js/jquery-1.4.min.js
Session? true
Session 4B842C774B30EE7886CC7243758C7D38 new? true
Request 6 created /moskitodemo/js/function.js
Session? true
Session 4B842C774B30EE7886CC7243758C7D38 new? true
Request 6 destroyed /moskitodemo/js/function.js
Request 5 destroyed /moskitodemo/js/jquery-1.4.min.js
Request 4 destroyed /moskitodemo/js/wz_tooltip.js
Request 3 destroyed /moskitodemo/img/moskito_webui_logo.gif
Request 7 created /moskitodemo/img/ind_green.png
Session? true
Session 4B842C774B30EE7886CC7243758C7D38 new? false
Request 2 destroyed /moskitodemo/mui/mskCSS
Request 7 destroyed /moskitodemo/img/ind_green.png
Request 8 created /moskitodemo/img/bgs.gif
Session? true
Session 4B842C774B30EE7886CC7243758C7D38 new? false
Request 8 destroyed /moskitodemo/img/bgs.gif
Request 9 created /moskitodemo/img/vline.png
Session? true
Session 4B842C774B30EE7886CC7243758C7D38 new? false
Request 10 created /moskitodemo/img/ind_off_small.png
Session? true
Session 4B842C774B30EE7886CC7243758C7D38 new? false
Request 9 destroyed /moskitodemo/img/vline.png
Request 11 created /moskitodemo/img/icons.png
Session? true
Session 4B842C774B30EE7886CC7243758C7D38 new? false
Request 11 destroyed /moskitodemo/img/icons.png
Request 10 destroyed /moskitodemo/img/ind_off_small.png
Request 1 destroyed /moskitodemo/mui/mskShowAllProducers
As you see there are multiple requests with session.isNew = true. I am not
sure if its proper behavior at least the docs aren't clear enough here, but
it's definitely not good enough to ensure that each session is called only
once.
regards
Leon
P.S. The above sequence is only reproduceable in chrome, not firefox
regards
Leon
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: getting the request that created the session
___ From: Leon Rosenberg [rosenberg.l...@gmail.com] Subject: Re: getting the request that created the session would ServletRequestListener being notified prior to any Filter execution? According to the docs, yes. A ServletRequest is defined as coming into scope of a web application when it is about to enter the first servlet or filter of the web application, and as going out of scope as it exits the last servlet or the first filter in the chain. http://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequestListener.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: getting the request that created the session
2013/4/28 Leon Rosenberg rosenberg.l...@gmail.com: Hi, is there any possibility to get the first request from a session (or any request from a session) from the HttpSessionListener. No. It is not possible to get request from within a HttpSessionListener. Background, I want to count sessions by top level domains. I'm doing it now in a combination of filter and listener. Filter for new sessions, putting a mark for already counted sessions, and listener for destroyed session. However, I would like to get rid of the Filter, if its possible somehow. For that, I need to get user's ip adress somehow. Just two ideas: 1. You can use javax.servlet.ServletRequestListener instead of a filter. 2. There is HttpSession.isNew() method. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: getting the request that created the session
org.apache.catalina.valves.RemoteIPValve getRemoteIpHeader? Martin __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Sat, 27 Apr 2013 23:08:31 +0200 Subject: getting the request that created the session From: rosenberg.l...@gmail.com To: users@tomcat.apache.org Hi, is there any possibility to get the first request from a session (or any request from a session) from the HttpSessionListener. Background, I want to count sessions by top level domains. I'm doing it now in a combination of filter and listener. Filter for new sessions, putting a mark for already counted sessions, and listener for destroyed session. However, I would like to get rid of the Filter, if its possible somehow. For that, I need to get user's ip adress somehow. thanks in advance Leon
