This content has been marked as final. Show 4 replies
Is the default port being used by the JMS server already in use on the computer that won't start?
You can see the port it uses within the j2ee/home/config/jms.xml file.
By default it is 9127.
The cause of this sometimes is when a second instance of OC4J is started on a machine (ie one instance is already running with all the default ports) and the ports are already taken.
Else do a netstat and see if 9127 is already in use.
You can change the port it uses by just editing the jms.xml file.
I have the same problem. The strange thing is: my jdeveloper 10.1.3 oc4j exhibits the problem but my standalone oc4j doesn't. So what's the problem you might ask. I need the jdeveloper instance because it is configured for adf.
I changed the port and that did not change anything.
This is using the final 10.1.3 release by the way.
The OC4J instance that is having the problem may have .lock file issues. Some quotes from the JMS chapter of the services guide:
If OC4J terminates normally, then the lock files are cleaned up automatically. However, if OC4J terminates abnormally, for example, a kill -9 command, then the lock files remain in the file system. OC4J can usually recognize leftover lock files. If not, you must manually remove lock files before restarting OC4J after abnormal termination.
JMS persistence lock files are tagged with (contain) server and persistence directory location info. If the lock file exists when the JMS server starts, and the lock file was created by the same server (having the same ip address) and using the same persistence directory location, then the JMS server will assume control of the lock file and start up successfully.
If, for some reason, the jms.state file itself is corrupted, then the only recourse is to delete it, with the attendant loss of all pending transactions - that is, transactions that have been committed, but the commits not yet performed by all individual destination objects participating in the transactions.
Note that the use of an IP address can cause issues if you have abnormal terminations and are using DHCP (so next time you start OC4J you also have a new IP address). There was also an issue in the dev preview versions if you are running on MS-Windows where the .lock files would not be automatically deleted on normal shut down - even if you have since moved to the release version, the old .lock files may still be there.
I'm not sure if it's some form of karma, but I just ran into this exact same problem for the very first time.
I fixed it by removing the entire contents of the directory:
Then OC4J started fine.
My situation was such that my laptop working at home on a broadband based VPN connection ran out of battery and just died.
When I got to work this morning and tried to start my OC4J instance, this error stack appeared and OC4J aborted.
Removing the contents of the persistence directory removed the lock files which thereby allowed OC4J to start as normal.