Hi. I am encountering errors when I attempt to execute a stored procedure two or more times. A Tomcat servlet connects to PIP via the JDBC driver and makes the SQL calls. The first time the stored procedure runs, it works fine and I get all the expected records. Any additional attempts to execute the same procedure (by reload the web page) causes an error, such as:
-----------------------
HTTP Status 500 -
type Exception report
message
description The server encountered an internal error () that prevented it from fulfilling this request.
exception
java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 3
java.util.Vector.get(Vector.java:694)
sanchez.utils.ScMatrix.elementAt(Unknown Source)
sanchez.jdbc.driver.ScJdbcResultSet.wasNull(Unknown Source)
sanchez.jdbc.driver.ScJdbcResultSet.getString(Unknown Source)
PipJdbc.doGet(PipJdbc.java:102)
javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
note The full stack trace of the root cause is available in the Apache Tomcat/5.5 logs.
Apache Tomcat/5.5
----------------------
Restarting Tomcat will allow the stored procedure to run again, but only for one time. The stored procedures I am using are generally something like "select * from TABLE". If I change the code to execute the select query directly, I don't have any problems -- I can run the select multiple times just fine. To complicate the problem further, I have only encountered this issue (so far) on tables that I have defined, and have not be able to reproduce the problem on any existing PIP table. So, I suspect that there is something about the structures I am mapping that are triggering this problem. I get the same results using Tomcat 5.5 on linux, and Tomcat 6.0 on Windows.
Would it be possible for me to send someone a sample WAR app, a file export and the sample data that demonstrates this problem? Solving this issue is going to be critical for us in order to move PIP into our production environment.
Ed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you start the MTM journal and reproduce this problem? The MTM journal logs all the requests and replies that goes through the MTM. I want to see the reply from Profile when the stored procedure is called the second time. So if you can create an MTM journal for both the times the stored procedure is called and send to me, that'll help in understanding the problem.
Thanks
Manoj
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sourceforge rejected the mail because I zipped the file, and then again because the attached file was too large when not zipped. I have sent the file to Bhaskar and asked him to forward it to you.
Ed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There seems to be bug in the JDBC Driver where it's sending in the qualifier /NOMETA=1 when the stored procedure is called the second time, even though it's a different connection. It's suppose to send that qualifier only if the same stored procedure is called using the same connection token.
I'll fix this bug in the next release.
Thanks
Manoj
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi. I am encountering errors when I attempt to execute a stored procedure two or more times. A Tomcat servlet connects to PIP via the JDBC driver and makes the SQL calls. The first time the stored procedure runs, it works fine and I get all the expected records. Any additional attempts to execute the same procedure (by reload the web page) causes an error, such as:
-----------------------
HTTP Status 500 -
type Exception report
message
description The server encountered an internal error () that prevented it from fulfilling this request.
exception
java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 3
java.util.Vector.get(Vector.java:694)
sanchez.utils.ScMatrix.elementAt(Unknown Source)
sanchez.jdbc.driver.ScJdbcResultSet.wasNull(Unknown Source)
sanchez.jdbc.driver.ScJdbcResultSet.getString(Unknown Source)
PipJdbc.doGet(PipJdbc.java:102)
javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
note The full stack trace of the root cause is available in the Apache Tomcat/5.5 logs.
Apache Tomcat/5.5
----------------------
Restarting Tomcat will allow the stored procedure to run again, but only for one time. The stored procedures I am using are generally something like "select * from TABLE". If I change the code to execute the select query directly, I don't have any problems -- I can run the select multiple times just fine. To complicate the problem further, I have only encountered this issue (so far) on tables that I have defined, and have not be able to reproduce the problem on any existing PIP table. So, I suspect that there is something about the structures I am mapping that are triggering this problem. I get the same results using Tomcat 5.5 on linux, and Tomcat 6.0 on Windows.
Would it be possible for me to send someone a sample WAR app, a file export and the sample data that demonstrates this problem? Solving this issue is going to be critical for us in order to move PIP into our production environment.
Ed
I still need this problem resolved.
Ed
Ed,
Can you start the MTM journal and reproduce this problem? The MTM journal logs all the requests and replies that goes through the MTM. I want to see the reply from Profile when the stored procedure is called the second time. So if you can create an MTM journal for both the times the stored procedure is called and send to me, that'll help in understanding the problem.
Thanks
Manoj
Manoj,
I have emailed you the journal file separately (to your sourceforge mail address).
Ed
Sourceforge rejected the mail because I zipped the file, and then again because the attached file was too large when not zipped. I have sent the file to Bhaskar and asked him to forward it to you.
Ed
Ed,
Bhaskar forwarded the MTM journal.
There seems to be bug in the JDBC Driver where it's sending in the qualifier /NOMETA=1 when the stored procedure is called the second time, even though it's a different connection. It's suppose to send that qualifier only if the same stored procedure is called using the same connection token.
I'll fix this bug in the next release.
Thanks
Manoj