Re: [hibernate-dev] [HSEARCH] Build on Windows
Yes I'm having a look; for what it's worth these are the slightly better results on Jenkins: Results : Failed tests: testWorkLongerThanMaxQueueSize(org.hibernate.search.test.backend.SyncBackendLongWorklistsStressTest): expected:<40> but was:<10> testInternalSharding(org.hibernate.search.test.shards.ShardsTest): expected:<1> but was:<0> Tests in error: testSourceNotReady(org.hibernate.search.test.directoryProvider.FSSlaveAndMasterDPTest): Unable to setup test directories testStandardInitialization(org.hibernate.search.test.directoryProvider.RetryInitializeTest): Unable to setup test directories testInitiallyFailing(org.hibernate.search.test.directoryProvider.RetryInitializeTest): Unable to setup test directories testMasterDelayedInitialization(org.hibernate.search.test.directoryProvider.RetryInitializeTest): Unable to setup test directories experimentWithAvro(org.hibernate.search.test.serialization.AvroTest) Tests run: 383, Failures: 2, Errors: 5, Skipped: 0 Quoting only Emmanue's results: On 29 September 2011 11:08, Emmanuel Bernard wrote: > > Results : > > Failed tests: > testWorkLongerThanMaxQueueSize(org.hibernate.search.test.backend.SyncBackendLongWorklistsStressTest): > expected:<40> but was:<10> > testInternalSharding(org.hibernate.search.test.shards.ShardsTest): > expected:<1> but was:<0> > > Tests in error: > testSourceNotReady(org.hibernate.search.test.directoryProvider.FSSlaveAndMasterDPTest): > Unable to setup test directories > testStandardInitialization(org.hibernate.search.test.directoryProvider.RetryInitializeTest): > Unable to setup test directories > testInitiallyFailing(org.hibernate.search.test.directoryProvider.RetryInitializeTest): > Unable to setup test directories > testMasterDelayedInitialization(org.hibernate.search.test.directoryProvider.RetryInitializeTest): > Unable to setup test directories > testCorrectDepthIndexed(org.hibernate.search.test.embedded.depth.DocumentIdContainedInTest): > More than one @DocumentId specified on entity > org.hibernate.search.test.embedded.depth.PersonWithBrokenSocialSecurityNumber > testEntityDeletionWithoutIdentifier(org.hibernate.search.test.engine.UsingIdentifierRollbackTest): > More than one @DocumentId specified on entity > org.hibernate.search.test.embedded.depth.PersonWithBrokenSocialSecurityNumber > testRolledBackIdentifiersOnUnusualDocumentId(org.hibernate.search.test.engine.UsingIdentifierRollbackTest): > More than one @DocumentId specified on entity > org.hibernate.search.test.embedded.depth.PersonWithBrokenSocialSecurityNumber > experimentWithAvro(org.hibernate.search.test.serialization.AvroTest) > > Tests run: 383, Failures: 2, Errors: 8, Skipped: 0 ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hibernate Search 4.0 Beta 2 is out
Hibernate Search 4.0 Beta 2 has been released. It contains bug fixes and a few new features including having Hibernate Core as an optional dependency. We have shuffled the maven modules a bit, but migration should be transparent. More info here http://goo.gl/J1ipz ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] OGM feature request on forums
Hi, there is this thread on the OGM forums, for which I think the last post makes an interesting read: https://forum.hibernate.org/viewtopic.php?p=2449117#p2449117 people want the flexibility of the "grid", but still permanently store the important stuff in their trusted relational database. I agree with the user in saying that this would certainly make OGM even more interesting, something to consider in the design as a long term plan. In addition, it would provide a reliable way to perform relational queries :) Sanne ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] [HSEARCH] Remove 'preferIPv4Stack' validation
The app I work on needs to bind to ipv6 addresses and to communicate with other network nodes using ipv6. The library component that does this communication breaks if I set 'preferIPV4Stack=true'. I've had to remove the code that forces this from hibernate-search and hibernate-search-infinispan and maintain custom libraries in order to use infinispan. After doing so, everything works fine binding to an ipv6 multicast address. My environment is RHEL4 + JDK 1.6.0.7 + Hibernate Search 3.4.1. I've used jgroups on other applications without having to set preferIPV4Stack=true(apps that also use ipv6), with no issues other than needing to ensure that both mcast port, and mcast address are different per 'group'. Is there any reason to keep this validation in? I understand there are JDK issues with some OS environments where ipv6 won't work, and this probably saves a lot of troubleshooting time. Maybe something can be added to allow an override so the majority of applications are forced to use ipv4, but if someone really wants ipv6 they can override: '-Dforce.hibernate.search.ipv6=true'? ZK ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HSEARCH] Remove 'preferIPv4Stack' validation
Hi, yes I'm aware the check is no longer needed, in fact we dropped it in HSEARCH-860, where you can find a short explanation too [1]. So since v.4 it won't prevent IPv6 anymore. Versions 3.x are expected to be compatible with Java5 so backporting the same patch as HSEARCH-860 would not be the best option; the solution you propose to add a system property to give the user a "I know what I'm doing" option sounds great: if you could send a pull request I'll apply it, just keep in mind it's needed for 3.4.x only. 1 - https://hibernate.onjira.com/browse/HSEARCH-860 Sanne On 29 September 2011 18:41, Zachary Kurey wrote: > The app I work on needs to bind to ipv6 addresses and to communicate with > other network nodes using ipv6. The library component that does this > communication breaks if I set 'preferIPV4Stack=true'. I've had to remove > the code that forces this from hibernate-search and > hibernate-search-infinispan and maintain custom libraries in order to use > infinispan. After doing so, everything works fine binding to an ipv6 > multicast address. My environment is RHEL4 + JDK 1.6.0.7 + Hibernate Search > 3.4.1. I've used jgroups on other applications without having to set > preferIPV4Stack=true(apps that also use ipv6), with no issues other than > needing to ensure that both mcast port, and mcast address are different per > 'group'. > > Is there any reason to keep this validation in? I understand there are JDK > issues with some OS environments where ipv6 won't work, and this probably > saves a lot of troubleshooting time. Maybe something can be added to allow > an override so the majority of applications are forced to use ipv4, but if > someone really wants ipv6 they can override: > '-Dforce.hibernate.search.ipv6=true'? > > ZK > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Source links in JIRA broken
Thanks for the update. Great to see FE working again.
--Gunnar
2011/9/29 Steve Ebersole :
> So apparently there are issues with the direct GitHub connector. The
> Atlassian dev team is working on that stuff. But in the meantime Atlassian
> have re-enabled the FishEye repository so that we can get linking. For the
> time being they have only restarted the Hibernate-Core Fisheye repo. They
> want to "watch it for a couple of days to see how the performance is", then
> they will re-enable the others.
>
>
> On Mon 26 Sep 2011 08:36:16 AM CDT, Steve Ebersole wrote:
>>
>> Yeah I am aware. I have been working with Atlassian/Contegix to get that
>> working again.
>>
>> On Sun 25 Sep 2011 12:32:41 PM CDT, Gunnar Morling wrote:
>>>
>>> Hi,
>>>
>>> I just noticed that the connection between JIRA issues and the
>>> associated sources in FishEye/GitHub seems to be broken.
>>>
>>> Taking HHH-5938 as example, the "GitHub" tab [1] is empty while the
>>> "Source" tab [2] displays the following error message:
>>>
>>> ===
>>> Repository Hibernate-Core on http://fisheye2.atlassian.com/ failed:
>>> Error in remote call to 'FishEye 0 (http://fisheye2.atlassian.com/)'
>>> (http://fisheye2.atlassian.com)
>>> [AbstractRestCommand{path='api/rest/query', params={query=select
>>> revisions from dir / where comment matches 'HHH-5938' order by date
>>> group by changeset return csid, rep=Hibernate-Core}, methodType=POST}]
>>> : repository not in correct state: Repository is stopped
>>> ===
>>>
>>> Does anybody know what the cause is or whom to address in order to
>>> have this fixed?
>>>
>>> Apologies in case the issue is already known/being worked on.
>>>
>>> --Gunnar
>>>
>>> [1]
>>> https://hibernate.onjira.com/browse/HHH-5938?page=com.atlassian.jira.plugins.jira-github-connector-plugin%3Agithub-commits-tabpanel#issue-tabs
>>> [2]
>>> https://hibernate.onjira.com/browse/HHH-5938?page=com.atlassian.jirafisheyeplugin%3Afisheye-issuepanel#issue-tabs
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
> --
> st...@hibernate.org
> http://hibernate.org
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
