Re: Handling requests when under load - ACCEPT and RST vs non-ACCEPT

2012-11-01 Thread Asankha C. Perera

Hi Chris

I was connecting locally to the same node over the local interface on 
both EC2 and locally.


Since this went unresolved for sometime now for me, I investigated this 
a bit myself, first looking at the Coyote source code, and then 
experimenting with plain Java sockets. It seems like the issue is not 
really Tomcat resetting connections by itself, but rather; letting the 
underlying OS do it. It seems like it could be a but difficult to 
prevent this with blocking sockets, but I hope what I've found 
investigating this issue will help others in future


http://esbmagic.blogspot.com/2012/10/does-tomcat-bite-more-than-it-can-chew.html

regards
asankha

On 10/31/2012 09:27 PM, Christopher Schultz wrote:

Also, are you using a load balancer, or connecting directly to the EC2
instance? Do you have a public, static IP? If you use a static IP,
Amazon proxies your connections. I'm not sure what happens if you use
a non-static IP (which are public, but can change).


--
Asankha C. Perera
AdroitLogic, http://adroitlogic.org

http://esbmagic.blogspot.com




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



Re: context.xml - how to escape a double quote in an attribute value

2012-11-01 Thread Daniel Mikusa
On Nov 1, 2012, at 11:32 AM, Campbell, Lance wrote:

 In a context.xml file in a Resource I need a value of an attribute to 
 contain a double quote.  Is there any way to escape a double quote so it will 
 work as a value in an attribute?

Have you tried quot;?

Dan


  
  
 Thanks,
  
 Lance Campbell
 Software Architect
 Web Services at Public Affairs
 217-333-0382
 
  
  


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



Problem with JAASMemoryLoginModule?

2012-11-01 Thread Jim Doble
I am experimenting with JAAS on Tomcat 7.0.30 and am trying to use 
JAASMemoryLoginModule as a simple test. Unfortunately, I am getting a 
null pointer exception when I try to login to my web application.


My tomcat-users.xml file is basically equivalent to:

tomcat-users

 role rolename=role1/
 role rolename=role2/

 user username=user1 password=password1 roles=role1/
 user username=user2 password=password2 roles=role1, role2/

/tomcat-users


My jaas.config file is trivial as well:

Catalina {
org.apache.catalina.realm.JAASMemoryLoginModule REQUIRED debug=true;
};

My realm element is nested inside an engine element in server.xml:

Realm className=org.apache.catalina.realm.JAASRealm
 userClassNames=org.apache.catalina.realm.GenericPrincipal
 roleClassNames=org.apache.catalina.realm.GenericPrincipal/

The stack trace for my exception is as follows:

java.lang.NullPointerException
   at java.lang.String.compareTo(String.java:1167)
   at java.lang.String.compareTo(String.java:92)
   at java.util.Arrays.mergeSort(Arrays.java:1144)
   at java.util.Arrays.sort(Arrays.java:1079)
   at 
org.apache.catalina.realm.GenericPrincipal.init(GenericPrincipal.java:134)
   at 
org.apache.catalina.realm.GenericPrincipal.init(GenericPrincipal.java:106)
   at 
org.apache.catalina.realm.JAASRealm.createPrincipal(JAASRealm.java:556)
   at 
org.apache.catalina.realm.JAASRealm.authenticate(JAASRealm.java:441)
   at 
org.apache.catalina.realm.JAASRealm.authenticate(JAASRealm.java:332)
   at 
org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:295)
   at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:450)
   at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
   at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
   at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)
   at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
   at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
   at 
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)
   at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)
   at 
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
   at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

   at java.lang.Thread.run(Thread.java:619)

This exception is occurring when we are trying to construct a new 
GenericPrincipal instance at the end of the createPrincipal method in 
the org.apache.catalina.realm.JAASRealm class.


   // Return the resulting Principal for our authenticated user

   return new GenericPrincipal(username, null, roles, userPrincipal, 
loginContext);


The roles argument is a list of Strings taken from the names of role 
principals, as shown in this snippet from the same method:


   if (roleClasses.contains(principalClass)) {

   roles.add(principal.getName());

   if( log.isDebugEnabled() ) {
   log.debug(sm.getString(jaasRealm.rolePrincipalAdd, 
principal.getName()));

   }
   }

