Re: Tests take forever
Strub, Locking's pom.xml defines the following property that should help you a bit: Cheers, Milosz > Might have been a temporal problem locally since this special test performs > rather quick in our hudson: > > https://hudson.apache.org/hudson/job/OpenJPA-trunk/370/org.apache.openjpa$openjpa-persistence-jdbc/testReport/ > > The locking tests of corse are really slow in hudson too. > > Might be worth moving all the expensive test into an own 'integration-test' > profile? > Otherwise developers will just take the shortcut and don't run the whole > build prior to a checkin because it takes so long ;) > > LieGrue, > strub > > --- On Thu, 1/6/11, Mark Struberg wrote: > > > From: Mark Struberg > > Subject: Tests take forever > > To: dev@openjpa.apache.org > > Date: Thursday, January 6, 2011, 1:56 PM > > Hi! > > > > Anyone has an idea why some of our tests take almost > > forever when they run inside the build, but are very cheap > > if run standalone? > > > > My build currently takes ~ 1h 15minutes on a 4x3GHz and > > also not much longer on my notebook. This indicates that > > there is something 'foul' with them. Either they wait > > unnecessarily long or they do not scale (even when built > > with mvn -T4) > > > > An example: > > > > I got the following results for > > org.apache.openjpa.lib.conf.TestEquivalentConfiguration: > > testOldStylePersistenceUnitConfiguration > > 6.541 > > testNewStylePersistenceUnitConfiguration > > 206 > > > > testMixedStylePersistenceUnitConfiguration > > 223 > > > > testConflictStylePersistenceUnitConfiguration > > 18 > > testNewStyleSystemPropertyConfiguration > > 214 > > testOldStyleSystemPropertyConfiguration > > 223 > > > > testMixedStyleSystemPropertyConfiguration > > 256 > > > > testConflictStyleSystemPropertyConfiguration > > 16 > > testOldStyleRuntimePropertyConfiguration > > 249 > > testNewStyleRuntimePropertyConfiguration > > 231 > > > > testMixedStyleRuntimePropertyConfiguration > > 24 > > > > testConflictStyleRuntimePropertyConfiguration > > 18 > > > > makes 844 seconds in summary. > > > > But the same test passes in 4.034 seconds when I run this > > test in Idea (all 12 tests pass). > > > > I used the following VM settings: > > -Dopenjpa.Log=DefaultLevel=INFO > > -Dopenjpa.DynamicEnhancementAgent=false > > -Dopenjpa.ConnectionDriverName=org.apache.derby.jdbc.EmbeddedDriver > > -Dopenjpa.ConnectionURL=jdbc:derby:target/database/openjpa-derby-database;create=true > > -Dopenjpa.ConnectionUserName= -Dopenjpa.ConnectionPassword= > > > > Is there anything I miss? > > > > Looks like we should pretty easily be able to slash down > > our build to 20 minutes or so... > > > > > > LieGrue, > > strub > > > > > > > > > > > >
Re: change schema based on environment
Keith, You can specify a default schema in a DB2 connection URL like this: jdbc:db2://mserver:50007/MYDB7T:currentSchema=MySchema; Can you use this syntax when creating the data source? Regards, Milosz > > I am using OpenJPA 1.2.3 on WebSphere with DB2. > > I have spent a lot of time trying to figure out if there is a way to build > and bundle my application in a way that allows for the same application > (EAR) to have a changing Schema name based on environment (DEV,ACPT,PROD, > etc). > > My PU is setup up to be container managed as follows: > > > > jdbc/DataSource > ... > > >value="managed"/> >value="managed"/> > > > > > I have looked into putting this in the ORM.xml, but this is still a static > value for the schema, and does not externalize the setting; also, it doesn't > seem to work (I have seen the many threads discussing this). I also, have > looked into putting this configuration into the WebSphere data source; this > does not seem to work either. > > Any help is appreciated. Thanks. > > --Keith >
Re: Build Errors
Hi, Thanks a lot. I made the changes you suggested and successfully done with the build. Now started to look into the code and documentation. Thanks, ~Umashanthi On Sat, Jan 8, 2011 at 5:37 PM, Mark Struberg wrote: > Hi! > > The problem is that our build opens lots of files: > > > > (Too many open files) > > Usually your ulimits for open files are set to 1024 if you are on *nix > > Try opening > /etc/security/limits.conf > > and add the following 2 lines: > * hardnofile 4096 > * softnofile 4096 > > Then apply those values with > $> sysctl -p > > and open a new shell environment with > $> su - [yourusername] > > Please check if the new limits got applied with > $> ulimit -n > > > LieGrue, > strub > > --- On Sat, 1/8/11, Umashanthi Pavalanathan wrote: > > > From: Umashanthi Pavalanathan > > Subject: Build Errors > > To: dev@openjpa.apache.org > > Date: Saturday, January 8, 2011, 3:04 AM > > Hi devs, > > > > I checked out the OpenJPA source code from [1] and trying > > to build it. > > I'm getting build errors due to different class files, in > > the OpenJPA > > Persistence JDBC component, each time I build. > > Following are some of the errors [2] [3] [4]. > > > > I would be glad if someone can guide me to solve these > > build errors. > > > > > > > > [1] http://svn.apache.org/repos/asf/openjpa/trunk > > [2] http://pastebin.com/SPhnRQyW > > [3] http://pastebin.com/78zUeUzE > > [4] http://pastebin.com/60gKwfRv > > > > Thanks, > > ~Umashanthi > > > > > >
[jira] Updated: (OPENJPA-1873) EntityManager#merge sometimes passes wrong entity values to @PostLoad EntityListeners
[ https://issues.apache.org/jira/browse/OPENJPA-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated OPENJPA-1873: --- Attachment: OPENJPA-1873-fix2.patch and here comes the next one, this time with a new 'openjpa.PostLoadOnMerge' configuration property. Tests are currently running LieGrue, strub > EntityManager#merge sometimes passes wrong entity values to @PostLoad > EntityListeners > -- > > Key: OPENJPA-1873 > URL: https://issues.apache.org/jira/browse/OPENJPA-1873 > Project: OpenJPA > Issue Type: Bug > Components: kernel >Affects Versions: 2.0.0, 2.0.1, 2.0.2 >Reporter: Mark Struberg >Assignee: Rick Curtis > Attachments: OPENJPA-1873-fix1.patch, OPENJPA-1873-fix2.patch, > openjpa-1873-hack-1.patch, OPENJPA-1873-unittest.patch, postloadtest.zip > > > I've tested this with the latest from branches/2.0.x. > My entity has an @EntityListeners which observes the @PostLoad lifecycle > event. This listener stores the 'old' values from the database for later use > (see http://struberg.wordpress.com/2010/07/31/howto-changelog-with-jpa/ for > the intention behind). All works well if the table has only a few rows. But > if you add more rows, OpenJPA tries to optimize the access and only loads the > @Version field + the dirty fields. In this case the merging seems to be > wrong, because I get the NEW values from the dirty fields instead of the > original values from the database passed to my @PostLoad method. > Did cost me a few grey hairs to track down the differences between the > working and the broken scenarios here ;) But finally I was able to creat a > unit test showing the problem -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Build Errors
Hi! The problem is that our build opens lots of files: > (Too many open files) Usually your ulimits for open files are set to 1024 if you are on *nix Try opening /etc/security/limits.conf and add the following 2 lines: * hardnofile 4096 * softnofile 4096 Then apply those values with $> sysctl -p and open a new shell environment with $> su - [yourusername] Please check if the new limits got applied with $> ulimit -n LieGrue, strub --- On Sat, 1/8/11, Umashanthi Pavalanathan wrote: > From: Umashanthi Pavalanathan > Subject: Build Errors > To: dev@openjpa.apache.org > Date: Saturday, January 8, 2011, 3:04 AM > Hi devs, > > I checked out the OpenJPA source code from [1] and trying > to build it. > I'm getting build errors due to different class files, in > the OpenJPA > Persistence JDBC component, each time I build. > Following are some of the errors [2] [3] [4]. > > I would be glad if someone can guide me to solve these > build errors. > > > > [1] http://svn.apache.org/repos/asf/openjpa/trunk > [2] http://pastebin.com/SPhnRQyW > [3] http://pastebin.com/78zUeUzE > [4] http://pastebin.com/60gKwfRv > > Thanks, > ~Umashanthi >