[JBoss JIRA] (ISPN-4590) Update Hibernate ORM to 4.3.6.Final
by Sanne Grinovero (JIRA)
Sanne Grinovero created ISPN-4590:
-------------------------------------
Summary: Update Hibernate ORM to 4.3.6.Final
Key: ISPN-4590
URL: https://issues.jboss.org/browse/ISPN-4590
Project: Infinispan
Issue Type: Component Upgrade
Security Level: Public (Everyone can see)
Components: Loaders and Stores
Reporter: Sanne Grinovero
Assignee: Sanne Grinovero
Priority: Minor
Fix For: 7.0.0.Beta1
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4584) Stricter validation of cache configurations for distributed indexes
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-4584?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes edited comment on ISPN-4584 at 7/31/14 5:43 AM:
------------------------------------------------------------------
I was thinking in a typesafe config to serve to both power users and beginners. It would make validation easier at the same time controlling what is exposed or not (I think there are currently +30 possible properties that can be used)
Minimally for disk indexes:
{code:xml}
<indexing>
<storage>
<filesystem/>
</storage>
</indexing>
{code}
Minimally for infinispan indexes:
{code:xml}
<indexing>
<storage>
<infinispan/>
</storage>
</indexing>
{code}
Dr. Manhattan version:
{code:xml}
<indexing>
<storage>
<infinispan>
<metadata-storage>
<distributed-cache name="superFancyMetadataStorage" mode="SYNC" segments="20" owners="2" remote-timeout="30000" start="EAGER">
<locking acquire-timeout="30000" concurrency-level="1000" striping="false" />
<transaction mode="NONE" />
</distributed-cache>
</metadataStorage>
<data-storage>
<replicated-cache name="jackpotTimeout" mode="SYNC" remote-timeout="17501">
<state-transfer timeout="60000" enabled="true"/>
</replicated-cache>
</data-storage>
<lock-storage>
...
</lock-storage>
</infinispan>
</storage>
<reader strategy="shared"/>
<writer>
<merge min-size="1000" max-size="10000" max-queue-length="10000"/>
<worker type="ASYNC">
<thread-pool size="10">
<queue max="1000"/>
</thread-pool>
</worker>
</writer>
</indexing>
{code}
and for compatibility, allowing it mutually exclusive with the above configs
{code:xml}
<indexing>
<properties>...</properties>
</indexing>
{code}
finally for "don't bother me, index it already!" users:
{code:xml}
<indexing auto-config="true">
</indexing>
{code}
was (Author: gustavonalle):
I was thinking in a typesafe config to serve to both power users and beginners. It would make validation easier at the same time controlling what is exposed or not (I think there are currently +30 possible properties that can be used)
Minimally for disk indexes:
{code:xml}
<indexing>
<storage>
<filesystem/>
</storage>
</indexing>
{code}
Minimally for infinispan indexes:
{code:xml}
<indexing>
<storage>
<infinispan/>
</storage>
</indexing>
{code}
Dr. Manhattan version:
{code:xml}
<indexing>
<storage>
<infinispan>
<metadata-storage>
<distributed-cache name="superFancyMetadataStorage" mode="SYNC" segments="20" owners="2" remote-timeout="30000" start="EAGER">
<locking acquire-timeout="30000" concurrency-level="1000" striping="false" />
<transaction mode="NONE" />
</distributed-cache>
</metadataStorage>
<data-storage>
<replicated-cache name="jackpotTimeout" mode="SYNC" remote-timeout="17501">
<state-transfer timeout="60000" enabled="true"/>
</replicated-cache>
</data-storage>
<lock-storage>
...
</lock-storage>
</infinispan>
</storage>
<reader strategy="shared">
<worker type="ASYNC">
<thread-pool size="10">
<queue max="1000"/>
</thread-pool>
</worker>
</reader>
<writer>
<merge min-size="1000" max-size="10000" max-queue-length="10000"/>
</writer>
</indexing>
{code}
and for compatibility, allowing it mutually exclusive with the above configs
{code:xml}
<indexing>
<properties>...</properties>
</indexing>
{code}
finally for "don't bother me, index it already!" users:
{code:xml}
<indexing auto-config="true">
</indexing>
{code}
> Stricter validation of cache configurations for distributed indexes
> -------------------------------------------------------------------
>
> Key: ISPN-4584
> URL: https://issues.jboss.org/browse/ISPN-4584
> Project: Infinispan
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Lucene Directory
> Reporter: Sanne Grinovero
> Assignee: Gustavo Fernandes
> Priority: Minor
>
> See also ISPN-4577 : it should not be allowed to configure a distributed metadata cache while the chunks cache is using local mode.
> Ideally think of additional strict checks which we should apply.. suggestions?
> Mitigated by ISPN-4340
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4584) Stricter validation of cache configurations for distributed indexes
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-4584?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes edited comment on ISPN-4584 at 7/31/14 5:43 AM:
------------------------------------------------------------------
I was thinking in a typesafe config to serve to both power users and beginners. It would make validation easier at the same time controlling what is exposed or not (I think there are currently +30 possible properties that can be used)
Minimally for disk indexes:
{code:xml}
<indexing>
<storage>
<filesystem/>
</storage>
</indexing>
{code}
Minimally for infinispan indexes:
{code:xml}
<indexing>
<storage>
<infinispan/>
</storage>
</indexing>
{code}
Dr. Manhattan version:
{code:xml}
<indexing>
<storage>
<infinispan>
<metadata-storage>
<distributed-cache name="superFancyMetadataStorage" mode="SYNC" segments="20" owners="2" remote-timeout="30000" start="EAGER">
<locking acquire-timeout="30000" concurrency-level="1000" striping="false" />
<transaction mode="NONE" />
</distributed-cache>
</metadataStorage>
<data-storage>
<replicated-cache name="jackpotTimeout" mode="SYNC" remote-timeout="17501">
<state-transfer timeout="60000" enabled="true"/>
</replicated-cache>
</data-storage>
<lock-storage>
...
</lock-storage>
</infinispan>
</storage>
<reader strategy="shared"/>
<writer>
<merge min-size="1000" max-size="10000" max-queue-length="10000"/>
<worker type="ASYNC">
<thread-pool size="10"/>
<queue max="1000"/>
</worker>
</writer>
</indexing>
{code}
and for compatibility, allowing it mutually exclusive with the above configs
{code:xml}
<indexing>
<properties>...</properties>
</indexing>
{code}
finally for "don't bother me, index it already!" users:
{code:xml}
<indexing auto-config="true">
</indexing>
{code}
was (Author: gustavonalle):
I was thinking in a typesafe config to serve to both power users and beginners. It would make validation easier at the same time controlling what is exposed or not (I think there are currently +30 possible properties that can be used)
Minimally for disk indexes:
{code:xml}
<indexing>
<storage>
<filesystem/>
</storage>
</indexing>
{code}
Minimally for infinispan indexes:
{code:xml}
<indexing>
<storage>
<infinispan/>
</storage>
</indexing>
{code}
Dr. Manhattan version:
{code:xml}
<indexing>
<storage>
<infinispan>
<metadata-storage>
<distributed-cache name="superFancyMetadataStorage" mode="SYNC" segments="20" owners="2" remote-timeout="30000" start="EAGER">
<locking acquire-timeout="30000" concurrency-level="1000" striping="false" />
<transaction mode="NONE" />
</distributed-cache>
</metadataStorage>
<data-storage>
<replicated-cache name="jackpotTimeout" mode="SYNC" remote-timeout="17501">
<state-transfer timeout="60000" enabled="true"/>
</replicated-cache>
</data-storage>
<lock-storage>
...
</lock-storage>
</infinispan>
</storage>
<reader strategy="shared"/>
<writer>
<merge min-size="1000" max-size="10000" max-queue-length="10000"/>
<worker type="ASYNC">
<thread-pool size="10">
<queue max="1000"/>
</thread-pool>
</worker>
</writer>
</indexing>
{code}
and for compatibility, allowing it mutually exclusive with the above configs
{code:xml}
<indexing>
<properties>...</properties>
</indexing>
{code}
finally for "don't bother me, index it already!" users:
{code:xml}
<indexing auto-config="true">
</indexing>
{code}
> Stricter validation of cache configurations for distributed indexes
> -------------------------------------------------------------------
>
> Key: ISPN-4584
> URL: https://issues.jboss.org/browse/ISPN-4584
> Project: Infinispan
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Lucene Directory
> Reporter: Sanne Grinovero
> Assignee: Gustavo Fernandes
> Priority: Minor
>
> See also ISPN-4577 : it should not be allowed to configure a distributed metadata cache while the chunks cache is using local mode.
> Ideally think of additional strict checks which we should apply.. suggestions?
> Mitigated by ISPN-4340
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4584) Stricter validation of cache configurations for distributed indexes
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-4584?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes commented on ISPN-4584:
-----------------------------------------
I was thinking in a typesafe config to serve to both power users and beginners. It would make validation easier at the same time controlling what is exposed or not (I think there are currently +30 possible properties that can be used)
Minimally for disk indexes:
{code:xml}
<indexing>
<storage>
<filesystem/>
</storage>
</indexing>
{code}
Minimally for infinispan indexes:
{code:xml}
<indexing>
<storage>
<infinispan/>
</storage>
</indexing>
{code}
Dr. Manhattan version:
{code:xml}
<indexing>
<storage>
<infinispan>
<metadata-storage>
<distributed-cache name="superFancyMetadataStorage" mode="SYNC" segments="20" owners="2" remote-timeout="30000" start="EAGER">
<locking acquire-timeout="30000" concurrency-level="1000" striping="false" />
<transaction mode="NONE" />
</distributed-cache>
</metadataStorage>
<data-storage>
<replicated-cache name="jackpotTimeout" mode="SYNC" remote-timeout="17501">
<state-transfer timeout="60000" enabled="true"/>
</replicated-cache>
</data-storage>
<lock-storage>
...
</lock-storage>
</infinispan>
</storage>
<reader strategy="shared">
<worker type="ASYNC">
<thread-pool size="10">
<queue max="1000"/>
</thread-pool>
</worker>
</reader>
<writer>
<merge min-size="1000" max-size="10000" max-queue-length="10000"/>
</writer>
</indexing>
{code}
and for compatibility, allowing it mutually exclusive with the above configs
{code:xml}
<indexing>
<properties>...</properties>
</indexing>
{code}
finally for "don't bother me, index it already!" users:
{code:xml}
<indexing auto-config="true">
</indexing>
{code}
> Stricter validation of cache configurations for distributed indexes
> -------------------------------------------------------------------
>
> Key: ISPN-4584
> URL: https://issues.jboss.org/browse/ISPN-4584
> Project: Infinispan
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Lucene Directory
> Reporter: Sanne Grinovero
> Assignee: Gustavo Fernandes
> Priority: Minor
>
> See also ISPN-4577 : it should not be allowed to configure a distributed metadata cache while the chunks cache is using local mode.
> Ideally think of additional strict checks which we should apply.. suggestions?
> Mitigated by ISPN-4340
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4588) JpaConfigurationTest.testConfigBuilder fails in Karaf
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4588?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-4588:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Labels: testsuite_stability (was: )
Fix Version/s: 7.0.0.Beta1
Resolution: Done
> JpaConfigurationTest.testConfigBuilder fails in Karaf
> -----------------------------------------------------
>
> Key: ISPN-4588
> URL: https://issues.jboss.org/browse/ISPN-4588
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Ion Savin
> Assignee: Ion Savin
> Priority: Blocker
> Labels: testsuite_stability
> Fix For: 7.0.0.Beta1
>
>
> Exception reported while running in Karaf JpaConfigurationTest.testConfigBuilder
> {noformat}
> java.lang.IllegalArgumentException: port out of range:65536
> at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143)
> at java.net.InetSocketAddress.<init>(InetSocketAddress.java:185)
> at java.net.DatagramSocket.<init>(DatagramSocket.java:284)
> at org.jgroups.util.DefaultSocketFactory.createDatagramSocket(DefaultSocketFactory.java:62)
> at org.jgroups.protocols.UDP.createEphemeralDatagramSocket(UDP.java:429)
> at org.jgroups.protocols.UDP.createSockets(UDP.java:311)
> at org.jgroups.protocols.UDP.start(UDP.java:216)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
> at org.jgroups.JChannel.startStack(JChannel.java:889)
> at org.jgroups.JChannel._preConnect(JChannel.java:547)
> at org.jgroups.JChannel.connect(JChannel.java:282)
> at org.jgroups.JChannel.connect(JChannel.java:273)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:200)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:191)
> at sun.reflect.GeneratedMethodAccessor113.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:221)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:563)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:529)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:409)
> at org.infinispan.persistence.jpa.JpaConfigurationTest.testConfigBuilder(JpaConfigurationTest.java:52)
> at org.infinispan.it.osgi.persistence.jpa.JpaConfigurationTest.testConfigBuilder(JpaConfigurationTest.java:27)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:67)
> at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:37)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:124)
> at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.findAndInvoke(JUnitProbeInvoker.java:97)
> at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.call(JUnitProbeInvoker.java:73)
> at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
> at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
> at sun.rmi.transport.Transport$1.run(Transport.java:177)
> at sun.rmi.transport.Transport$1.run(Transport.java:174)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Related issue in jgroups: https://issues.jboss.org/browse/JGRP-1864
> The Karaf container is not using -Djava.net.preferIPv4Stack=true
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months