Questions[glassfish](server)

I am hosting a web app on amazon aws, using an ec2 instance.

On that instance i will be running only one application. using glassfish v3.0.1

I do not want to run the app using :

www.mydomain.com:8080 or www.mydomain.com:8181 

I just want to use :

www.mydomain.com or https://www.mydomain.com

so i changed the http-listener-1 and http-listener-2 on glassfish to run on ports (respectively) 80 and 443.

Is this considered bad practice? i'm a software engineer and I usually do not deal with server admin stuff thus not too experienced in those things.

thanks for any guidance.

Our server recently ran out of file descriptors, and in regards to that I have some questions. ulimit -n is supposed to give me the maximum number of open file descriptors. That number is 1024. I checked the number of open file descriptors by running lsof -u root |wc -l and got 2500 fds. That is a lot more than 1024, so I guessed that would mean the number 1024 is per process, not per user, as I though. Well, I ran lsof -p$PidOfGlassfish|wc -l and got 1300. This is the part I don't get. If ulimit -n is not the maximum number of processes per user or per process, then what is it good for? Does it not apply to the root user? And if so, how could I then get the error messages about running out of file descriptor?

EDIT: The only way I can make sense out of ulimit -n is if it applies the the number of open files (as stated in the bash manual) rather than the number of file handles (different processes can open the same file). If this is the case, then simply listing the number of open files (grepping on '/', thus excluding memory mapped files) is not sufficent:

lsof -u root |grep /|sort  -k9  |wc -l #prints '1738'

To actually see the number of open files, I would need to filter on the name column on only print the unique entries. Thus the following is probably more correct:

lsof -u root |grep /|sort  -k9 -u |wc -l #prints '604'

The command above expects output on the following format from lsof:

java      32008 root  mem       REG                8,2 11942368      72721 /usr/lib64/locale/locale-archive
vmtoolsd   4764 root  mem       REG                8,2    18624     106432 /usr/lib64/open-vm-tools/plugins/vmsvc/libguestInfo.so

This at least gives me number less than 1024 (the number reported by ulimit -n), so this seems like a step in the right direction. "Unfortunately" I am not experiencing any problems with running out of file descriptors, so I will have a hard time validating this.

I'm primarily a Java developer, and I come to you with a question that straddles the divide between developers and sysadmins.

Years ago, when it was a novel thing to run Tomcat as an app server, it was customary to front it with Apache. As I understand it, this was done because:

1. Java was considered "slow", and it was helpful to have Apache serve static content directly.
2. Tomcat couldn't listen to ports 80/443 unless run as root, which was dangerous.

Java is no longer considered slow, and I doubt adding Apache to the mix will actually help speed things up.

As for the ports issue, there are probably simpler ways to connect app servers to ports 80/443 these days.

So my question is- is there really any benefit to fronting Java Webapps with Apache these days? If so, is Apache still the way to go? Should I look at Nginx? Instead of Tomcat I'm using Glassfish, if that matters.

I'm quite newbie on Glassfish.

What are some differences between JBoss and Glassfish? Why would you chooose one over the other.

I'm trying to read up on Glassfish, but it is really hard to pinpoint things that I may need before I start installing and trying to deploy some applications on it.

UPDATE
It would be good if any additional information on JBoss and Glassfish comparison is provided
(e.g. technologies they support, performance, etc.)

Our current stack is Apache + Tomcat + MySQL, using ProxyPass AJP to fire requests from Apache to Tomcat. We also run PHP for Wordpress on the same sites, and so need working .htaccess files. In response to an annoying problem (see this Stack Overflow page), we're considering alternative stacks. Note that we generally quite like apache, but this problem is a show-stopper: if we can't fix it, we can't use Apache.

Alternatives include:

• Tomcat alone
• Glassfish (Java app server, forked from Tomcat)
• Jetty (Java server)
• Resin
• LightTPD (lightweight HTTP server)
• Nginx (lightweight HTTP server)

The way I see it, solutions fall into two camps: the pure Java camp, such as Glassfish; or the split camp such as our current Apache + Tomcat. We like the idea of a pure Java solution, since fewer moving parts should mean less to go wrong; but do any of them support PHP, .htaccess files, etc?

In theory we could do the split the other way - have a simple front end that proxies to Apache on only those bits that need those features - but in practice that would be 80% of requests.

What options do people suggest?