rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marlon Pierce <mpie...@cs.indiana.edu>
Subject Re: [DISCUSS] Apache Rave 0.6-incubating Release Candidate
Date Tue, 06 Dec 2011 13:39:38 GMT
-----BEGIN PGP SIGNED MESSAGE-----
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)


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' 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.
>>>
>>> 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 :)
> 
>>
>> 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
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
>>>> 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
Candidate
>>>>>>>>
>>>>>>>> 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 -<t
>>>> 1730147382,
>>>>>> conn
>>>>>>>> 1904595916>   executing stmnt 292713878 CREATE INDEX
>>>>>> I_WDGTMNT_USER ON
>>>>>>>> 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. 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
LICENSE, NOTICE
>>>> 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
>>>>>>>>
>>>>>>>
>>>>>
>>>
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJO3hsaAAoJEEfVXEODPFIDnpIH/2jgVl/22OehuiC51XGEYXLz
NRR82cvLt4lEkHiZVEbbcYgfmN7YkVKVRSfawe3C1WVkOfhTIJMh2UdL5i4I+l7q
WBLbpc9AelaH3DdFBQNFUA09/YyZ2Gm63Ry3Y8ulAeyxvR7oqdmItJRFSzCSb5W9
qVkmQXQXVQOoj2I2T/VNxwd9K7G9qv7xH6NsKBaxVQmf/EwBv3Mt8nlOZJkGXG43
t2B8oOVd8nli9pfsUkeBb707cNjiAGRJR6k+Zu40YjXjRpdWLDSoRk1Py7KwAFd8
mbi0lIH+L+O+mvH9oam6quYk0cnVHFlBIs3kNbpkO/EE06W9x8BS32lGD61ok+k=
=0h7u
-----END PGP SIGNATURE-----

Mime
View raw message