DO NOT REPLY [Bug 47437] New: better exception message for shutdown
https://issues.apache.org/bugzilla/show_bug.cgi?id=47437 Summary: better exception message for shutdown Product: Tomcat 6 Version: 6.0.20 Platform: PC OS/Version: Windows Vista Status: NEW Severity: enhancement Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: michael.i...@gmail.com There are many Tomcat users that disable the shutdown port by setting it to '-1'. When I do so, I am not allowed to run shutdown.bat|sh anymore because there is no port anymore for shutodown. In that case, I've got an exception message which is difficult to understand. It would be nice to provide a message such as "you might have disabled the shutdown port. In that case you should kill the tomcat process or close the Tomcat shell/dos window." Here is the exception I had: E:\tomcat\bin>if not "" == "" goto doSecurity E:\tomcat\bin>"D:\Java\JDK1.6\bin\java" -server -Xmx2 56m -Xms128m -Xss128k -Djava.endorsed.dirs="E:\tomcat\ho me\endorsed" -classpath "D:\Java\JDK1.6\lib\tools.jar;E:\tomcat\home\bin\bootstrap.jar" -Dcatalina.base="E:\tomcat\b ase1" -Dcatalina.home="E:\tomcat" -Djava.io.tmpdir="E :\tomcat\base1\temp" org.apache.catalina.startup.Bootstrap stop java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.startup.Bootstrap.stopServer(Bootstrap.java:337) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:415) Caused by: java.lang.IllegalArgumentException: port out of range:-1 at java.net.InetSocketAddress.(InetSocketAddress.java:118) at java.net.Socket.(Socket.java:180) at org.apache.catalina.startup.Catalina.stopServer(Catalina.java:421) ... 6 more E:\tomcat\bin>goto end -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r788214 - /tomcat/current/tc5.5.x/STATUS.txt
Mark Thomas wrote: >Konstantin Kolinko wrote: >> 2. struct.currentDateString is calculated in two different places >> I propose to encapsulate that code into AccessDateStruct >> >> 3. Invocation of getDate() in invoke() (the only place where getDate() >> is called): >> I think that getDate() also can be incapsulated into AccessDateStruct. >> Actually, I think of the following: >> 1) In invoke() there is already a variable that stores current time >> millis: "t2" >> I propose to replace that getDate() with >> AccessDateStruct.setDate(t2) that will perform the same job. >> 2) Change the signature of replace(..., Date, ..) method, and pass a >> reference to the AccessDateStruct instead of a Date. >> In the future the replace(..) methods of this class can be changed to >> accept a StringBuffer, instead of returning a String, but that can be >> another story. >> >> If AccessDateStruct is passed into the replace() method, >> timeTakenFormatter can be added to it as well. Maybe. >> >> 4. The log() method still creates a new Date() once in a second. >> The Date instance can be stored in some member variable and reused. It >> is in a synchronized block, so it will be safe. >> I do not like, that it is the same once-in-a-second synchronized >> block, that we already avoided once by using those ThreadLocals. >> Can be addressed separately, though. > > Thanks for this. I'll see about updating the patch. > One more thought: It would be better if the ThreadLocal is shared among all AccessLogValve instances on the same server. Otherwise, the count of threads will be multiplied by the count of AccessLogValve instances. That implies that the AccessDateStruct does not have any configurable parameters or any valve instance specific data. E.g., fileDateFormat is configurable, thus its formatter is not a candidate to be put there (and it is not there now). >> I do not like, that it is the same once-in-a-second synchronized >> block, that we already avoided I was not right writing this. We avoided sync around the formatters on every call, and that makes a difference. We already have sync in the writer on every call, so this sync once-in-a second won't be something noticeable. Though maybe it can be done once in 5/20/60 secs, but who cares. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47439] New: PooledConnection.connect() fails to check for null connection
https://issues.apache.org/bugzilla/show_bug.cgi?id=47439 Summary: PooledConnection.connect() fails to check for null connection Product: Tomcat 6 Version: unspecified Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Modules: jdbc-pool AssignedTo: dev@tomcat.apache.org ReportedBy: s...@apache.org PooledConnection.connect() fails to check for null return from java.sql.Driver.connect() method. This can result in an NPE when the connection is used later. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47440] New: Remove DB-specific SQL statements from test cases (SELECT 1)
https://issues.apache.org/bugzilla/show_bug.cgi?id=47440 Summary: Remove DB-specific SQL statements from test cases (SELECT 1) Product: Tomcat 6 Version: unspecified Platform: PC OS/Version: Windows XP Status: NEW Severity: enhancement Priority: P2 Component: Modules: jdbc-pool AssignedTo: dev@tomcat.apache.org ReportedBy: s...@apache.org Some of the test cases assume that the JDBC provider supports "SELECT 1" as a valid SQL statement; however this is not always the case, e.g. Derby requires a table name to select from. The solution provided in the patches is to use the validation query defined in the properties set up for the test, rather than always using "SELECT 1". -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47440] Remove DB-specific SQL statements from test cases (SELECT 1)
https://issues.apache.org/bugzilla/show_bug.cgi?id=47440 --- Comment #1 from Sebb 2009-06-27 05:19:01 PST --- Created an attachment (id=23890) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23890) Remove setValidattionQuery() calls -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47440] Remove DB-specific SQL statements from test cases (SELECT 1)
https://issues.apache.org/bugzilla/show_bug.cgi?id=47440 --- Comment #2 from Sebb 2009-06-27 05:19:46 PST --- Created an attachment (id=23891) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23891) Use validationQuery instead of "SELECT 1" -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r788214 - /tomcat/current/tc5.5.x/STATUS.txt
But how could ThreadLocal be shared among all AccessLogValve instances on the same server? After all, each thread access ThreadLocal has its own. Another point, based on the java doc of ThreadLocal, maybe "private ThreadLocal currentDateStruct" should be declared as static? 2009/6/27 Konstantin Kolinko > Mark Thomas wrote: > >Konstantin Kolinko wrote: > >> 2. struct.currentDateString is calculated in two different places > >> I propose to encapsulate that code into AccessDateStruct > >> > >> 3. Invocation of getDate() in invoke() (the only place where getDate() > >> is called): > >> I think that getDate() also can be incapsulated into AccessDateStruct. > >> Actually, I think of the following: > >> 1) In invoke() there is already a variable that stores current time > >> millis: "t2" > >> I propose to replace that getDate() with > >> AccessDateStruct.setDate(t2) that will perform the same job. > >> 2) Change the signature of replace(..., Date, ..) method, and pass a > >> reference to the AccessDateStruct instead of a Date. > >> In the future the replace(..) methods of this class can be changed to > >> accept a StringBuffer, instead of returning a String, but that can be > >> another story. > >> > >> If AccessDateStruct is passed into the replace() method, > >> timeTakenFormatter can be added to it as well. Maybe. > >> > >> 4. The log() method still creates a new Date() once in a second. > >> The Date instance can be stored in some member variable and reused. It > >> is in a synchronized block, so it will be safe. > >> I do not like, that it is the same once-in-a-second synchronized > >> block, that we already avoided once by using those ThreadLocals. > >> Can be addressed separately, though. > > > > Thanks for this. I'll see about updating the patch. > > > > One more thought: > It would be better if the ThreadLocal is shared among all > AccessLogValve instances on the same server. Otherwise, the count of > threads will be multiplied by the count of AccessLogValve instances. > > That implies that the AccessDateStruct does not have any configurable > parameters or any valve instance specific data. > E.g., fileDateFormat is configurable, thus its formatter is not a > candidate to be put there (and it is not there now). > > >> I do not like, that it is the same once-in-a-second synchronized > >> block, that we already avoided > I was not right writing this. We avoided sync around the formatters on > every call, and that makes a difference. > We already have sync in the writer on every call, so this sync > once-in-a second won't be something noticeable. Though maybe it can be > done once in 5/20/60 secs, but who cares. > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > -- Sincerely yours and Best Regards, Xie Xiaodong
Re: svn commit: r788214 - /tomcat/current/tc5.5.x/STATUS.txt
On 27/06/2009, Xie Xiaodong wrote: > But how could ThreadLocal be shared among all AccessLogValve instances on > the same server? After all, each thread access ThreadLocal has its own. > > Another point, based on the java doc of ThreadLocal, maybe "private > ThreadLocal currentDateStruct" should be declared as > static? +1, that should ensure that it will be shared. Also it should be declared final. > > 2009/6/27 Konstantin Kolinko > > > > Mark Thomas wrote: > > >Konstantin Kolinko wrote: > > >> 2. struct.currentDateString is calculated in two different places > > >> I propose to encapsulate that code into AccessDateStruct > > >> > > >> 3. Invocation of getDate() in invoke() (the only place where getDate() > > >> is called): > > >> I think that getDate() also can be incapsulated into AccessDateStruct. > > >> Actually, I think of the following: > > >> 1) In invoke() there is already a variable that stores current time > > >> millis: "t2" > > >> I propose to replace that getDate() with > > >> AccessDateStruct.setDate(t2) that will perform the same job. > > >> 2) Change the signature of replace(..., Date, ..) method, and pass a > > >> reference to the AccessDateStruct instead of a Date. > > >> In the future the replace(..) methods of this class can be changed to > > >> accept a StringBuffer, instead of returning a String, but that can be > > >> another story. > > >> > > >> If AccessDateStruct is passed into the replace() method, > > >> timeTakenFormatter can be added to it as well. Maybe. > > >> > > >> 4. The log() method still creates a new Date() once in a second. > > >> The Date instance can be stored in some member variable and reused. It > > >> is in a synchronized block, so it will be safe. > > >> I do not like, that it is the same once-in-a-second synchronized > > >> block, that we already avoided once by using those ThreadLocals. > > >> Can be addressed separately, though. > > > > > > Thanks for this. I'll see about updating the patch. > > > > > > > One more thought: > > It would be better if the ThreadLocal is shared among all > > AccessLogValve instances on the same server. Otherwise, the count of > > threads will be multiplied by the count of AccessLogValve instances. > > > > That implies that the AccessDateStruct does not have any configurable > > parameters or any valve instance specific data. > > E.g., fileDateFormat is configurable, thus its formatter is not a > > candidate to be put there (and it is not there now). > > > > >> I do not like, that it is the same once-in-a-second synchronized > > >> block, that we already avoided > > I was not right writing this. We avoided sync around the formatters on > > every call, and that makes a difference. > > We already have sync in the writer on every call, so this sync > > once-in-a second won't be something noticeable. Though maybe it can be > > done once in 5/20/60 secs, but who cares. > > > > Best regards, > > Konstantin Kolinko > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > > > > -- > Sincerely yours and Best Regards, > > Xie Xiaodong > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r788214 - /tomcat/current/tc5.5.x/STATUS.txt
Yes, you're right. Both static and final. :) 2009/6/27 sebb > On 27/06/2009, Xie Xiaodong wrote: > > But how could ThreadLocal be shared among all AccessLogValve instances on > > the same server? After all, each thread access ThreadLocal has its own. > > > > Another point, based on the java doc of ThreadLocal, maybe "private > > ThreadLocal currentDateStruct" should be declared as > > static? > > +1, that should ensure that it will be shared. > > Also it should be declared final. > > > > > 2009/6/27 Konstantin Kolinko > > > > > > > Mark Thomas wrote: > > > >Konstantin Kolinko wrote: > > > >> 2. struct.currentDateString is calculated in two different places > > > >> I propose to encapsulate that code into AccessDateStruct > > > >> > > > >> 3. Invocation of getDate() in invoke() (the only place where > getDate() > > > >> is called): > > > >> I think that getDate() also can be incapsulated into > AccessDateStruct. > > > >> Actually, I think of the following: > > > >> 1) In invoke() there is already a variable that stores current > time > > > >> millis: "t2" > > > >> I propose to replace that getDate() with > > > >> AccessDateStruct.setDate(t2) that will perform the same job. > > > >> 2) Change the signature of replace(..., Date, ..) method, and pass > a > > > >> reference to the AccessDateStruct instead of a Date. > > > >> In the future the replace(..) methods of this class can be changed > to > > > >> accept a StringBuffer, instead of returning a String, but that can > be > > > >> another story. > > > >> > > > >> If AccessDateStruct is passed into the replace() method, > > > >> timeTakenFormatter can be added to it as well. Maybe. > > > >> > > > >> 4. The log() method still creates a new Date() once in a second. > > > >> The Date instance can be stored in some member variable and reused. > It > > > >> is in a synchronized block, so it will be safe. > > > >> I do not like, that it is the same once-in-a-second synchronized > > > >> block, that we already avoided once by using those ThreadLocals. > > > >> Can be addressed separately, though. > > > > > > > > Thanks for this. I'll see about updating the patch. > > > > > > > > > > One more thought: > > > It would be better if the ThreadLocal is shared among all > > > AccessLogValve instances on the same server. Otherwise, the count of > > > threads will be multiplied by the count of AccessLogValve instances. > > > > > > That implies that the AccessDateStruct does not have any configurable > > > parameters or any valve instance specific data. > > > E.g., fileDateFormat is configurable, thus its formatter is not a > > > candidate to be put there (and it is not there now). > > > > > > >> I do not like, that it is the same once-in-a-second synchronized > > > >> block, that we already avoided > > > I was not right writing this. We avoided sync around the formatters on > > > every call, and that makes a difference. > > > We already have sync in the writer on every call, so this sync > > > once-in-a second won't be something noticeable. Though maybe it can be > > > done once in 5/20/60 secs, but who cares. > > > > > > Best regards, > > > Konstantin Kolinko > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > > > > > > > > > > -- > > Sincerely yours and Best Regards, > > > > Xie Xiaodong > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > -- Sincerely yours and Best Regards, Xie Xiaodong
DO NOT REPLY [Bug 47439] PooledConnection.connect() fails to check for null connection
https://issues.apache.org/bugzilla/show_bug.cgi?id=47439 Filip Hanik changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Filip Hanik 2009-06-27 11:27:12 PST --- I'm not aware of any driver that returns null, when there is a checked exception on the method Driver.connect() -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47439] PooledConnection.connect() fails to check for null connection
https://issues.apache.org/bugzilla/show_bug.cgi?id=47439 Sebb changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #2 from Sebb 2009-06-27 12:09:30 PST --- The Javadoc for Driver.connect() states: >> Attempts to make a database connection to the given URL. The driver should return "null" if it realizes it is the wrong kind of driver to connect to the given URL. This will be common, as when the JDBC driver manager is asked to connect to a given URL it passes the URL to each loaded driver in turn. The driver should throw an SQLException if it is the right driver to connect to the given URL but has trouble connecting to the database. << As it happens, the JDBC driver for Derby also returns null in other cases, which is how I found the problem. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47439] PooledConnection.connect() fails to check for null connection
https://issues.apache.org/bugzilla/show_bug.cgi?id=47439 --- Comment #3 from Sebb 2009-06-27 13:03:46 PST --- Here's the result of using a "jdbc:oracle:" URL with the Derby JDBC client: Testcase: testException(org.apache.tomcat.jdbc.test.TestException): Caused an ERROR null java.sql.SQLException at org.apache.tomcat.jdbc.pool.ConnectionPool.createConnection(ConnectionPool.java:540) at org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:471) at org.apache.tomcat.jdbc.pool.ConnectionPool.init(ConnectionPool.java:370) at org.apache.tomcat.jdbc.pool.ConnectionPool.(ConnectionPool.java:118) at org.apache.tomcat.jdbc.pool.DataSourceProxy.createPool(DataSourceProxy.java:85) at org.apache.tomcat.jdbc.pool.DataSourceProxy.getConnection(DataSourceProxy.java:96) at org.apache.tomcat.jdbc.test.TestException.testException(TestException.java:22) Caused by: java.lang.NullPointerException at org.apache.tomcat.jdbc.pool.PooledConnection.connect(PooledConnection.java:168) at org.apache.tomcat.jdbc.pool.ConnectionPool.createConnection(ConnectionPool.java:517) === This is what happens if a local database "jdbc:derby:dbname" cannot be found: Testcase: testGetConnection(org.apache.tomcat.jdbc.test.TestGetConnection): Caused an ERROR null java.sql.SQLException at org.apache.tomcat.jdbc.pool.ConnectionPool.createConnection(ConnectionPool.java:540) at org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:471) at org.apache.tomcat.jdbc.pool.ConnectionPool.init(ConnectionPool.java:370) at org.apache.tomcat.jdbc.pool.ConnectionPool.(ConnectionPool.java:118) at org.apache.tomcat.jdbc.pool.DataSourceProxy.createPool(DataSourceProxy.java:85) at org.apache.tomcat.jdbc.pool.DataSourceProxy.getConnection(DataSourceProxy.java:96) at org.apache.tomcat.jdbc.test.TestGetConnection.testGetConnection(TestGetConnection.java:32) Caused by: java.lang.NullPointerException at org.apache.tomcat.jdbc.pool.PooledConnection.connect(PooledConnection.java:168) at org.apache.tomcat.jdbc.pool.ConnectionPool.createConnection(ConnectionPool.java:517) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47439] PooledConnection.connect() fails to check for null connection
https://issues.apache.org/bugzilla/show_bug.cgi?id=47439 Filip Hanik changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Comment #4 from Filip Hanik 2009-06-27 15:38:13 PST --- In both cases you get a SQLException, as specified by the API for getting a connection. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47439] PooledConnection.connect() fails to check for null connection
https://issues.apache.org/bugzilla/show_bug.cgi?id=47439 Sebb changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #5 from Sebb 2009-06-27 16:10:47 PST --- I think we are talking about two different APIs here. The Driver.connect() API specifically says that it returns null for some cases. I'm not sure which API you are referring to, as I could not find any Javadoc for any of the methods involved. The NPE is caught later and converted into an SQLException, but the resulting Exception is difficult to debug. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
