[JBoss JIRA] (ISPN-4679) OsgiClassLoader needs null check when iterating bundles
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4679?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4679:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1161349|https://bugzilla.redhat.com/show_bug.cgi?id=1161349] from VERIFIED to CLOSED
> OsgiClassLoader needs null check when iterating bundles
> -------------------------------------------------------
>
> Key: ISPN-4679
> URL: https://issues.jboss.org/browse/ISPN-4679
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.0.0.Beta1
> Reporter: Niels Bertram
> Assignee: Dan Berindei
> Priority: Minor
> Fix For: 7.0.0.Beta2, 7.0.0.Final
>
>
> {{org.infinispan.commons.util.OsgiClassLoader}} requires a null check when the bundle is retrieved from a WeakReference.
> {code:java}
> for (WeakReference<Bundle> ref : bundles) {
> final Bundle bundle = ref.get();
> // BUG: we may not get a bundle back from the weak reference, eg. if uninstalled or deactivated
> if (bundle.getState() == Bundle.ACTIVE) {
> try {
> final Class clazz = bundle.loadClass(name);
> if (clazz != null) {
> classCache.put(name, clazz);
> return clazz;
> }
> } catch (Exception ignore) {
> }
> }
> }
> {code}
> I am running 7.0.0.Beta1 on servicemix 5.1.1 and can't load this simple infinispan.xml:
> {code:xml}
> <infinispan xmlns="urn:infinispan:config:7.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="urn:infinispan:config:7.0 http://infinispan.org/schemas/infinispan-config-7.0.xsd">
> <cache-container default-cache="default" name="TestContainer">
> <jmx domain="TestDomain" mbean-server-lookup="org.infinispan.jmx.PerThreadMBeanServerLookup" duplicate-domains="true"/>
> <!-- definitions of the caches -->
> <local-cache name="default" statistics="false">
> <locking concurrency-level="100" acquire-timeout="1000"/>
> <transaction mode="NONE" complete-timeout="3123" reaper-interval="123"/>
> </local-cache>
> </cache-container>
> </infinispan>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-4828) Increasing default internal thread pool size
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4828?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4828:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1160635|https://bugzilla.redhat.com/show_bug.cgi?id=1160635] from VERIFIED to CLOSED
> Increasing default internal thread pool size
> --------------------------------------------
>
> Key: ISPN-4828
> URL: https://issues.jboss.org/browse/ISPN-4828
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration, Core
> Affects Versions: 7.0.0.CR1
> Reporter: Matej Čimbora
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 7.0.0.Final
>
>
> Using synchronous replication with high number of concurrent clients doing put() operations over a shared set of keys, lock-acquisition timeouts occur when various thread pools (internal, jgroups oob) do not have appropriate size.
> org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [3 seconds] on key [key_00000000000003B4] for requestor [Thread[OOB-66,default,node03-12795,5,main]]! Lock held by [Thread[OOB-314,default,node03-12795,5,main]]
> [org.infinispan.interceptors.InvocationContextInterceptor] (Stressor-1) ISPN000136: Execution error
> org.infinispan.util.concurrent.TimeoutException: org.infinispan.util.concurrent.TimeoutException: Node node04-24454 timed out
> This applies to both transactional and non-transactional configuration. The problem can be mitigated by increasing Infinispan's internal thread pool size (defined for remoteCommandsExecutor, blockingBoundedQueueThreadPool). In order to improve user experience either:
> a) When needed, the size of the thread pool should be increased as the load increases
> b) The default values should be high enough to handle even significant load (in terms of number of concurrent clients per node)
> c) The documentation should describe how the end user should size the thread pools based on expected load on the system
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-4766) Cache can't start if coordinator leaves during join and joiner becomes the new coordinator
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4766?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4766:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1148723|https://bugzilla.redhat.com/show_bug.cgi?id=1148723] from VERIFIED to CLOSED
> Cache can't start if coordinator leaves during join and joiner becomes the new coordinator
> ------------------------------------------------------------------------------------------
>
> Key: ISPN-4766
> URL: https://issues.jboss.org/browse/ISPN-4766
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.0.0.Beta2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Labels: testsuite_stability
> Fix For: 7.0.0.CR1
>
>
> When the joiner becomes the coordinator, it tries to recover the current cache topologies, but it receives just one expected member and no current topology. This causes a NPE in ClusterCacheStatus:
> {noformat}
> 22:51:49,547 ERROR (transport-thread-NodeB-p21124-t1:) [ClusterCacheStatus] ISPN000228: Failed to recover cache dist state after the current node became the coordinator
> java.lang.NullPointerException
> at org.infinispan.partionhandling.impl.PreferAvailabilityStrategy.onPartitionMerge(PreferAvailabilityStrategy.java:104)
> at org.infinispan.topology.ClusterCacheStatus.doMergePartitions(ClusterCacheStatus.java:452)
> at org.infinispan.topology.ClusterTopologyManagerImpl.recoverClusterStatus(ClusterTopologyManagerImpl.java:260)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:180)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener$1.run(ClusterTopologyManagerImpl.java:427)
> {noformat}
> The LocalTopologyManagerImpl waits a bit after receiving the SuspectException and tries again, but this time it receives a {{null}} initial topology, causing another NPE:
> {noformat}
> 22:51:51,319 DEBUG (testng-GlobalKeySetTaskTest:) [LocalTopologyManagerImpl] Error sending join request for cache dist to coordinator
> java.lang.NullPointerException
> at org.infinispan.topology.LocalTopologyManagerImpl.resetLocalTopologyBeforeRebalance(LocalTopologyManagerImpl.java:222)
> at org.infinispan.topology.LocalTopologyManagerImpl.handleTopologyUpdate(LocalTopologyManagerImpl.java:191)
> at org.infinispan.topology.LocalTopologyManagerImpl.join(LocalTopologyManagerImpl.java:105)
> at org.infinispan.statetransfer.StateTransferManagerImpl.start(StateTransferManagerImpl.java:108)
> {noformat}
> This keeps going on until the state transfer timeout expires.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-5023) Random Failues on *FactoryBeanTest in the Spring Modules
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5023?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5023:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1168609|https://bugzilla.redhat.com/show_bug.cgi?id=1168609] from VERIFIED to CLOSED
> Random Failues on *FactoryBeanTest in the Spring Modules
> --------------------------------------------------------
>
> Key: ISPN-5023
> URL: https://issues.jboss.org/browse/ISPN-5023
> Project: Infinispan
> Issue Type: Bug
> Components: Spring Integration
> Affects Versions: 7.0.2.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 7.1.0.Alpha1
>
>
> Example: http://ci.infinispan.org/viewLog.html?buildId=14526&tab=buildResultsDiv&b...
> {noformat}
> org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type JGroupsTransport
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:243)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:573)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:539)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:416)
> at org.infinispan.spring.support.embedded.InfinispanEmbeddedCacheManagerFactoryBeanTest$2.call(InfinispanEmbeddedCacheManagerFactoryBeanTest.java:82)
> at org.infinispan.test.TestingUtil.withCacheManager(TestingUtil.java:1321)
> at org.infinispan.spring.support.embedded.InfinispanEmbeddedCacheManagerFactoryBeanTest.infinispanEmbeddedCacheManagerFactoryBeanShouldCreateACustomizedCacheManagerIfGivenADefaultConfigurationLocation(InfinispanEmbeddedCacheManagerFactoryBeanTest.java:75)
> 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.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:348)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:38)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> 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)
> Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type JGroupsTransport
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:170)
> 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) ... 26 more
> Caused by: org.infinispan.commons.CacheException: Channel connected, but unable to register MBeans
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:216)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:190)
> 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.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168) ... 31 more
> Caused by: javax.management.MBeanRegistrationException: The @MBean objectName is not unique
> at org.jgroups.jmx.JmxConfigurator.internalRegister(JmxConfigurator.java:178)
> at org.jgroups.jmx.JmxConfigurator.register(JmxConfigurator.java:116)
> at org.jgroups.jmx.JmxConfigurator.registerChannel(JmxConfigurator.java:53)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:213) ... 37 more
> Caused by: javax.management.InstanceAlreadyExistsException: org.infinispan:type=protocol,cluster="infinispan-cluster",protocol=TCP
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at org.jgroups.jmx.JmxConfigurator.internalRegister(JmxConfigurator.java:175) ... 40 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-5089) Zero-divide ArithmeticException in org.infinispan.interceptors.CacheMgmtInterceptor.getAverageWriteTime()
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5089?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5089:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1174582|https://bugzilla.redhat.com/show_bug.cgi?id=1174582] from VERIFIED to CLOSED
> Zero-divide ArithmeticException in org.infinispan.interceptors.CacheMgmtInterceptor.getAverageWriteTime()
> ---------------------------------------------------------------------------------------------------------
>
> Key: ISPN-5089
> URL: https://issues.jboss.org/browse/ISPN-5089
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Environment: JDG 6.3.1 (Infinispan 6.1.1.Final) and the current master seems the same.
> Reporter: Osamu Nagano
> Assignee: Tristan Tarrant
> Fix For: 7.1.0.Beta1
>
>
> There are occasional {{java.lang.ArithmeticException: / by zero}} in server.log. It seems a part collecting statistics for MBean and they were actually collecting such data by JMX.
> {noformat}
> 2014-12-15 12:32:00.283 ERROR [org.infinispan.server.hotrod.HotRodDecoder] (HotRodServerWorker-491) ISPN005009: Unexpected error before any request parameters read: io.netty.handler.codec.DecoderException: org.infinispan.server.hotrod.HotRodException: java.lang.ArithmeticException: / by zero
> at io.netty.handler.codec.ReplayingDecoder.callDecode(ReplayingDecoder.java:417) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:141) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at org.infinispan.server.core.AbstractProtocolDecoder.channelRead(AbstractProtocolDecoder.scala:471) [infinispan.jar:6.1.1.Final-redhat-5]
> at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:341) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:327) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:785) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:116) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:494) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:461) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55]
> Caused by: org.infinispan.server.hotrod.HotRodException: java.lang.ArithmeticException: / by zero
> at org.infinispan.server.hotrod.HotRodDecoder.createServerException(HotRodDecoder.scala:206) [infinispan.jar:6.1.1.Final-redhat-5]
> at org.infinispan.server.core.AbstractProtocolDecoder.decodeDispatch(AbstractProtocolDecoder.scala:77) [infinispan.jar:6.1.1.Final-redhat-5]
> at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:61) [infinispan.jar:6.1.1.Final-redhat-5]
> at io.netty.handler.codec.ReplayingDecoder.callDecode(ReplayingDecoder.java:362) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> ... 12 more
> Caused by: java.lang.ArithmeticException: / by zero
> at org.infinispan.interceptors.CacheMgmtInterceptor.getAverageWriteTime(CacheMgmtInterceptor.java:294) [infinispan-core-6.1.1.Final-redhat-5.jar:6.1.1.Final-redhat-5]
> at org.infinispan.stats.StatsImpl.<init>(StatsImpl.java:48) [infinispan-core-6.1.1.Final-redhat-5.jar:6.1.1.Final-redhat-5]
> at org.infinispan.CacheImpl.getStats(CacheImpl.java:884) [infinispan-core-6.1.1.Final-redhat-5.jar:6.1.1.Final-redhat-5]
> at org.infinispan.AbstractDelegatingAdvancedCache.getStats(AbstractDelegatingAdvancedCache.java:173) [infinispan-core-6.1.1.Final-redhat-5.jar:6.1.1.Final-redhat-5]
> at org.infinispan.server.hotrod.HotRodDecoder.createStatsResponse(HotRodDecoder.scala:161) [infinispan.jar:6.1.1.Final-redhat-5]
> at org.infinispan.server.core.AbstractProtocolDecoder.decodeHeader(AbstractProtocolDecoder.scala:147) [infinispan.jar:6.1.1.Final-redhat-5]
> at org.infinispan.server.core.AbstractProtocolDecoder.decodeDispatch(AbstractProtocolDecoder.scala:70) [infinispan.jar:6.1.1.Final-redhat-5]
> ... 14 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-4500) Karaf cause OOME when running iOSGI integration tests on all environments
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4500?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4500:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1118593|https://bugzilla.redhat.com/show_bug.cgi?id=1118593] from VERIFIED to CLOSED
> Karaf cause OOME when running iOSGI integration tests on all environments
> -------------------------------------------------------------------------
>
> Key: ISPN-4500
> URL: https://issues.jboss.org/browse/ISPN-4500
> Project: Infinispan
> Issue Type: Bug
> Components: Integration
> Affects Versions: 7.0.0.Alpha3, 7.0.0.Alpha4
> Environment: Windows, Solaris, RHEL
> Reporter: Vitalii Chepeliuk
> Assignee: Ion Savin
> Labels: testsuite_stability
>
> Karaf is parsing XML file and can not fing closing </hr> tag. There should be no <hr> tag at all. Then it throws following exception
> {noformat}
> org.xml.sax.SAXParseException; lineNumber: 6; columnNumber: 3; The element type "hr" must be terminated by the matching end-tag "</hr>".
> at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
> at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
> at javax.xml.parsers.DocumentBuilder.parse(Unknown Source)
> at org.apache.karaf.features.internal.FeatureValidationUtil.validate(FeatureValidationUtil.java:52)
> at org.apache.karaf.features.internal.FeaturesServiceImpl.validateRepository(FeaturesServiceImpl.java:215)
> at org.apache.karaf.features.internal.FeaturesServiceImpl.internalAddRepository(FeaturesServiceImpl.java:257)
> at org.apache.karaf.features.internal.FeaturesServiceImpl.addRepository(FeaturesServiceImpl.java:237)
> at org.apache.karaf.features.internal.FeaturesServiceImpl.addRepository(FeaturesServiceImpl.java:225)
> at org.infinispan.it.osgi.features.OSGiKarafFeaturesTest.checkInstall(OSGiKarafFeaturesTest.java:87)
> at org.infinispan.it.osgi.features.OSGiKarafFeaturesTest.testCleanInstall(OSGiKarafFeaturesTest.java:71)
> 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.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.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
> 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 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:744)
> {noformat}
> Very often EOF Exceotion is thrown
> {noformat}
> java.io.EOFException
> at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2598)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1318)
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990)
> at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:500)
> at java.lang.Throwable.readObject(Throwable.java:914)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1017)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1893)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990)
> at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:500)
> at java.lang.Throwable.readObject(Throwable.java:914)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1017)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1893)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1915)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
> at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:244)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
> at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:194)
> at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:148)
> at com.sun.proxy.$Proxy20.remoteCall(Unknown Source)
> at org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl$1.invoke(RemoteBundleContextClientImpl.java:101)
> at com.sun.proxy.$Proxy21.call(Unknown Source)
> at org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl.call(RemoteBundleContextClientImpl.java:268)
> at org.ops4j.pax.exam.container.remote.RBCRemoteTarget.call(RBCRemoteTarget.java:65)
> at org.ops4j.pax.exam.karaf.container.internal.KarafTestContainer.call(KarafTestContainer.java:533)
> at org.ops4j.pax.exam.spi.reactors.SingletonStagedReactor.invoke(SingletonStagedReactor.java:113)
> at org.ops4j.pax.exam.spi.reactors.PerSuiteStagedReactor.invoke(PerSuiteStagedReactor.java:47)
> at org.ops4j.pax.exam.junit.impl.ProbeRunner$2.evaluate(ProbeRunner.java:278)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> 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.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:112)
> at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
> at org.junit.runners.Suite.runChild(Suite.java:127)
> at org.junit.runners.Suite.runChild(Suite.java:26)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> 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:744)
> {noformat}
> And finally is start to leak memory and end up with
> {noformat}
> java.lang.OutOfMemoryError: Java heap space
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-4359) Provide an annotation driven way of declaring protobuf metadata
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4359?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4359:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1172646|https://bugzilla.redhat.com/show_bug.cgi?id=1172646] from VERIFIED to CLOSED
> Provide an annotation driven way of declaring protobuf metadata
> ---------------------------------------------------------------
>
> Key: ISPN-4359
> URL: https://issues.jboss.org/browse/ISPN-4359
> Project: Infinispan
> Issue Type: Feature Request
> Components: Marshalling
> Affects Versions: 7.0.0.Alpha4
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Labels: jdg
> Fix For: 7.1.0.Beta1
>
>
> The main goal of this is to simply marshalling of java objects to protobuf using the Protostream library.
> Instead of providing a Protostream MessageMarshaller implementation and a proto schema file it would be nice to have an alternative way of just adding minimal annotations to a Java class (and its fields) to assist on the fly generation (via reflection) of the proto schema. The Protostream library should also infer the marshaller so it would not require a manually implemented one. The annotation should require minimal info (tag number) and the rest should be inferred based on common sense defaults (protobuf type, java collection type, collection element type ...) but should be possible to override. The auto-generated schema should be available to users and they should be able then to use it as reference if they need it to implement domain model classes and marshallers for other languages.
> The user should still be able to specify a manually created schema (besides the annotated classes) and in that case the Protostream library should check the auto-inferred schema against the provided one and ensure they match.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-4848) Offer way to implement includeCurrentState based on indexed query
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4848?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4848:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1160635|https://bugzilla.redhat.com/show_bug.cgi?id=1160635] from VERIFIED to CLOSED
> Offer way to implement includeCurrentState based on indexed query
> -----------------------------------------------------------------
>
> Key: ISPN-4848
> URL: https://issues.jboss.org/browse/ISPN-4848
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: Emmanuel Bernard
>
> Based on the infinispan-dev mailing list discussion from September 2014 titled
> 'Feedback and requests on clustered and remote listeners'.
> Loading the whole state of the data grid to then filter / convert them can be costly especially if data has been passivated.
> An alternative could be offered that would delegate the includeCurrentState filtering with a global indexed query. That query would need to be provided by the user. While the query is run, the list of change events matching should be piled up and released once the query has be run and the converted events are send to the clustered listener.
> Maybe that should be only done for "continuous" queries as we could use the query for both the initial and continuous side of the query transparently.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months