tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Moller" <andymol...@gmail.com>
Subject Re: Tomcat 4.x (Major Problem)
Date Tue, 23 Jan 2007 03:56:50 GMT
On 1/22/07, Christopher Schultz <chris@christopherschultz.net> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andy,
>
> Andy Moller wrote:
> > String commonName = (String)session.getAttribute("commonName");
> > String[] value1 = (request.getParameterValues("value_1") != null)
> >        ? request.getParameterValues("value_1")
> >        : new String[0];
> >
> > String[] value2 =
> >    (request.getParameterValues("value_2") != null)
> >        ? request.getParameterValues("value_2")
> >        : new String[0];
>
> [snip]
>
> >                query=
> >                    "insert into sample_table(id,val1,common_name,val2)"
> >                        + " values (sequence.nextVal,"
> >                        + singleVal1
> >                        + ",'"
> >                        + commonName
> >                        + "','"
> >                        + val2[j]
> >                        + "')";
>
> A few notes:
>
> 1. You are using the array "val2" here instead of "value2". Is that
> intentional? Or, were you somewhat obfuscating your code for publication
> on the list?


Andy: It is a mistake while changing the variable naming, the variable name
should be "val2" not "value2", i have to alter the namings

2. You really should be using PreparedStatements instead of string
> concatenation for parameter replacement.


Andy: you are right, but this is one "way" to do it, It has performance and
other issues but it should not affect the final results.

3. These is no evidence that "commonName" ever had the value that you
> expected. Your initial claim was that the value was being taken from the
> session and, between that time and the issue of the SQL query, the value
> was being changed.


Andy: the value of the "commonName" is set ONLY ONCE at the session
initalization, and not updated during the session life, you can think about
it as an application specific session ID. A filter ensures the existance of
a valid "commonName" with each request, otherwise the access to the JSP page
is not permitted

So... what's going on here? During the processing of this request, can
> you ever see session.getAttribute("commonName") returning the correct
> value? Or, has the session really been polluted somehow, or have you
> really "swtiched" sessions somehow?


Andy: (same note as above)

> Where the value "nameB" is the "commonName" session attribute value from
> > a different session.
>
> Is there any relationship whatsoever between the session you should have
> and the session that you are apparently getting? Are you /sure/ that
> there is another session containing that value, or are you assuming that
> since it's not the expected value that you must be looking at another
> session.


Andy: I am sure there is another session with the "nameB" at the same time i
had that incident, the application has a filter that keep track of the
session requests and activities, it keeps a log with requests and operations
for every session from start to end.

Is your entire application written in JSP? I'm wondering if you ever try
> to manage sessions yourself in any way.
>
> Try this: create an HttpSesssionBindingListener and implement the
> valueBound method like this:
>
> public void valueBound(HttpSessionBindingEvent esbe)
> {
>    if("commonName".equals(esbe.getName()))
>    {
>        System.out.println("Setting session["
>          + esbe.getSession().getId()
>          + "].commonName="
>          + esbe.getValue());
>        new Throwable().printStackTrace(System.out);
>    }
> }
>
> This will put a full stack trace into stdout whenever the value of
> commonName for a session is changed. I'm assuming that you have a test
> plan that is reproducing this error in development, so you can watch the
> logs as you move through your application.
>
> Login and watch the logs. You can see when a value is poked into the
> session, and what that value is. If you see that the value is changing
> in your session (and it shouldn't be), then you'll see the stack trace
> of the code that's doing it.
>
> You can install this listener using a <listener> element in your web.xml
> like this:
>
> <listener>
> <listener-class>your.package.ComonNameSessionBindingListener
> </listener-class>
> </listener>
>
> This goes after any <filter> and <filter-mapping> elements and before
> any <servlet> elements.



Andy: I have not attempted a similar check, though the filter I mentioned
earlier logs the session variables with each request. I was not suspecting
session variables until I stumbled upon that statement in the error log. We
tried to simulate random sessions and perform similar operations per each
session to overload the JDBC drivers but all operations went ok.



That issue occurs on relatively far intervals and in a random fashion; we
are trying to systematically isolate each component and so far we have just
started debugging Tomcat as a possible cause.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFtTXT9CaO5/Lv0PARAjY2AJ92nhsTHaW9IQTIETpM1J40gAcwSQCeMyWr
sp4svE3vaNqmhp6iCFqLWqI=
=HlHR
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


I hope this adds useful information to the discussion,



Thank you,

Andy

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message