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 14:16:37 GMT
On 12/06/2011 02:39 PM, Marlon Pierce wrote:
> Hash: SHA1
> It's a shot in the dark, but what Java version were you using, Ate?  My linux test (which
went ok) used the following:
> $ java -version
> java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)

I'm in the middle of another meeting (for the next several hours) so I can't 
interact/response properly right now.

Just a quick answer to this question:

$ java -version
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)

> Marlon
> On 12/6/11 8:33 AM, Franklin, Matthew B. wrote:
>>> -----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 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'
>>>>>>> initialization done from rave-portal initial_data.sql is using
a different
>>>>>>> subset of the person attributes. They overlap partly but not
>>>>>> The extra SQL artifact is my fault.  I didn't remove it when I moved
>>>>> Person to core.
>>>>>>> At any rate, I think this part of the configuration is simply
>>>>>>> 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
>>>>>> 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
>>> 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
>>>>> 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.
>>>> 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
>>> 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 :)
>>> Ate
>>>>>> 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
>>>>> shindig
>>>>>>> and rave-portal point to two different databases (and then it
>>> 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
>>>>> 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
>>> 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
>>>>> tomcat.
>>>>>>> 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
>>>>>>>>> I still haven't had the time to review the candidate
in detail, I expect
>>> to
>>>>>>>>> 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
>>>>> 1730147382,
>>>>>>> conn
>>>>>>>>> 1904595916>    executing stmnt 292713878 CREATE INDEX
>>>>>>>>> widget_comment (user_id)
>>>>>>>>> 11699 ravePersistenceUnit TRACE [main] openjpa.jdbc.SQL
>>>>> 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
>>> 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
>>>>>>>>>> Note, there were two staging repos created during
the release
>>>>> process. I
>>>>>>> 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
>>>>> 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 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
>>>>> and
>>>>>>>>>> DISCLAIMER files
>>>>>>>>>> - are all of the staged jars signed and the signature
>>>>>>>>>> - is the signing key in the project's KEYS file and
on a public server
> Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> NRR82cvLt4lEkHiZVEbbcYgfmN7YkVKVRSfawe3C1WVkOfhTIJMh2UdL5i4I+l7q
> WBLbpc9AelaH3DdFBQNFUA09/YyZ2Gm63Ry3Y8ulAeyxvR7oqdmItJRFSzCSb5W9
> qVkmQXQXVQOoj2I2T/VNxwd9K7G9qv7xH6NsKBaxVQmf/EwBv3Mt8nlOZJkGXG43
> t2B8oOVd8nli9pfsUkeBb707cNjiAGRJR6k+Zu40YjXjRpdWLDSoRk1Py7KwAFd8
> mbi0lIH+L+O+mvH9oam6quYk0cnVHFlBIs3kNbpkO/EE06W9x8BS32lGD61ok+k=
> =0h7u

View raw message