Re: SpnegoAuthenticator feedback

2011-04-21 Thread Mark Thomas
On 20/04/2011 21:00, Filip Hanik - Dev Lists wrote:
> Here are some thoughts on the implementation

Thanks for the feedback.

> 1. |com.sun.security.jgss.initiate is not needed
> This definition is not needed in jaas.conf. Tomcat is not a client in
> this case, it's a server accepting tickets.
> the .initiate is only for clients that request a Kerberos ticket from
> the KDC.
> The example works fine removing this entry all together.

I think this will be required when we add support for using the server's
delegated credentials to connect to the directory to retrieve user
roles. I'll check this when I implement it and will remove it if I can.

> 2. com.sun.security.jgss.krb5.accept is not configurable
> While the authenticator has the attribute loginConfigName, there seems
> to be a place in the code where it omits this entry.
> renaming this entry in jaas.conf and setting the loginConfigName will
> fail to validate a ticket

Thanks. I'll add a BZ entry for this. I should be able to get to in in
time for 7.0.13 (unless someone beats me to it).

Mark

> 
> The problem code is here:
> 
> gssContext =
> manager.createContext(manager.createCredential(null,
> GSSCredential.DEFAULT_LIFETIME,
> new Oid("1.3.6.1.5.5.2"),
> GSSCredential.ACCEPT_ONLY));
> 
> should look like
> final GSSManager manager = GSSManager.getInstance();
> final PrivilegedExceptionAction action =
> new PrivilegedExceptionAction() {
> public GSSCredential run() throws GSSException {
> return manager.createCredential(null,
> GSSCredential.DEFAULT_LIFETIME,
> new Oid("1.3.6.1.5.5.2"),
> GSSCredential.ACCEPT_ONLY);
> }
> };
> gssContext =
> manager.createContext(Subject.doAs(lc.getSubject(), action));||
> 
> 
> best
> Filip
> |
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 




-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



DO NOT REPLY [Bug 51099] New: SPNEGO loginConfigName does not work

2011-04-21 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=51099

   Summary: SPNEGO loginConfigName does not work
   Product: Tomcat 7
   Version: trunk
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: ma...@apache.org


As reported by fhanik on the dev list:

2. com.sun.security.jgss.krb5.accept is not configurable
While the authenticator has the attribute loginConfigName, there seems to be a
place in the code where it omits this entry.
renaming this entry in jaas.conf and setting the loginConfigName will fail to
validate a ticket

The problem code is here:

gssContext = manager.createContext(manager.createCredential(null,
GSSCredential.DEFAULT_LIFETIME,
new Oid("1.3.6.1.5.5.2"),
GSSCredential.ACCEPT_ONLY));

should look like
final GSSManager manager = GSSManager.getInstance();
final PrivilegedExceptionAction action =
new PrivilegedExceptionAction() {
public GSSCredential run() throws GSSException {
return manager.createCredential(null,
GSSCredential.DEFAULT_LIFETIME,
new Oid("1.3.6.1.5.5.2"),
GSSCredential.ACCEPT_ONLY);
}
};
gssContext = manager.createContext(Subject.doAs(lc.getSubject(),
action));||


best
Filip

-- 
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



svn commit: r1095677 - in /tomcat/trunk/java/org/apache: catalina/users/MemoryUserDatabase.java tomcat/util/digester/AbstractObjectCreationFactory.java tomcat/util/digester/AbstractRulesImpl.java

2011-04-21 Thread markt
Author: markt
Date: Thu Apr 21 12:25:31 2011
New Revision: 1095677

URL: http://svn.apache.org/viewvc?rev=1095677&view=rev
Log:
Fix some unused code warnings

Removed:
tomcat/trunk/java/org/apache/tomcat/util/digester/AbstractRulesImpl.java
Modified:
tomcat/trunk/java/org/apache/catalina/users/MemoryUserDatabase.java

tomcat/trunk/java/org/apache/tomcat/util/digester/AbstractObjectCreationFactory.java

