Foren

Liferay startup stuck while db changed to mysql

Prashant Mirajkar, geändert vor 13 Jahren.

Liferay startup stuck while db changed to mysql

New Member Beiträge: 22 Beitrittsdatum: 24.11.08 Neueste Beiträge
I have installed liferay 5.2.3 under Tomcat 6 VirtualHost on Ubuntu.

With default installation that uses hsql, I got errors as Liferay would find database locked and so I decided to switch to mysql.

In my portal-ext.properties I have created entries to use mysql.

However when I start tomcat, Liferay reads the portal-ext, but then nothing happens after that.

(I have mentioned schema.run.enable and schema.run.minimal as true).

Does anyone have solution?

cheers,

Prashant
Prashant Mirajkar, geändert vor 13 Jahren.

RE: Liferay startup stuck while db changed to mysql - RESOLVED

New Member Beiträge: 22 Beitrittsdatum: 24.11.08 Neueste Beiträge
This was rather tricky to solve.

First I enabled all the logging at DEBUG level by hacking portal-log4j.xml in portal-impl.jar/META-INF. (out of lazinessemoticon)

That first indicated that mysql server version 5.1.37 and connector in liferay distro were incompatible. Therefore I upgraded the connector (version 5.1.12). Now thing to remember is that it takes a while for code to timeout and give this exception and I was in a hurry!

This progress was stuck as I started getting "The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.)"

To tackle this I had to open mysql port 3306 on 127.0.0.1 in my iptables firewall.

cheers,

Prashant
thumbnail
Olaf Kock, geändert vor 13 Jahren.

RE: Liferay startup stuck while db changed to mysql

Liferay Legend Beiträge: 6403 Beitrittsdatum: 23.09.08 Neueste Beiträge
Prashant Mirajkar:
With default installation that uses hsql, I got errors as Liferay would find database locked and so I decided to switch to mysql.


You have already solved your problem, but let me add one piece of information:

Not being able to write to hsql most likely means that the user account that is used to run tomcat cannot write to the directory where hsql wants to store its data. So either you used another account to unzip/copy the files or you ran tomcat once as root, leading to all the files belonging to root, so that they can't be written to once you run tomcat as unprivileged user.

You've mitigated this problem well though - as advertised everywhere, I wouldn't recommend anything more than a quick demo on hsql.