Wednesday, September 24, 2008

Pramati IIS Webgate plugin

Most of the times the Application servers are hidden beyond the Webserver/Load Balancers/Reverse Proxy servers, such as Apache and IIS. One of my previous posts talk about Reverse Proxy here In case you are running an apache server, it provides a nice Mod_proxy module to reverse proxy to back end nodes which happen to be Application servers. However, when running IIS, then we are in a fix if you are running the back end nodes as J2EE Application servers . Pramati Server has a nice plugin that helps you to dispatch requests from IIS to Pramati Server. Documentation for the same can be refered here

I have seen some issues where the IIS plugin installation shows up red in the IIS configuration window. Restarts of the IIS service/admin service does not seem to fix the problem. Here are 2 quick things that you might need to check if you are seeing this problem.

1. The version of the IIS Webgate plugin and the version of IIS being used. Pramati Server ships various versions of IIS Webgate plugin with different versions of Pramati Server. The ones shipped with 4.1 are compatible only with IIS 4 or IIS5. May be you are trying to use a wrong combination!! For Webgate plugin that works with IIS 5 and above, I recommend that you pick up the latest version of Pramati Server and use its plugin. The latest version of Pramati Server can be downloaded from the site here

2. Sometimes, the issue could be with the log file location that you have specified for the Webgate log. The log location tag is present in the iisplugin.props file located in the ${Pramati_install}/add_ons/webgate/iis folder. Change the value to a valid location on the system

LogFileName E:\\fubar.log

These 2 checks should be able to get you running with IIS Webgate plugin in Pramati Server. Inc case you still have problems, you can talk to your designated support contact at Pramati or drop a message in one of their forums here.

Friday, July 25, 2008

Session Invalidation

Session is the user's key to the application. Once the user logs out of the application, it is very vital to invalidate the session.

I have come across a situation where the session was not invalidated even when I clicked on the Logout button.

This happened to me with the NetGear Wireless router that I use. I logged into the Router Management page and clicked on the logout button present. I was presented with the logged out screen. All was well till I wanted to visit the Management console again. When I accessed the pages, I was presented with the console without prompting for username/password.

Did I do something wrong? May be. Retry again. But it still shows the same. I use Firefox as the default browser. Then I tried with Internet Explorer. This is where the magic came up.

The logout button sends back to logged out confirmation page and this relies on the java script to close the browser. But that javascript fails in Firefox. There are 2 trivial things here:

1. To rely on the javascript to close the browser and not verifying the cross browser functionality.
2. Not invalidating the session once you click on the Logout button.

Now talking about why it is important to invalidate the session once the user clicks on the logout button:

1. Memory utilization: Most of the times, username is not the only data stored in the Session object. There could be some user specific cache that can be put into the sessions as well. The cache could account to good amount of memory. Imagine thousands of sessions created on the server which are waiting to be cleaned up and the memory they could could be hogging.

2. Security Vulnerability: Well, this is kind of tricky. Lets say the user has clicked on the logout button but the application has not invalidated the session. Now, there is some window between the user clicking on the logout and the session invalidated on the server side due to timeout. Now, lets take a session stealing case. This scenario leads to an extra time window which will help the other guy to use the stolen session and change the system. Invalidating the session once the user has logged out would reduce that security risk.

Tuesday, July 22, 2008

ORA-12519 & ORA-12505

java.sql.SQLException: Listener refused the connection with the following error:

ORA-12519, TNS:no appropriate service handler found The Connection descriptor used by the client was: localhost:1521:XE

Alright, another Oracle Exception. It says "Listener refused the connection". Is hostname correct? Yes, port? Yes, SID? Yes. Damn me. Must have forgot to start the TNSListener. But wait, if it is saying Listener refused the connection, doesn't it mean that the Listener is working and has refused the connection? Oh, yes. A quick check in the services shows that the Listener is already up and running. Why would Listener refuse the connection.? Wouldn't it refuse if the Oracle service is not running? Yes!! But the Oracle Server is running. Run a quick check and see what it says when the Oracle Service is not running.

Well, it says

java.sql.SQLException: Listener refused the connection with the following error:

ORA-12505, TNS:listener does not currently know of SID given in connect descriptor The Connection descriptor used by the client was: localhost:1521:XE

This clearly states that the SID is not recognized as the service is not running. So the earlier problem was not due to Oracle service not running. Back to square one. Okay, let me see if listener recognizes the Oracle services... What was the command? Oh, Yes. "LSNRCTL.EXE". Do a lsnrctl.exe services

Service "xe" has 1 instance(s).
Instance "xe", status READY, has 1 handler(s) for this service...

Handler(s): "DEDICATED" established:243 refused:0

The listener is able to identify that there is a service running. Hmmm. Now why does the listener refuse the connection? Let me do a quick restart on both the Oracle Service and Listener service. No use...

Hmmm. Does it have have anything to do with the username/pwd that I am using. Given the fact that the username/pwd has been created just now...It might be.

Now rerun with the root username/pwd. :-) It still fails. Thank God, I have not misconfigured the username/pwd. Wait, I see that there are some connections already established in the Application Server. Well, if its failing, it should fail for all the connections. Do a restart on the AppServer and check. Its the same thing again.

Okay, lets put up a simple java client which will try to create connections and see. Alright, it gets the connection. Let me try to check how many connections it can establish.

Connection :0
Connection :2
Connection :3
Connection :4
Connection :5
Connection :6
Connection :7
Connection :8
Connection :9
Connection :10
Connection :11
Connection :13
Connection :15
Connection :16
Connection :17
Connection :18
Exception in thread "main" java.sql.SQLException: Listener refused the connection with the following error:
ORA-12519, TNS:no appropriate service handler found The Connection descriptor used by the client was: localhost:1521:XE

Aha!!!! Trying to establish more than 20 connections is causing the problem.

Alright, its out of my control now. Googling, finally I land up at:

It says, the problem is with the number of process count defined in the init.ora file. Let me check. There is no process count defined. WTH, let me define the process count in init.ora file and restart Oracle


It still stays the same. So adding the process count is not recognized. Let me try what was suggested.


Now with this change and restarting the Oracle service, it is able to create upto 409 connections now. Great!

Tuesday, April 8, 2008

No blogging!

One more reason why I do not blog (being lazy is the first one) :-)