You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Leon Rosenberg <ro...@gmail.com> on 2013/04/27 23:08:31 UTC
getting the request that created the session
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
Re: getting the request that created the session
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: getting the request that created the session
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Mon, Apr 29, 2013 at 9:54 AM, André Warnier <aw...@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
Posted by André Warnier <aw...@ice-sa.com>.
Leon Rosenberg wrote:
> Hello Andre,
>
>
> On Mon, Apr 29, 2013 at 10:13 AM, André Warnier <aw...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: getting the request that created the session
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Mon, Apr 29, 2013 at 12:55 PM, Leon Rosenberg
<ro...@gmail.com>wrote:
>
> 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
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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 List<SetUpFilter> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: getting the request that created the session
Posted by Leon Rosenberg <ro...@gmail.com>.
Hello Howard et al,
On Mon, Apr 29, 2013 at 5:55 PM, Howard W. Smith, Jr. <
smithh032772@gmail.com> wrote:
> Leon,
>
> On Mon, Apr 29, 2013 at 11:02 AM, Leon Rosenberg
> <ro...@gmail.com>wrote:
>
> 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. <
> > smithh032772@gmail.com> wrote:
> >
> > > On Mon, Apr 29, 2013 at 10:54 AM, Christopher Schultz <
> > > chris@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
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Leon,
On Mon, Apr 29, 2013 at 11:02 AM, Leon Rosenberg
<ro...@gmail.com>wrote:
> 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. <
> smithh032772@gmail.com> wrote:
>
> > On Mon, Apr 29, 2013 at 10:54 AM, Christopher Schultz <
> > chris@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
Posted by Leon Rosenberg <ro...@gmail.com>.
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. <
smithh032772@gmail.com> wrote:
> On Mon, Apr 29, 2013 at 10:54 AM, Christopher Schultz <
> chris@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
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Mon, Apr 29, 2013 at 10:54 AM, Christopher Schultz <
chris@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
Posted by Leon Rosenberg <ro...@gmail.com>.
On Mon, Apr 29, 2013 at 4:54 PM, Christopher Schultz <
chris@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 <
> > chris@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=712222474A695869D2494E2135CBCEAF 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: getting the request that created the session
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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 <
> chris@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=712222474A695869D2494E2135CBCEAF 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: getting the request that created the session
Posted by Leon Rosenberg <ro...@gmail.com>.
On Mon, Apr 29, 2013 at 3:49 PM, Christopher Schultz <
chris@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=712222474A695869D2494E2135CBCEAF
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: getting the request that created the session
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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 <aw...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: getting the request that created the session
Posted by Leon Rosenberg <ro...@gmail.com>.
Hello Andre,
On Mon, Apr 29, 2013 at 10:13 AM, André Warnier <aw...@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
Posted by André Warnier <aw...@ice-sa.com>.
Leo Donahue - RDSA IT wrote:
> _______________________________________
> From: Leon Rosenberg [rosenberg.leon@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: getting the request that created the session
Posted by Leo Donahue - RDSA IT <Le...@mail.maricopa.gov>.
_______________________________________
From: Leon Rosenberg [rosenberg.leon@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: getting the request that created the session
Posted by Leon Rosenberg <ro...@gmail.com>.
Answering my own email :-)
On Sun, Apr 28, 2013 at 6:07 PM, Leon Rosenberg <ro...@gmail.com>wrote:
> 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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
Re: getting the request that created the session
Posted by Leon Rosenberg <ro...@gmail.com>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: getting the request that created the session
Posted by Konstantin Kolinko <kn...@gmail.com>.
2013/4/28 Leon Rosenberg <ro...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: getting the request that created the session
Posted by Leon Rosenberg <ro...@gmail.com>.
2013/4/28 Martin Gainty <mg...@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
Posted by André Warnier <aw...@ice-sa.com>.
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.leon@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: getting the request that created the session
Posted by Martin Gainty <mg...@hotmail.com>.
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.leon@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