"Too many open files" but what are they?

java.io.FileNotFoundException: /opt/tb55/s3/conf/web.xml (Too many open files) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.<init>(FileInputStream.java:106)

this shows the open file limit has been reached.. you can check this by JMX

java.lang:type=OperatingSystem >  OpenFileDescriptorCount

but what are these files ? you can see this by linux shell script

lsof -u tomcat

solution: increase systems open file limit !!!

vi /etc/security/limits.conf

and edit the line to increase open file limit

* soft nofile 3072
* hard nofile 4048

Clustering Acegi

Acegi is a well known security framework. Some really good features:

• method level based security configuration
• url level auth configuration
• easy login mechanism
• so on.

But there only one point that is missing in current version (1.0.3) distributable SessionRegistry, in fact there is one implemantion to this interface but it do not support multiple JVM.This is used for concurrent access with username.

Quick Fix:
replace the Maps in SessionRegistryImpl with your distributable caching mechanism (can be ehcache,oscache,vs) and reimplement it. Or you can use some JMS mechanism to fix this cap but it should be used only in complex architectures.

Acegi Concurrent Setup:

<bean id=" org.acegisecurity.concurrent.SessionRegistry" class="org.acegisecurity.concurrent.SessionRegistryImpl"/> <bean id="org.acegisecurity.concurrent.ConcurrentSessionController" class="org.acegisecurity.concurrent.ConcurrentSessionControllerImpl"> <property name="maximumSessions"> <value>1</value> </property> <property name="sessionRegistry"> <ref local="org.acegisecurity.concurrent.SessionRegistry"/> </property> <property name="sessionRegistry" ref="org.acegisecurity.concurrent.SessionRegistry"/> </bean> <bean id="org.acegisecurity.AuthenticationManager" class="org.acegisecurity.providers.ProviderManager "> <property name="providers"> <list> <ref local="org.acegisecurity.providers.dao.DaoAuthenticationProvider"/> <ref local="org.acegisecurity.providers.anonymous.AnonymousAuthenticationProvider"/> </list> </property> <property name="sessionController" ref="org.acegisecurity.concurrent.ConcurrentSessionController "/> </bean> <bean id="org.acegisecurity.concurrent.ConcurrentSessionFilter" class="org.acegisecurity.concurrent.ConcurrentSessionFilter "> <property name="sessionRegistry" ref="org.acegisecurity.concurrent.SessionRegistry"/> <property name="expiredUrl" value="/myself/"/> </bean>




And add org.acegisecurity.concurrent.ConcurrentSessionFilter to your filter list

PS:
check my new blog Clustering Acegi via JGroups (DistributedHashtable)

when do not generate code !

     Currently code generation is very common way of some handling common repeating code fragments and some initial setup task like startup configurations and so on. Some clear benefits are:

• ease your setup process
  
• protects your code form some common coding mistakes
  
• maintain some coding pattern practices and standards.
• keep your effort on complex tasks

But on the other hand when you evaluate code generator or while writing your code should thing about " why you generate this code ? and not writing some generic component to evolute such business"
 this is the most common mistake while using this technology. you generate code to customize the generated code. If you not need this fragment to customization. DO NOT GENERATE IT. otherwise in most case any enhancement in these fragments will require great effort or worse (to generate again).

so what is important.

• more less code generated more perfect it is
• more easily you customize it more useful it is

Some code generators:
http://www.codegeneration.net/