The problem is that in the commit method of the 
org.apache.catalina.realm.JAASMemoryLoginModule class, role principals 
are added to the subject with the name set to null, as shown below 
(note: the first argument to the GenericPrincipal constructor is the name).


   public boolean commit() throws LoginException {

   log.debug(commit  + principal);
  
   // If authentication was not successful, just return false


   if (principal == null)
   return (false);

   // Add our Principal to the Subject if needed

   if (!subject.getPrincipals().contains(principal)) {

   subject.getPrincipals().add(principal);

   // Add the roles as additional subjects as per the contract 
with the JAASRealm


   if (principal instanceof GenericPrincipal) {

   String roles[] = ((GenericPrincipal) principal).getRoles();

   for (int i = 0; i  roles.length; i++) {

   // ** Here is the line that I think may be 
wrong ***
   subject.getPrincipals().add(new 
GenericPrincipal(null, roles[i], null));

   }
   }
   }

   committed = true;

   return (true);
   }

As a result, the roles list in the createPrincipal method in the 
org.apache.catalina.realm.JAASRealm class (see above) contains a number 
of null Strings, which leads to a null pointer exception in the 
GenericPrincipal constructor, when it calls Arrays.sort, as shown below.


   public GenericPrincipal(String name, String password, ListString 
roles, 

RE: Handling requests when under load - ACCEPT and RST vs non-ACCEPT

2012-11-01 Thread Esmond Pitt
Asankha

What you are looking at is TCP platform-dependent behaviour. There is a
'backlog' queue of inbound connections that have been completed by the TCP
stack but not yet accepted by the application via the accept() API. This is
the queue whose length is specified in the 'C' listen() method (although the
platform is free to adjust it either up or down, and generally does so).
When the backlog queue fills, the behaviour for subsequent incoming
connections is platform-dependent: 

(a) Windows sends an RST
(b) other platforms ignore the incoming connection, in the hope that the
backlog will clear and the client will try again.

An RST sent because the backlog queue is full is indistinguishable from an
RST sent because there is nothing listening at that port, so in either case
you should get 'connection refused' or possibly 'connection reset by peer'.
Failure to reply at all is indistinguisable from a lost packet, so TCP
should retry it a few times before timing out and giving a 'connection
timeout'.

Whether Windows is correct in sending an RST is debatable but it's been
doing it for decades and it certainly isn't going to change. 

Tomcat and indeed Java have nothing to do with this behaviour, and expecting
either to be modified to 'fix' it would be like keeping a dog and barking
yourself.

EJP


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



nsapi connector 1.2.37 build fails on Solaris 9 Sparc

2012-11-01 Thread Vladimir Liapko

Hi,

 
I am getting error during linking

ld: fatal: relocations remain against allocatable but 
non-writable sections
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target 
`nsapi_redirector.so'
 
The server I compile on is 
Solaris 9, sparc. Connector version 1.2.37
I was able to compile on linux, but need it on Solaris 9 sparc as well. Any 
ideas, please?

 

$make -f Makefile.solaris  comp.log 
21


gcc 
-DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX -DMCC_HTTPD -DSPAPI20 -DJK_NSAPI 
-DHAVE_CONFIG_H -I../common -I/apps/sun/we
pps/sun/web/plugins/include/base 
-I/apps/sun/web/plugins/include/frame -c ../common/ap_snprintf.c
gcc 
-DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX -DMCC_HTTPD -DSPAPI20 -DJK_NSAPI 
-DHAVE_CONFIG_H -I../common -I/apps/sun/we
pps/sun/web/plugins/include/base 
-I/apps/sun/web/plugins/include/frame -c ../common/jk_md5.c
gcc 
-DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX -DMCC_HTTPD -DSPAPI20 -DJK_NSAPI 
-DHAVE_CONFIG_H -I../common -I/apps/sun/we
pps/sun/web/plugins/include/base 
-I/apps/sun/web/plugins/include/frame -c ../common/jk_ajp12_worker.c
gcc 
-DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX -DMCC_HTTPD -DSPAPI20 -DJK_NSAPI 
-DHAVE_CONFIG_H -I../common -I/apps/sun/we
pps/sun/web/plugins/include/base 
-I/apps/sun/web/plugins/include/frame -c ../common/jk_msg_buff.c
gcc 
-DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX -DMCC_HTTPD -DSPAPI20 -DJK_NSAPI 
-DHAVE_CONFIG_H -I../common -I/apps/sun/we
pps/sun/web/plugins/include/base 
-I/apps/sun/web/plugins/include/frame -c ../common/jk_ajp13.c
gcc 
-DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX -DMCC_HTTPD -DSPAPI20 -DJK_NSAPI 
-DHAVE_CONFIG_H -I../common -I/apps/sun/we
pps/sun/web/plugins/include/base 
-I/apps/sun/web/plugins/include/frame -c ../common/jk_ajp13_worker.c
gcc 
-DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX -DMCC_HTTPD -DSPAPI20 -DJK_NSAPI 
-DHAVE_CONFIG_H -I../common -I/apps/sun/we
pps/sun/web/plugins/include/base 
-I/apps/sun/web/plugins/include/frame -c ../common/jk_pool.c
gcc 
-DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX -DMCC_HTTPD -DSPAPI20 -DJK_NSAPI 
-DHAVE_CONFIG_H -I../common -I/apps/sun/we
pps/sun/web/plugins/include/base 
-I/apps/sun/web/plugins/include/frame -c ../common/jk_ajp14.c
gcc 
-DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX -DMCC_HTTPD -DSPAPI20 -DJK_NSAPI 
-DHAVE_CONFIG_H -I../common -I/apps/sun/we
pps/sun/web/plugins/include/base 
-I/apps/sun/web/plugins/include/frame -c ../common/jk_shm.c
gcc 
-DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX -DMCC_HTTPD -DSPAPI20 -DJK_NSAPI 
-DHAVE_CONFIG_H -I../common -I/apps/sun/we
pps/sun/web/plugins/include/base 
-I/apps/sun/web/plugins/include/frame -c ../common/jk_ajp14_worker.c
gcc 
-DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX -DMCC_HTTPD -DSPAPI20 -DJK_NSAPI 
-DHAVE_CONFIG_H -I../common -I/apps/sun/we
pps/sun/web/plugins/include/base 
-I/apps/sun/web/plugins/include/frame -c ../common/jk_sockbuf.c
gcc 
-DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX -DMCC_HTTPD -DSPAPI20 -DJK_NSAPI 
-DHAVE_CONFIG_H -I../common -I/apps/sun/we
pps/sun/web/plugins/include/base 
-I/apps/sun/web/plugins/include/frame -c ../common/jk_ajp_common.c
gcc 
-DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX -DMCC_HTTPD -DSPAPI20 -DJK_NSAPI 
-DHAVE_CONFIG_H -I../common -I/apps/sun/we
pps/sun/web/plugins/include/base 
-I/apps/sun/web/plugins/include/frame -c ../common/jk_status.c
gcc 
-DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX -DMCC_HTTPD -DSPAPI20 -DJK_NSAPI 
-DHAVE_CONFIG_H -I../common -I/apps/sun/we
pps/sun/web/plugins/include/base 
-I/apps/sun/web/plugins/include/frame -c ../common/jk_connect.c
gcc 
-DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX -DMCC_HTTPD -DSPAPI20 -DJK_NSAPI 
-DHAVE_CONFIG_H -I../common -I/apps/sun/we
pps/sun/web/plugins/include/base 
-I/apps/sun/web/plugins/include/frame -c 
../common/jk_uri_worker_map.c
gcc 
-DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX -DMCC_HTTPD -DSPAPI20 -DJK_NSAPI 
-DHAVE_CONFIG_H -I../common -I/apps/sun/we
pps/sun/web/plugins/include/base 
-I/apps/sun/web/plugins/include/frame -c ../common/jk_context.c
gcc 
-DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX -DMCC_HTTPD -DSPAPI20 -DJK_NSAPI 
-DHAVE_CONFIG_H -I../common -I/apps/sun/we
pps/sun/web/plugins/include/base 
-I/apps/sun/web/plugins/include/frame -c ../common/jk_url.c
gcc 
-DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX -DMCC_HTTPD -DSPAPI20 -DJK_NSAPI 
-DHAVE_CONFIG_H -I../common -I/apps/sun/we
pps/sun/web/plugins/include/base 
-I/apps/sun/web/plugins/include/frame -c ../common/jk_util.c
gcc 
-DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX -DMCC_HTTPD -DSPAPI20 -DJK_NSAPI 
-DHAVE_CONFIG_H -I../common -I/apps/sun/we
pps/sun/web/plugins/include/base 
-I/apps/sun/web/plugins/include/frame -c ../common/jk_lb_worker.c
gcc 
-DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX -DMCC_HTTPD -DSPAPI20 -DJK_NSAPI 
-DHAVE_CONFIG_H -I../common -I/apps/sun/we
pps/sun/web/plugins/include/base 
-I/apps/sun/web/plugins/include/frame -c ../common/jk_worker.c
gcc 
-DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX -DMCC_HTTPD -DSPAPI20 -DJK_NSAPI