rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: [DISCUSS] Apache Rave 0.6-incubating Release Candidate
Date Tue, 06 Dec 2011 13:00:05 GMT
On 12/06/2011 01:36 PM, Franklin, Matthew B. wrote:
>> -----Original Message-----
>> From: Ate Douma [mailto:ate@douma.nu]
>> Sent: Monday, December 05, 2011 7:16 PM
>> To: rave-dev@incubator.apache.org
>> Subject: Re: [DISCUSS] Apache Rave 0.6-incubating Release Candidate
>> On 12/05/2011 05:41 PM, Ate Douma wrote:
>>> On 12/05/2011 04:39 PM, Mahadevan, Venkat wrote:
>>>> I had the same issue, clearing the /tmp/rave DB files fixed it.
>>> Just tried that myself but didn't make a difference. Same set of errors.
>> I dived deeper into the problem and after a while I noticed what IMO is
>> causing
>> the problem.
>> What I really don't understand is why nobody else seems to encounter this...
>> What I see going wrong is that we have initialization data for persons in both
>> rave-shindig *and* rave-portal... using (and reinitializing) the same 'person'
>> sequence *and* the same person entity_id...
>> That of course never can work if you use one and the same database and the
>> same
>> set of tables.
>> Besides that, the person initialization done from rave-shindig initial_data.sql
>> only uses a subset of the person attributes while the 'same' person
>> initialization done from rave-portal initial_data.sql is using a different
>> subset of the person attributes. They overlap partly but not wholly.
> The extra SQL artifact is my fault.  I didn't remove it when I moved the Person to core.
>> At any rate, I think this part of the configuration is simply broken.
>> When I deleted all person initialization as well move the person_association,
>> groups and group_members initialization from rave-shindig initial_data.sql to
>> the rave-portal initial_data.sql I finally got it working again.
>> But, how could it possibly work for everyone else without such changes?
> I think I have the answer.  The rave-shindig initial-data.sql file only gets parsed and
the statements executed if SELECT * FROM PERSON returns no rows or an exception that the table
doesn't exist.  What seems to be happening to you is that the rave-portal initial-data.sql
is failing to execute properly, which in turn is executing the rave-shindig version.  This
is why everyone who has it working doesn't see the collision between the statements in the
two SQL files.
OK, I missed that check, or better said forgot about it.
Make sense. However... it is failing on me, and always. And I did check it like 
20x (while trying to find the culprit) as well against trunk. And every time I 
made sure to run $ rm /tmp/rave* first. So, running without any initial database.

I do think the rave-shindig is loaded first though, before rave-portal (ROOT 
webapp always being initialized first), which them could explain this because 
rave-portal uses the check "SELECT * FROM WIDGET" to determine if the data 
initialization should be done... So, in that case it is logical both 
rave-shindig and rave-portal data initialization are executed.

> Not sure why you are getting the duplicate key exception on the sequence table unless
the database is already there, but not populated.
>> Alternatively, I can of course change the configuration by having rave-shindig
>> and rave-portal point to two different databases (and then it works again
>> too),
>> but the whole point here IMO is leveraging the same database and the same
>> model
>>from both sides, right (RAVE-345 and sub tasks)?
>> What am I doing different (other than simply extract and run the binary) from
>> everyone else?
> Just for fun, I would double check that /tmp/rave_db.h2.db is not there when you run
the demo binaries for the first time.  Maybe the exception you posted to the list was on a
second or third attempt in the same session and is just a mask of the real problem...
That is not the case.
I've tested this every time with first removing the database before starting up 

>> Ate
>>> Note that on Linux /tmp is cleared every time I reboot anyway, so I had a
>>> "clean" /tmp to begin with.
>>> I still haven't had time to look more deeply into this, and will do so later
>>> this evening. But it would be good if everyone else (on Linux at least) could
>>> check once more.
>>> The only thing I did was download the binary tar.gz, extract it at a random
>>> location and executed $ bin/catalina.sh run from that location.
>>> Ate
>>>> Venkat
>>>> -----Original Message-----
>>>> From: Ate Douma [mailto:ate@douma.nu]
>>>> Sent: Monday, December 05, 2011 8:18 AM
>>>> To: rave-dev@incubator.apache.org
>>>> Subject: Re: [DISCUSS] Apache Rave 0.6-incubating Release Candidate
>>>> I still haven't had the time to review the candidate in detail, I expect
>>>> provide more feedback earliest late today / this evening.
>>>> However, I did try to run the binary download and hit a problem right
>> away:
>>>> login doesn't seem to work anymore.
>>>> That might be something specific to my environment, but seems odd.
>>>> I will try to figure out what is causing the problem, but I did see some
>>>> exceptions thrown in the console during startup:
>>>> 11699 ravePersistenceUnit TRACE [main] openjpa.jdbc.SQL -<t 1730147382,
>> conn
>>>> 1904595916>  executing stmnt 292713878 CREATE INDEX
>>>> widget_comment (user_id)
>>>> 11699 ravePersistenceUnit TRACE [main] openjpa.jdbc.SQL -<t 1730147382,
>> conn
>>>> 1904595916>  [0 ms] spent
>>>> ERROR:
>> org.apache.rave.persistence.jpa.PopulatedLocalContainerEntityManagerFact
>> ory -
>>>> Database population has failed. It will be empty.
>>>> java.lang.RuntimeException: SQL exception occurred loading data from
>>>> initial_data.sql
>>>> and:
>>>> UPDATE RAVE_PORTAL_SEQUENCES SET seq_count = (seq_count + 1)
>> WHERE seq_name =
>>>> @portal_preference_seq; [23505-154]
>>>> at
>> org.h2.message.DbException.getJdbcSQLException(DbException.java:327)
>>>> at org.h2.message.DbException.get(DbException.java:167)
>>>> at org.h2.message.DbException.get(DbException.java:144)
>>>> at org.h2.index.BaseIndex.getDuplicateKeyException(BaseIndex.java:80)
>>>> Anyway, it might be something trivial but right now I cannot yet give a
>> vote.
>>>> Not sure when Matt wants to wrap up this vote but maybe it might be
>> good to wait
>>>> a few hours up to a day more.
>>>> Regards,
>>>> Ate
>>>> On 12/01/2011 12:30 AM, Franklin, Matthew B. wrote:
>>>>> Discussion thread for vote on 0.6-incubating release candidate.
>>>>> Note, there were two staging repos created during the release process.
>> am
>>>>> unsure why this happened, but I did have a network hiccup while the
>> release
>>>>> script was running, so maybe that was the issue. All of the artifacts
>>>>> to have made it fine, but it would be good to have a second pair of eyes
>>>>> check that.
>>>>> Also, I forgot to create a combined release with the updated master pom
>>>>> containing the metadata that has Sean as a committer/PPMC member
>> listed.
>>>>> For more information on the release process, checkout -
>>>>> http://www.apache.org/dev/release.html
>>>>> http://incubator.apache.org/guides/releasemanagement.html
>>>>> Some of the things to check before voting are:
>>>>> - can you run the demo binaries
>>>>> - can you build the contents of source-release.zip and svn tag
>>>>> - do all of the staged jars/zips contain the required LICENSE, NOTICE
>>>>> DISCLAIMER files
>>>>> - are all of the staged jars signed and the signature verifiable
>>>>> - is the signing key in the project's KEYS file and on a public server

View raw message