December 2014 - infinispan-issues

[JBoss JIRA] (ISPN-4421) Migration from jboss-as to wildfly arquillian-container-managed broke RollingUpgrades tests

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4421?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4421: ----------------------------------------------- Tomas Sykora <tsykora(a)redhat.com> changed the Status of [bug 1111186|https://bugzilla.redhat.com/show_bug.cgi?id=1111186] from NEW to CLOSED > Migration from jboss-as to wildfly arquillian-container-managed broke RollingUpgrades tests > ------------------------------------------------------------------------------------------- > > Key: ISPN-4421 > URL: https://issues.jboss.org/browse/ISPN-4421 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 7.0.0.Alpha4 > Reporter: Tomas Sykora > Assignee: Tomas Sykora > Labels: test_suite, testsuite_stability > Fix For: 7.0.0.CR1 > > > Server was rebased to Wildfly. > For Arquillian, jboss-as-arquillian-container-managed was changed to wildfly-arquillian-container-managed in order to reflect respective changes. > The problem for Rolling Upgrade tests ( -Psuite.rolling.upgrades ) is that there are used also old server instances in those tests. > Due to new changes in infinispan-arquillian-container old Infinispan servers are not properly managed during their startup phase. > Observation: > Switching port to 10099 (wildfly is using 10090 for mgmt ops) does not help. Strange message is continuously showing until timeout: > 13:41:57,691 ERROR [org.jboss.remoting.remote.connection] (Remoting "node1:MANAGEMENT" read-1) JBREM000200: Remote connection failed: java.io.IOException: Received an invalid message length of 1195725856 > "Experiment" with setting up <property name="managementProtocol">remoting-jmx</property> for OLD server in arquillian.xml didn't help either, however, ERROR message ^ disappeared. > But the server can't start properly, better to say, it starts, but Arquillian is not able to handle it properly and communicate: > testHotRodRollingUpgradesDiffVersions(org.infinispan.server.test.rollingupgrades.HotRodRollingUpgradesIT) Time elapsed: 60.389 sec <<< ERROR! > org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container > at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:204) > at org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:112) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > 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:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > 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:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.container.ClientContainerController.start(ClientContainerController.java:93) > at org.infinispan.server.test.rollingupgrades.HotRodRollingUpgradesIT.testHotRodRollingUpgradesDiffVersions(HotRodRollingUpgradesIT.java:68) > It looks like we need to somehow create a "bridge" or "switch" which will allow operations for both old and new servers in one test. > Or maybe I'm missing something important. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5043) Composite Key caching problem when deploying multiple applications in a single Jboss Application Server using Infinispan (classloader issues).

by Stijn Vlaes (JIRA)

[ https://issues.jboss.org/browse/ISPN-5043?page=com.atlassian.jira.plugin.... ] Stijn Vlaes updated ISPN-5043: ------------------------------ Attachment: cachingtest_final.rar Example project to reproduce the problem. > Composite Key caching problem when deploying multiple applications in a single Jboss Application Server using Infinispan (classloader issues). > ---------------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-5043 > URL: https://issues.jboss.org/browse/ISPN-5043 > Project: Infinispan > Issue Type: Bug > Components: Core, Server > Affects Versions: 5.2.1.Final > Environment: JBOSS AS 7.2.0.FINAL, Windows 7/Linux, Spring framework 4.1.1 > Infinispan/Hibernate versions included in JBoss AS > Reporter: Stijn Vlaes > Attachments: cachingtest_final.rar > > > While developing our applications we encountered a problem with the use of Composite ID's when using Hibernate with Infinispan causing us to have classcast exceptions like the following: > Request processing failed; nested exception is org.hibernate.PropertyAccessException: could not get a field value by reflection getter of be.vaph.cachingtest.common.barema.Barema.wettelijkeFunctieCode. > Our setup: > - 2 applications (1 with a rest interface, 1 with a web interface) > - Both applications use the same bussiness logic and data (same database, pojo's, ...) > - Both applications are deployed on the same Jboss AS, with infinispan configured in jboss and thus shared between the 2 applications. > Let's take the following example: > - Jboss AS 7 runs infinispan on its own main ClassLoader A and gives each application running on it it's own classloader. > - App 1 (rest) uses ClassLoader B. > - App 2 (web) uses ClassLoader C. > - App 1 does a query for some pojo's en puts these in the cache (using a composite key). > - App 2 does the same query and since it notices these pojo's are available in its cache and tries to load them. > The problem: > App 2 gets an exception, saying it can't cast the key to a key of the correct type. We discovered in the above case, that infinispan stored the instance of the key that was created while loading the object in app 1. Because this key is made in app 1 it was created by a different classloader then the one currently used by app 2. This causes the above exception, since the code thinks the found key isn't of the correct type. > As a side note: we have also encountered this issue with enumerations in keys, which are also created by a specific classloader, and thus bound to it. > Included is an example project made with Spring Boot to simulate the problem we are having. The example contains a single application that is configured to be deployed twice on a single jboss AS server. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5043) Composite Key caching problem when deploying multiple applications in a single Jboss Application Server using Infinispan (classloader issues).

by Stijn Vlaes (JIRA)

Stijn Vlaes created ISPN-5043: --------------------------------- Summary: Composite Key caching problem when deploying multiple applications in a single Jboss Application Server using Infinispan (classloader issues). Key: ISPN-5043 URL: https://issues.jboss.org/browse/ISPN-5043 Project: Infinispan Issue Type: Bug Components: Core, Server Affects Versions: 5.2.1.Final Environment: JBOSS AS 7.2.0.FINAL, Windows 7/Linux, Spring framework 4.1.1 Infinispan/Hibernate versions included in JBoss AS Reporter: Stijn Vlaes While developing our applications we encountered a problem with the use of Composite ID's when using Hibernate with Infinispan causing us to have classcast exceptions like the following: Request processing failed; nested exception is org.hibernate.PropertyAccessException: could not get a field value by reflection getter of be.vaph.cachingtest.common.barema.Barema.wettelijkeFunctieCode. Our setup: - 2 applications (1 with a rest interface, 1 with a web interface) - Both applications use the same bussiness logic and data (same database, pojo's, ...) - Both applications are deployed on the same Jboss AS, with infinispan configured in jboss and thus shared between the 2 applications. Let's take the following example: - Jboss AS 7 runs infinispan on its own main ClassLoader A and gives each application running on it it's own classloader. - App 1 (rest) uses ClassLoader B. - App 2 (web) uses ClassLoader C. - App 1 does a query for some pojo's en puts these in the cache (using a composite key). - App 2 does the same query and since it notices these pojo's are available in its cache and tries to load them. The problem: App 2 gets an exception, saying it can't cast the key to a key of the correct type. We discovered in the above case, that infinispan stored the instance of the key that was created while loading the object in app 1. Because this key is made in app 1 it was created by a different classloader then the one currently used by app 2. This causes the above exception, since the code thinks the found key isn't of the correct type. As a side note: we have also encountered this issue with enumerations in keys, which are also created by a specific classloader, and thus bound to it. Included is an example project made with Spring Boot to simulate the problem we are having. The example contains a single application that is configured to be deployed twice on a single jboss AS server. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5035) DeltaAware support for conditional operations

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5035?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-5035: ------------------------------------ I don't think put operations should be allowed to return arbitrary values, depending on the type of the value inserted into the cache. Couldn't you use {{DistributedExecutorService.submit(task, key)}} instead? > DeltaAware support for conditional operations > --------------------------------------------- > > Key: ISPN-5035 > URL: https://issues.jboss.org/browse/ISPN-5035 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Radim Vansa > > Current delta-aware approach is implemented only in PutKeyValueCommand and ApplyDeltaCommand. This implementation does not allow to execute conditional delta-aware commands - or rather it does not allow to return any kind of value (the condition itself can be implemented inside the delta). > One use-case when this would be required is equivalent of AtomicLong.getAndIncrement(). Currently we can implement this using > {code} > Long previous; > do { > previous = cache.get(key); > } while (cache.replace(key, previous, previous + 1); > {code} > which requires at least two RPCs. With more generic interface, such as JCache's EntryProcessor this could be implemented using single RPC. > (so, this JIRA is basically a request to native support for EntryProcessor) -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5035) DeltaAware support for conditional operations

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5035?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5035: ------------------------------- Status: Open (was: New) > DeltaAware support for conditional operations > --------------------------------------------- > > Key: ISPN-5035 > URL: https://issues.jboss.org/browse/ISPN-5035 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Radim Vansa > > Current delta-aware approach is implemented only in PutKeyValueCommand and ApplyDeltaCommand. This implementation does not allow to execute conditional delta-aware commands - or rather it does not allow to return any kind of value (the condition itself can be implemented inside the delta). > One use-case when this would be required is equivalent of AtomicLong.getAndIncrement(). Currently we can implement this using > {code} > Long previous; > do { > previous = cache.get(key); > } while (cache.replace(key, previous, previous + 1); > {code} > which requires at least two RPCs. With more generic interface, such as JCache's EntryProcessor this could be implemented using single RPC. > (so, this JIRA is basically a request to native support for EntryProcessor) -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5037) Do not replicate value from backup owner

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5037?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5037: ------------------------------- Status: Open (was: New) > Do not replicate value from backup owner > ---------------------------------------- > > Key: ISPN-5037 > URL: https://issues.jboss.org/browse/ISPN-5037 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Radim Vansa > > When a write is replicated from primary owner to backup owner, the backup owner returns the old value. This is unnecessary as the primary owner ignores this value, and introduces networking and marshalling overhead. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5037) Do not replicate value from backup owner

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5037?page=com.atlassian.jira.plugin.... ] Dan Berindei reassigned ISPN-5037: ---------------------------------- Assignee: Dan Berindei > Do not replicate value from backup owner > ---------------------------------------- > > Key: ISPN-5037 > URL: https://issues.jboss.org/browse/ISPN-5037 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Radim Vansa > Assignee: Dan Berindei > > When a write is replicated from primary owner to backup owner, the backup owner returns the old value. This is unnecessary as the primary owner ignores this value, and introduces networking and marshalling overhead. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5042) Remote gets caused by writes could be replicated only to the primary owner

by Dan Berindei (JIRA)

Dan Berindei created ISPN-5042: ---------------------------------- Summary: Remote gets caused by writes could be replicated only to the primary owner Key: ISPN-5042 URL: https://issues.jboss.org/browse/ISPN-5042 Project: Infinispan Issue Type: Enhancement Components: Core, State Transfer Affects Versions: 7.1.0.Alpha1 Reporter: Dan Berindei Priority: Minor Fix For: 7.1.0.Final For write operations that need the previous value, a write CH-only owner that doesn't have a key locally will attempt to retrieve the key from the read CH-owners. Sending the remote get command to all the previous owners will create extra load on the cluster during state transfer, so it should be more efficient to send the remote get only to the primary owner. Even though the latency of some write operations will be higher, the average latency should be better. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4657) Allow for customization of SearchWorkCreator used by the QueryInterceptor

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4657?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4657: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1167874|https://bugzilla.redhat.com/show_bug.cgi?id=1167874] from MODIFIED to ON_QA > Allow for customization of SearchWorkCreator used by the QueryInterceptor > ------------------------------------------------------------------------- > > Key: ISPN-4657 > URL: https://issues.jboss.org/browse/ISPN-4657 > Project: Infinispan > Issue Type: Feature Request > Components: Embedded Querying > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 7.0.0.Beta2 > > > Regression, setSearchCreator method removed since 6.0. > Capedwarf needs to be able to customize it. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4979) CacheStatusResponse map uses too much memory

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4979?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4979: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1163573|https://bugzilla.redhat.com/show_bug.cgi?id=1163573] from MODIFIED to ON_QA > CacheStatusResponse map uses too much memory > -------------------------------------------- > > Key: ISPN-4979 > URL: https://issues.jboss.org/browse/ISPN-4979 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.0.0.Final > Reporter: Dan Berindei > Assignee: William Burns > Priority: Critical > Fix For: 7.1.0.Alpha1, 7.1.0.Final > > > When the cluster is large and there are a log of caches, the {{CacheStatusResponse}} map on the new coordinator can get quite large. One of the problems that seems to be that the addresses in {{DefaultConsistentHash}} are duplicated on serialization, so the deserialized version occupies more memory. > We need to investigate why the objects are not "shared" by the River marshaller, and maybe work around the problem by de-duplicating the addresses in the externalizer. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2014