rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Franklin, Matthew B." <mfrank...@mitre.org>
Subject RE: [DISCUSS] Apache Rave 0.6-incubating Release Candidate
Date Tue, 06 Dec 2011 13:33:41 GMT
>-----Original Message-----
>From: Ate Douma [mailto:ate@douma.nu]
>Sent: Tuesday, December 06, 2011 8:20 AM
>To: rave-dev@incubator.apache.org
>Subject: Re: [DISCUSS] Apache Rave 0.6-incubating Release Candidate
>On 12/06/2011 02:05 PM, Franklin, Matthew B. wrote:
>>> -----Original Message-----
>>> From: Ate Douma [mailto:ate@douma.nu]
>>> Sent: Tuesday, December 06, 2011 8:00 AM
>>> To: rave-dev@incubator.apache.org
>>> Subject: Re: [DISCUSS] Apache Rave 0.6-incubating Release Candidate
>>> 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
>>>>> I dived deeper into the problem and after a while I noticed what IMO
>>>>> 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
>>> 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
>>> 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
>>> 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
>>> 20x (while trying to find the culprit) as well against trunk. And every time
>>> 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
>>> rave-portal uses the check "SELECT * FROM WIDGET" to determine if the
>>> initialization should be done... So, in that case it is logical both
>>> rave-shindig and rave-portal data initialization are executed.
>> Maybe therein lies the issue.  The portal context always starts for me before
>the root (not intuitive nor potentially correct, but seems to be consistent in
>multiple environments).  Therefore, I never see the issue, since by the time
>Shindig starts, the Person table is populated.
>OK. That might be the 'cause' then.
>But it still is puzzling why it always is initializing the ROOT context first on
>my machine. Which would make sense to me from a web server POV.
>But it clearly isn't always the case. Which makes it unreliable behavior to say
>the least.

Is there anything in the language settings that could be changing the default sort order?
 R comes after p, so it seems that tomcat may be trying to load all of the applications in
alphabetical order on the machines where it is working...

>I'm now unsure if I should vote +1 or -1 on this release.
> From a release process POV, disregarding execution, this release candidate
>seems valid to me.
>But I personally cannot use this release, nor the current trunk for that matter.
>So, to me this feels like a -1 on usability.

IMO, if this were not isolated to some identifiable issue with your machine configuration
(language settings, etc) that we could post as a known issue with the download, I would be
inclined to vote -1 as well.  However, if we can figure out what the issue is and document
it, then my personal vote will be +1.

>Just to be clear: regardless my vote, if you get a majority and +3 IPMC votes
>this release can be regarded successfully.

That assumes we can get IPMC members to vote at all :)

>>>> Not sure why you are getting the duplicate key exception on the
>>> 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
>>>>> 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
>>> posted to the list was on a second or third attempt in the same session and
>>> 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
>>> tomcat.
>>>>> Ate
>>>>>> Note that on Linux /tmp is cleared every time I reboot anyway, so
I had
>>>>>> "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
>>> could
>>>>>> check once more.
>>>>>> The only thing I did was download the binary tar.gz, extract it at
>>>>>> 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
>>>>> away:
>>>>>>> login doesn't seem to work anymore.
>>>>>>> That might be something specific to my environment, but seems
>>>>>>> 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:
>>>>> ory -
>>>>>>> Database population has failed. It will be empty.
>>>>>>> java.lang.RuntimeException: SQL exception occurred loading data
>>>>>>> initial_data.sql
>>>>>>> and:
>>>>>>> UPDATE RAVE_PORTAL_SEQUENCES SET seq_count = (seq_count + 1)
>>>>> WHERE seq_name =
>>>>>>> @portal_preference_seq; [23505-154]
>>>>>>> at
>>>>>>> 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
>>>>> 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. I
>>>>> am
>>>>>>>> unsure why this happened, but I did have a network hiccup
>>>>> release
>>>>>>>> script was running, so maybe that was the issue. All of the
>>> appear
>>>>>>>> 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
>>> pom
>>>>>>>> containing the metadata that has Sean as a committer/PPMC
>>>>> 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
>>>>>>>> - do all of the staged jars/zips contain the required LICENSE,
>>> and
>>>>>>>> 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