Modified: tomcat/trunk/java/org/apache/catalina/users/MemoryUserDatabase.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/users/MemoryUserDatabase.java?rev=1095677&r1=1095676&r2=1095677&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/users/MemoryUserDatabase.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/users/MemoryUserDatabase.java Thu Apr 
21 12:25:31 2011
@@ -36,8 +36,8 @@ import org.apache.catalina.UserDatabase;
 import org.apache.juli.logging.Log;
 import org.apache.juli.logging.LogFactory;
 import org.apache.tomcat.util.ExceptionUtils;
+import org.apache.tomcat.util.digester.AbstractObjectCreationFactory;
 import org.apache.tomcat.util.digester.Digester;
-import org.apache.tomcat.util.digester.ObjectCreationFactory;
 import org.apache.tomcat.util.res.StringManager;
 import org.xml.sax.Attributes;
 
@@ -683,7 +683,7 @@ public class MemoryUserDatabase implemen
 /**
  * Digester object creation factory for group instances.
  */
-class MemoryGroupCreationFactory implements ObjectCreationFactory {
+class MemoryGroupCreationFactory extends AbstractObjectCreationFactory {
 
 public MemoryGroupCreationFactory(MemoryUserDatabase database) {
 this.database = database;
@@ -722,26 +722,13 @@ class MemoryGroupCreationFactory impleme
 }
 
 private MemoryUserDatabase database = null;
-
-private Digester digester = null;
-
-@Override
-public Digester getDigester() {
-return (this.digester);
-}
-
-@Override
-public void setDigester(Digester digester) {
-this.digester = digester;
-}
-
 }
 
 
 /**
  * Digester object creation factory for role instances.
  */
-class MemoryRoleCreationFactory implements ObjectCreationFactory {
+class MemoryRoleCreationFactory extends AbstractObjectCreationFactory {
 
 public MemoryRoleCreationFactory(MemoryUserDatabase database) {
 this.database = database;
@@ -759,26 +746,13 @@ class MemoryRoleCreationFactory implemen
 }
 
 private MemoryUserDatabase database = null;
-
-private Digester digester = null;
-
-@Override
-public Digester getDigester() {
-return (this.digester);
-}
-
-@Override
-public void setDigester(Digester digester) {
-this.digester = digester;
-}
-
 }
 
 
 /**
  * Digester object creation factory for user instances.
  */
-class MemoryUserCreationFactory implements ObjectCreationFactory {
+class MemoryUserCreationFactory extends AbstractObjectCreationFactory {
 
 public MemoryUserCreationFactory(MemoryUserDatabase database) {
 this.database = database;
@@ -842,17 +816,4 @@ class MemoryUserCreationFactory implemen
 }
 
 private MemoryUserDatabase database = null;
-
-private Digester digester = null;
-
-@Override
-public Digester getDigester() {
-return (this.digester);
-}
-
-@Override
-public void setDigester(Digester digester) {
-this.digester = digester;
-}
-
 }

Modified: 
tomcat/trunk/java/org/apache/tomcat/util/digester/AbstractObjectCreationFactory.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/digester/AbstractObjectCreationFactory.java?rev=1095677&r1=1095676&r2=1095677&view=diff
==
--- 
tomcat/trunk/java/org/apache/tomcat/util/digester/AbstractObjectCreationFactory.java
 (original)
+++ 
tomcat/trunk/java/org/apache/tomcat/util/digester/AbstractObjectCreationFactory.java
 Thu Apr 21 12:25:31 2011
@@ -24,7 +24,8 @@ import org.xml.sax.Attributes;
  * Abstract base class for ObjectCreationFactory
  * implementations.
  */
-public abstract class AbstractObjectCreationFactory implements 
ObjectCreationFactory {
+public abstract class AbstractObjectCreationFactory
+implements ObjectCreationFactory {
 
 
 // - Instance Variables
@@ -34,7 +35,7 @@ public abstract class AbstractObjectCrea
  * The associated Digester instance that was set up by
  * {@link FactoryCreateRule} upon initialization.
  */
-protected Digester digester = null;
+private Digester digester = null;
 
 
 // - Public Methods
@@ -48,6 +49,7 @@ public abstract class AbstractObjectCrea
  *
  * @throws Exception any exception thrown will be propagated upwards
  */
+@Override
 public abstract Object createObject(Attribut

svn commit: r1095681 - /tomcat/trunk/webapps/docs/config/http.xml

2011-04-21 Thread markt
Author: markt
Date: Thu Apr 21 12:37:21 2011
New Revision: 1095681

URL: http://svn.apache.org/viewvc?rev=1095681&view=rev
Log:
Fix typo

Modified:
tomcat/trunk/webapps/docs/config/http.xml

Modified: tomcat/trunk/webapps/docs/config/http.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/http.xml?rev=1095681&r1=1095680&r2=1095681&view=diff
==
--- tomcat/trunk/webapps/docs/config/http.xml (original)
+++ tomcat/trunk/webapps/docs/config/http.xml Thu Apr 21 12:37:21 2011
@@ -267,7 +267,7 @@
 
 
   Controls when the socket used by the connector is bound. By default it
-  is bound when the connector is initiated and unbund when the connector is
+  is bound when the connector is initiated and unbound when the connector 
is
   destroyed. If set to false, the socket will be bound when 
the
   connector is started and unbound when it is stopped.
 



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



svn commit: r1095682 - /tomcat/trunk/webapps/docs/config/ajp.xml

2011-04-21 Thread markt
Author: markt
Date: Thu Apr 21 12:37:44 2011
New Revision: 1095682

URL: http://svn.apache.org/viewvc?rev=1095682&view=rev
Log:
bindOnInit is supported for AJP too.

Modified:
tomcat/trunk/webapps/docs/config/ajp.xml

Modified: tomcat/trunk/webapps/docs/config/ajp.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/ajp.xml?rev=1095682&r1=1095681&r2=1095682&view=diff
==
--- tomcat/trunk/webapps/docs/config/ajp.xml (original)
+++ tomcat/trunk/webapps/docs/config/ajp.xml Thu Apr 21 12:37:44 2011
@@ -268,6 +268,13 @@
   interface.
 
 
+
+  Controls when the socket used by the connector is bound. By default it
+  is bound when the connector is initiated and unbound when the connector 
is
+  destroyed. If set to false, the socket will be bound when 
the
+  connector is started and unbound when it is stopped.
+
+
 
   When client certificate information is presented in a form other than
   instances of java.security.cert.X509Certificate it needs to



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: bindOnInit and maxConnections for AJP connectors

2011-04-21 Thread Mark Thomas
On 05/04/2011 09:51, Tim Whittington wrote:
> In the AJP standard implementation docs, the following are not
> mentioned, although they're properties of AbstractEndpoint and
> probably should work:
> - bindOnInit
> - maxConnections
> Am I right in assuming these should be possible in the AJP connector
> (my reading of the code indicates they are - just wanted to check if
> something arcane was going on)?

If fixed the docs for bindOnInit

maxConnections is still TBD.

Mark

> If so I'll update the docs.
> 
> cheers
> tim
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 




-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



svn commit: r1095684 - /tomcat/trunk/java/org/apache/jasper/compiler/DefaultErrorHandler.java

2011-04-21 Thread markt
Author: markt
Date: Thu Apr 21 12:43:08 2011
New Revision: 1095684

URL: http://svn.apache.org/viewvc?rev=1095684&view=rev
Log:
Fix some Findbugs warnings

Modified:
tomcat/trunk/java/org/apache/jasper/compiler/DefaultErrorHandler.java

Modified: tomcat/trunk/java/org/apache/jasper/compiler/DefaultErrorHandler.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/DefaultErrorHandler.java?rev=1095684&r1=1095683&r2=1095684&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/DefaultErrorHandler.java 
(original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/DefaultErrorHandler.java Thu 
Apr 21 12:43:08 2011
@@ -72,7 +72,7 @@ class DefaultErrorHandler implements Err
 for (int i=0; i < details.length; i++) {
 if (details[i].getJspBeginLineNumber() >= 0) {
 args = new Object[] {
-new Integer(details[i].getJspBeginLineNumber()), 
+Integer.valueOf(details[i].getJspBeginLineNumber()), 
 details[i].getJspFileName() };
 buf.append("\n\n");
 buf.append(Localizer.getMessage("jsp.error.single.line.number",
@@ -83,7 +83,7 @@ class DefaultErrorHandler implements Err
 buf.append(details[i].getJspExtract());
 } else {
 args = new Object[] {
-new Integer(details[i].getJavaLineNumber()) };
+Integer.valueOf(details[i].getJavaLineNumber()) };
 buf.append("\n\n");
 buf.append(Localizer.getMessage("jsp.error.java.line.number",
 args));



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



svn commit: r1095686 - in /tomcat/trunk/java/org/apache/jasper: compiler/DefaultErrorHandler.java resources/LocalStrings.properties

2011-04-21 Thread markt
Author: markt
Date: Thu Apr 21 12:50:40 2011
New Revision: 1095686

URL: http://svn.apache.org/viewvc?rev=1095686&view=rev
Log:
i18n for r1090763

Modified:
tomcat/trunk/java/org/apache/jasper/compiler/DefaultErrorHandler.java
tomcat/trunk/java/org/apache/jasper/resources/LocalStrings.properties

Modified: tomcat/trunk/java/org/apache/jasper/compiler/DefaultErrorHandler.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/DefaultErrorHandler.java?rev=1095686&r1=1095685&r2=1095686&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/DefaultErrorHandler.java 
(original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/DefaultErrorHandler.java Thu 
Apr 21 12:50:40 2011
@@ -38,8 +38,10 @@ class DefaultErrorHandler implements Err
 @Override
 public void jspError(String fname, int line, int column, String errMsg,
 Exception ex) throws JasperException {
-throw new JasperException(fname + "(line: " + line + ", column: " +
-column + ")" + " " + errMsg, ex);
+throw new JasperException(fname + " (" +
+Localizer.getMessage("jsp.error.location",
+Integer.toString(line), Integer.toString(column)) +
+") " + errMsg, ex);
 }
 
 /*

Modified: tomcat/trunk/java/org/apache/jasper/resources/LocalStrings.properties
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/resources/LocalStrings.properties?rev=1095686&r1=1095685&r2=1095686&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/resources/LocalStrings.properties 
(original)
+++ tomcat/trunk/java/org/apache/jasper/resources/LocalStrings.properties Thu 
Apr 21 12:50:40 2011
@@ -336,6 +336,7 @@ jsp.error.needAlternateJavaEncoding=Defa
 jsp.error.single.line.number=An error occurred at line: {0} in the jsp file: 
{1}
 jsp.error.multiple.line.number=\n\nAn error occurred between lines: {0} and 
{1} in the jsp file: {2}\n\n
 jsp.error.java.line.number=An error occurred at line: {0} in the generated 
java file
+jsp.error.location=line: {0}, column {1}
 jsp.error.corresponding.servlet=Generated servlet error:\n
 jsp.error.empty.body.not.allowed=Empty body not allowed for {0}
 jsp.error.jspbody.required=Must use jsp:body to specify tag body for {0} if 
jsp:attribute is used.



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: svn commit: r1090763 - in /tomcat/trunk: java/org/apache/jasper/compiler/DefaultErrorHandler.java webapps/docs/changelog.xml

2011-04-21 Thread Mark Thomas
On 10/04/2011 16:06, Konstantin Kolinko wrote:
> 2011/4/10  :
>> Author: markt
>> Date: Sun Apr 10 10:33:30 2011
>> New Revision: 1090763
>>
>> URL: http://svn.apache.org/viewvc?rev=1090763&view=rev
>> Log:
>> Improve error reporting by labeling line/column numbers
> 
> This contradicts with i18n of errMsg.
> 
> If you are making this more human-readable, maybe add a whitespace
> before "(" in "(line"

Fixed. Thanks for the review.

Mark



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: svn commit: r1094069 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/ha/session/ java/org/apache/catalina/manager/ java/org/apache/catalina/session/ webapps/docs/

2011-04-21 Thread Mark Thomas
On 19/04/2011 16:27, Filip Hanik - Dev Lists wrote:
> 
> 
> On 4/18/2011 4:39 AM, Mark Thomas wrote:
>> On 18/04/2011 10:13, Remy Maucherat wrote:
>>> On Sat, 2011-04-16 at 22:25 +, ma...@apache.org wrote:
 Author: markt
 Date: Sat Apr 16 22:25:28 2011
 New Revision: 1094069

 URL: http://svn.apache.org/viewvc?rev=1094069&view=rev
 Log:
 Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=51042
 Don't trigger session creation listeners when changing the session
 ID during authentication.
>>> But the listeners have to be aware that the id changed.
>> Why? I have checked the Servlet spec and I don't see any event defined
>> for "session ID changed". I also don't see anything (although I may have
>> missed it) that says the ID must be constant.
> 
> Every logical application that uses the ID as a key, would like to know
> that the ID has changed since the key is no longer valid. Those apps
> would rely on some sort event that the key is no longer there.
> regardless of what the servlet spec says, it's seems logical.

That raises the question of what event to fire. The session lifecycle
events are for when An HttpSession has been created,
invalidated, or timed out.. None of those apply in this
case. Hence my leaning towards the view that no event should be fired.
If this causes an issue for an application, it can always disable the
session fixation protection and provide their own alternative protection.

I assume that you are suggesting that the session invalidated + session
created events are used, but as I said before, if those events are fired
then the object binding and attribute change events should also be
fired. I can see firing all these additional events being more likely to
cause problems for applications that just a change of the session ID.

Mark



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



svn commit: r1095711 - in /tomcat/trunk/webapps/docs/config: ajp.xml http.xml

2011-04-21 Thread markt
Author: markt
Date: Thu Apr 21 13:52:39 2011
New Revision: 1095711

URL: http://svn.apache.org/viewvc?rev=1095711&view=rev
Log:
Move the maxConnections description to the correct part of the HTTP doc. Add it 
to the AJP doc.

Modified:
tomcat/trunk/webapps/docs/config/ajp.xml
tomcat/trunk/webapps/docs/config/http.xml

Modified: tomcat/trunk/webapps/docs/config/ajp.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/ajp.xml?rev=1095711&r1=1095710&r2=1095711&view=diff
==
--- tomcat/trunk/webapps/docs/config/ajp.xml (original)
+++ tomcat/trunk/webapps/docs/config/ajp.xml Thu Apr 21 13:52:39 2011
@@ -379,10 +379,18 @@
 
   
 
-The BIO implementation supports the following Java TCP socket attributes
-in addition to the common Connector and AJP attributes listed above.
+The BIO implementation supports the following attributes in addition to
+the common Connector and AJP attributes listed above.
   
 
+  
+The maximum number of connections that the server will accept and
+process at any given time. When this number has been reached, the 
server
+will not accept any more connections until the number of connections
+falls below this value. The operating system may still accept
+connections based on the acceptCount setting. Default 
value
+is 1.
+  
   
 (int)The socket receive buffer (SO_RCVBUF) size in bytes. JVM 
default
 used if not set.

Modified: tomcat/trunk/webapps/docs/config/http.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/http.xml?rev=1095711&r1=1095710&r2=1095711&view=diff
==
--- tomcat/trunk/webapps/docs/config/http.xml (original)
+++ tomcat/trunk/webapps/docs/config/http.xml Thu Apr 21 13:52:39 2011
@@ -373,15 +373,6 @@
   execute tasks using the executor rather than an internal thread pool.
 
 
-
-  The maximum number of connections that the server will accept and 
process
-  at any given time. When this number has been reached, the server will 
not accept any more
-  connections until the number of connections reach below this value. The 
operating system may still accept connections based 
-  on the acceptCount setting.
-  This setting is currently only applicable to the blocking Java 
connectors (AJP/HTTP).
-  Default value is 1.
-
-
 
   Limits the total length of trailing headers in the last chunk of
   a chunked HTTP request. If the value is -1, no limit will be
@@ -554,8 +545,21 @@
   
   
 
-There are no BIO specific configuration settings.
+The following attributes are specific to the BIO connector.
 
+
+
+  
+The maximum number of connections that the server will accept and
+process at any given time. When this number has been reached, the 
server
+will not accept any more connections until the number of connections
+falls below this value. The operating system may still accept
+connections based on the acceptCount setting. Default 
value
+is 1.
+  
+
+
+
   
   
   



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



svn commit: r1095712 - /tomcat/trunk/webapps/docs/config/http.xml

2011-04-21 Thread markt
Author: markt
Date: Thu Apr 21 13:54:17 2011
New Revision: 1095712

URL: http://svn.apache.org/viewvc?rev=1095712&view=rev
Log:
Update summary for maxConnections

Modified:
tomcat/trunk/webapps/docs/config/http.xml

Modified: tomcat/trunk/webapps/docs/config/http.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/http.xml?rev=1095712&r1=1095711&r2=1095712&view=diff
==
--- tomcat/trunk/webapps/docs/config/http.xml (original)
+++ tomcat/trunk/webapps/docs/config/http.xml Thu Apr 21 13:54:17 2011
@@ -1172,7 +1172,7 @@
 Write HTTP Response   Blocking   Sim Blocking  
  Blocking
 SSL Support   Java SSL Java SSL
  OpenSSL
 SSL Handshake Blocking   Non blocking  
  Blocking
-Max Connections  maxThreadsSee polling size
  See polling size
+Max ConnectionsmaxConnections  See polling size
  See polling size
 
 
 



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: SpnegoAuthenticator feedback

2011-04-21 Thread Filip Hanik - Dev Lists

On 4/21/2011 3:09 AM, Mark Thomas wrote:

On 20/04/2011 21:00, Filip Hanik - Dev Lists wrote:

Here are some thoughts on the implementation

Thanks for the feedback.


1. |com.sun.security.jgss.initiate is not needed
This definition is not needed in jaas.conf. Tomcat is not a client in
this case, it's a server accepting tickets.
the .initiate is only for clients that request a Kerberos ticket from
the KDC.
The example works fine removing this entry all together.

I think this will be required when we add support for using the server's
delegated credentials to connect to the directory to retrieve user
roles. I'll check this when I implement it and will remove it if I can.

yes, if you want tomcat to act as a client.
Acting like a client will mean a few different things, like
- configuring the module name for the client
- I'm pretty sure the configuration will be different here, you should not need 
a keytab or principal, you're a client in this case.



2. com.sun.security.jgss.krb5.accept is not configurable
While the authenticator has the attribute loginConfigName, there seems
to be a place in the code where it omits this entry.
renaming this entry in jaas.conf and setting the loginConfigName will
fail to validate a ticket

Thanks. I'll add a BZ entry for this. I should be able to get to in in
time for 7.0.13 (unless someone beats me to it).


much appreciated
Filip



Mark


The problem code is here:

 gssContext =
manager.createContext(manager.createCredential(null,
 GSSCredential.DEFAULT_LIFETIME,
 new Oid("1.3.6.1.5.5.2"),
 GSSCredential.ACCEPT_ONLY));

should look like
 final GSSManager manager = GSSManager.getInstance();
 final PrivilegedExceptionAction  action =
 new PrivilegedExceptionAction() {
 public GSSCredential run() throws GSSException {
 return manager.createCredential(null,
 GSSCredential.DEFAULT_LIFETIME,
 new Oid("1.3.6.1.5.5.2"),
 GSSCredential.ACCEPT_ONLY);
 }
 };
 gssContext =
manager.createContext(Subject.doAs(lc.getSubject(), action));||


best
Filip
|

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1321 / Virus Database: 1500/3586 - Release Date: 04/20/11





-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



DO NOT REPLY [Bug 50642] keepAliveProtection doesn't work

2011-04-21 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=50642

--- Comment #8 from Dennis Homann  2011-04-21 
14:10:05 EDT ---
The issue is still present in 6.0.32. In more than 50% of my attempts, the
KeepAliveThread is not cleared correctly. Debugging and profiling showed that
in these cases, the Thread object is still kept around, even though the thread
was no longer active. In that case, ThreadGroup#enumerate does not even list it
(WebappClassLoader#getThreads), although it's still shown in the profiler
(YourKit in my case) and holds a reference to the WebappClassLoader. Even if it
was listed by enumerate, WebappClassLoader#clearReferencesThreads would skip it
as it is not alive.

-- 
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



svn commit: r1095794 - in /tomcat/trunk: java/org/apache/coyote/http11/Http11Processor.java webapps/docs/changelog.xml

2011-04-21 Thread markt
Author: markt
Date: Thu Apr 21 19:02:46 2011
New Revision: 1095794

URL: http://svn.apache.org/viewvc?rev=1095794&view=rev
Log:
Fix TODO - take account of time waiting for a thread when calculating timeouts.

Modified:
tomcat/trunk/java/org/apache/coyote/http11/Http11Processor.java
tomcat/trunk/webapps/docs/changelog.xml

Modified: tomcat/trunk/java/org/apache/coyote/http11/Http11Processor.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/Http11Processor.java?rev=1095794&r1=1095793&r2=1095794&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/Http11Processor.java (original)
+++ tomcat/trunk/java/org/apache/coyote/http11/Http11Processor.java Thu Apr 21 
19:02:46 2011
@@ -17,6 +17,7 @@
 
 package org.apache.coyote.http11;
 
+import java.io.EOFException;
 import java.io.IOException;
 import java.io.InterruptedIOException;
 import java.net.InetAddress;
@@ -184,15 +185,48 @@ public class Http11Processor extends Abs
 
 // Parsing the request header
 try {
-//TODO - calculate timeout based on length in queue 
(System.currentTimeMills() - wrapper.getLastAccess() is the time in queue)
+int standardTimeout = 0;
 if (keptAlive) {
 if (keepAliveTimeout > 0) {
-socket.getSocket().setSoTimeout(keepAliveTimeout);
+standardTimeout = keepAliveTimeout;
+} else if (soTimeout > 0) {
+standardTimeout = soTimeout;
 }
-else if (soTimeout > 0) {
-socket.getSocket().setSoTimeout(soTimeout);
+}
+/*
+ * When there is no data in the buffer and this is not the 
first
+ * request on this connection and timeouts are being used the
+ * first read for this request may need a different timeout to
+ * take account of time spent waiting for a processing thread.
+ * 
+ * This is a little hacky but better than exposing the socket
+ * and the timeout info to the InputBuffer
+ */
+if (inputBuffer.lastValid == 0 &&
+socketWrapper.getLastAccess() > -1 &&
+standardTimeout > 0) {
+
+long queueTime = System.currentTimeMillis() -
+socketWrapper.getLastAccess();
+int firstReadTimeout;
+if (queueTime >= standardTimeout) {
+// Queued for longer than timeout but there might be
+// data so use shortest possible timeout
+firstReadTimeout = 1;
+} else {
+// Cast is safe since queueTime must be less than
+// standardTimeout which is an int
+firstReadTimeout = standardTimeout - (int) queueTime;
+}
+socket.getSocket().setSoTimeout(firstReadTimeout);
+if (!inputBuffer.fill()) {
+throw new EOFException(sm.getString("iib.eof.error"));
 }
 }
+if (standardTimeout > 0) {
+socket.getSocket().setSoTimeout(standardTimeout);
+}
+
 inputBuffer.parseRequestLine(false);
 if (endpoint.isPaused()) {
 // 503 - Service unavailable

Modified: tomcat/trunk/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1095794&r1=1095793&r2=1095794&view=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Thu Apr 21 19:02:46 2011
@@ -111,6 +111,11 @@
 information was also added to the documentation on how to select an
 appropriate value. 
   
+  
+Take account of time spent waiting for a processing thread when
+calculating connection and keep-alive timeouts for the HTTP BIO
+connector. (markt)
+  
 
   
   



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: bindOnInit and maxConnections for AJP connectors

2011-04-21 Thread Mark Thomas
On 06/04/2011 22:51, Tim Whittington wrote:
> On Wed, Apr 6, 2011 at 11:16 PM, Mark Thomas  wrote:
>> On 05/04/2011 10:50, Tim Whittington wrote:
>>> Is what's actually going on more like:
>>>
>>> APR: use maxConnections == pollerSize (smallest will limit, but if
>>> pollerSize < maxConnections then the socket backlog effectively won't
>>> be used as the poller will keep killing connections as they come in)
>>>
>>> NIO: use maxConnections to limit 'poller size'
>>>
>>> HTTP: use maxConnections. For keep alive situations, reduce
>>> maxConnections to something closer to maxThreads (the default config
>>> is 10,000 keepalive connections serviced by 200 threads with a 60
>>> second keepalive timeout, which could lead to some large backlogs of
>>> connected sockets that take 50 minutes to get serviced)

This is still an issue. I'm still thinking about how to address it. My
current thinking is:
- BIO: Introduce simulated polling using a short timeout (see below)
- NIO: Leave as is
- APR: Make maxConnections and pollerSize synonyms
- All: Make the default for maxConnections 8192 so it is consistent with
the current APR default.

The other option is dropping maxConnections entirely from the NIO and
APR connectors. That would align the code with the docs. The only
downside is that the NIO connector would no longer have an option to
limit the connections. I'm not sure that is much of an issue since I
don't recall any demands for such a limit from the user community.

>> There are a number of issues with the current BIO implementation.
>>
>> 1. Keep-alive timeouts
Fixed.

>> 2. The switch to a queue does result in the possibility of requests with
>> data being delayed by requests without data in keep-alive.
Still TODO.

>> 3. HTTP pipe-lining is broken (this is bug 50957 [1]).
Fixed.

>> The fix for issue 2 is tricky. The fundamental issue is that to resolve
>> it and to keep maxConnections >> maxThreads we need NIO like behaviour
>> from a BIO socket which just isn't possible.
>> Fixing 1 will reduce the maximum length of delay that any one request
>> might experience which will help but that won't address the fundamental
>> issue.
>> For sockets in keepalive, I considered trying to fake NIO behaviour by
>> using a read with a timeout of 1ms, catching the SocketTimeoutException
>> and returning them to the back of the queue if there is no data. The
>> overhead of that looks to be around 2-3ms for a 1ms timeout. I'm worried
>> about CPU usage but for a single thread this doesn't seem to be
>> noticeable. More testing with multiple threads is required. The timeout
>> could be tuned by looking at the current number of active threads, size
>> of the queue etc. but it is an ugly hack.
>> Returning to the pre [3] approach of disabling keep-alive once
>> connections > 75% of threads would fix this at the price of no longer
>> being able to support maxConnections >> maxThreads.
> 
> 
> Yeah, I went down this track as well before getting to the "Just use
> APR/NIO" state of mind.
> It is an ugly hack, but might be workable if the timeout is large
> enough to stop it being a busy loop on the CPU.
> With 200 threads, even a 100ms timeout would give you a 'reasonable' 
> throughput.
> Even if we do this, I still think maxConnections should be somewhat
> closer to maxThreads than it is now if the BIO connector is being
> used.

We can make the timeout configurable but 100ms shouldn't be too bad. I
have a simple, scaled-down test case and this approach looks good in
terms of throughput but there are a few kinks I need to iron out. Also
the CPU usage looked rather high, although that might be a side-effect
of one of the kinks. If the issues can't be ironed out then we'll need a
major rethink about this - probably heading back towards a TC6 style
solution.

Mark



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: svn commit: r1095794 - in /tomcat/trunk: java/org/apache/coyote/http11/Http11Processor.java webapps/docs/changelog.xml

2011-04-21 Thread Filip Hanik - Dev Lists

On 4/21/2011 1:02 PM, ma...@apache.org wrote:

+int firstReadTimeout;
+if (queueTime>= standardTimeout) {
+// Queued for longer than timeout but there might be
+// data so use shortest possible timeout
+firstReadTimeout = 1;
+} else {
+// Cast is safe since queueTime must be less than
+// standardTimeout which is an int
+firstReadTimeout = standardTimeout - (int) queueTime;
+}
+socket.getSocket().setSoTimeout(firstReadTimeout);
+if (!inputBuffer.fill()) {
+throw new EOFException(sm.getString("iib.eof.error"));
  }
  }
+if (standardTimeout>  0) {
+socket.getSocket().setSoTimeout(standardTimeout);
+}
+
  inputBuffer.parseRequestLine(false);
not fully understanding the logic here. But if you ever run into a case where standardTimeout=0 and firstReadTimeout=1, then you'd have 1 
millisecond timeout for the parse request line. And the request line, typically comes in one packet, but it is legal to send it up in two. 
And you'd have an invalid SocketTimeoutException here, since 1 is no longer the correct timeout.




-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org