|
Home > Archive > WebSphere Application Server > September 2006 > Do I have to restart WAS when I restart HTTP?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Do I have to restart WAS when I restart HTTP?
|
|
| Tom Clukay 2006-09-16, 1:48 pm |
| We are currently running WAS Express 5.1 on a V5R3 i5 box. If both HTTP and WAS is up and running, can I restart HTTP (using the administrative console) without restarting WAS?
NOTE- Our WAS server IS NOT configured to automatically stop/start when the attached HTTP server is stopped/started.
Second, we have a job that runs nightly that 1) stops WAS, 2) stops HTTP, 3) starts HTTP, and 4) starts WAS (via the QSH StartServer command). Occasionally, this doesn't seem to work properly. No errors in any joblogs, but "unable to connect to database"
errors occur when users try to log on. Does there need to be some kind of time delay between the HTTP restart and the WAS restart or something? Ideas?
| |
| Paul Ilechko 2006-09-16, 1:48 pm |
| Tom Clukay wrote:
> We are currently running WAS Express 5.1 on a V5R3 i5 box. If both
> HTTP and WAS is up and running, can I restart HTTP (using the
> administrative console) without restarting WAS?
Yes.
> NOTE- Our WAS server IS NOT configured to automatically stop/start
> when the attached HTTP server is stopped/started.
>
> Second, we have a job that runs nightly that 1) stops WAS, 2) stops
> HTTP, 3) starts HTTP, and 4) starts WAS (via the QSH StartServer
> command). Occasionally, this doesn't seem to work properly. No errors
> in any joblogs, but "unable to connect to database" errors occur when
> users try to log on. Does there need to be some kind of time delay
> between the HTTP restart and the WAS restart or something? Ideas?
No, you can restart them in parallel. Until web traffic for WAS hits the
HTTP server there will be no traffic between them. In fact it probably
makes more sense to stop the HTTP server first and start WAS first.
| |
| Tom Clukay 2006-09-16, 1:48 pm |
| Okay. That said, I'm at a loss to understand why I'm having problems connecting to the database after a restart. A couple of times a month, after stopping and restarting the servers (remember, no error messages), users are unable to login because of an "
Unable to instantiate database connection" error message.
This is DEFINITELY tied to the server stop and restart.
Anyone have any ideas?
| |
|
| Work with your DBAs to determine if anything is happening on the database at the same time. There could be a timing issue as far as the app server and database coming up out of sequence that throws off the communication between the two - we've seen a few
problems like that as far as having a database go down and come back up, but WebSphere can't seem to reestablish connections, and a WAS restart is in order. On the other hand, it's possible that the application(s) is not closing Oracle connections grace
fully on a destroy, and you need to tune some code (shouldn't apply if you are using DataSources and connection pooling from within WebSphere instead of the application managing database connections).
Your DBAs would probably be the best source of information, they should be able to monitor the database during your scripts' execution and see how the connections are failing.
| |
| Tom Clukay 2006-09-19, 1:35 pm |
| Thanks Tim and Paul for your responses.
I'm coming to the conclusion that it's not so much the order that we're stopping and restarting the servers as it is something else that's "interfering" with the restart process. In fact, it could even be so simple as that we're not allowing enough time
between the automated job that stops both the servers and the one that restarts them. (If the stop job is still finishing up terminating HTTP and/or WAS and then the start job kicks in and tries to start restarting things, I'm guessing that, in some inst
ances, that could cause a problem).
I think I'm going to open up a new post restating my question in a different way, given the information I've got so far. Thanks again.
|
|
|
|
|