[JBoss JIRA] (ISPN-5062) Cross site state transfer - incorrect status of push operation
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5062?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5062:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1172034|https://bugzilla.redhat.com/show_bug.cgi?id=1172034] from VERIFIED to CLOSED
> Cross site state transfer - incorrect status of push operation
> ---------------------------------------------------------------
>
> Key: ISPN-5062
> URL: https://issues.jboss.org/browse/ISPN-5062
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 7.1.0.Alpha1
> Reporter: Matej Čimbora
> Assignee: Pedro Ruivo
> Fix For: 7.1.0.Beta1, 7.1.0.Final
>
>
> Status of push operation remains at value "CANCELLED" after the push operation was cancelled and reinvoked (even if state transfer is currently in progress) - "SENDING" value is expected. Otherwise works as expected (after the state transfer completes, status is switched to "OK").
> - Sites LON (lonCache) - main, BRN (brnCache) - backup
> Consider the following scenario:
> [standalone@localhost:9999 distributed-cache=lonCache] site --push BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --cancelpush BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=CANCELED
> [standalone@localhost:9999 distributed-cache=lonCache] site --push BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=CANCELED
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=OK
> Expected behavior:
> [standalone@localhost:9999 distributed-cache=lonCache] site --push BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --cancelpush BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=CANCELED
> [standalone@localhost:9999 distributed-cache=lonCache] site --push BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=SENDING
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=OK
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (ISPN-4499) Prevent shadowing user-defined jgroups configuration file
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4499?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4499:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1115555|https://bugzilla.redhat.com/show_bug.cgi?id=1115555] from VERIFIED to CLOSED
> Prevent shadowing user-defined jgroups configuration file
> ---------------------------------------------------------
>
> Key: ISPN-4499
> URL: https://issues.jboss.org/browse/ISPN-4499
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration
> Affects Versions: 7.0.0.Alpha4
> Reporter: Martin Gencur
> Assignee: Martin Gencur
> Fix For: 7.0.0.Alpha5
>
>
> When users create their own JGroups configuration file and name it the same way as default configuration files (jgroups-udp.xml / jgroups-tcp-xml / jgroups-ec2.xml), they might not be visible to the user application as they're shadowed by the default configuration files.
> Proposed solution:
> * place current jgroups configuration files into META-INF/configs folder (this folder doesn't have to have an obscure name such as "_internal" because of the following two points which complement the solution)
> * define order in which the config files are read by class loader (i.e. first scan user application, then path under META-INF/configs)
> * when Infinispan is started, log the path to the configuration file used, e.g.:
> {code}
> 2014-06-12 06:45:02,871 [thread-name] INFO [package-name] Using JGroups configuration file 'jar:META-INF/example_configurations/jgroups/udp.xml'
> 2014-06-12 06:45:02,871 [thread-name] INFO [package-name] Using JGroups configuration file 'file:/app_home/config/jgroups-udp.xml'
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (ISPN-4499) Prevent shadowing user-defined jgroups configuration file
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4499?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4499:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1115555|https://bugzilla.redhat.com/show_bug.cgi?id=1115555] from VERIFIED to CLOSED
> Prevent shadowing user-defined jgroups configuration file
> ---------------------------------------------------------
>
> Key: ISPN-4499
> URL: https://issues.jboss.org/browse/ISPN-4499
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration
> Affects Versions: 7.0.0.Alpha4
> Reporter: Martin Gencur
> Assignee: Martin Gencur
> Fix For: 7.0.0.Alpha5
>
>
> When users create their own JGroups configuration file and name it the same way as default configuration files (jgroups-udp.xml / jgroups-tcp-xml / jgroups-ec2.xml), they might not be visible to the user application as they're shadowed by the default configuration files.
> Proposed solution:
> * place current jgroups configuration files into META-INF/configs folder (this folder doesn't have to have an obscure name such as "_internal" because of the following two points which complement the solution)
> * define order in which the config files are read by class loader (i.e. first scan user application, then path under META-INF/configs)
> * when Infinispan is started, log the path to the configuration file used, e.g.:
> {code}
> 2014-06-12 06:45:02,871 [thread-name] INFO [package-name] Using JGroups configuration file 'jar:META-INF/example_configurations/jgroups/udp.xml'
> 2014-06-12 06:45:02,871 [thread-name] INFO [package-name] Using JGroups configuration file 'file:/app_home/config/jgroups-udp.xml'
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (ISPN-4499) Prevent shadowing user-defined jgroups configuration file
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4499?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4499:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1115555|https://bugzilla.redhat.com/show_bug.cgi?id=1115555] from VERIFIED to CLOSED
> Prevent shadowing user-defined jgroups configuration file
> ---------------------------------------------------------
>
> Key: ISPN-4499
> URL: https://issues.jboss.org/browse/ISPN-4499
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration
> Affects Versions: 7.0.0.Alpha4
> Reporter: Martin Gencur
> Assignee: Martin Gencur
> Fix For: 7.0.0.Alpha5
>
>
> When users create their own JGroups configuration file and name it the same way as default configuration files (jgroups-udp.xml / jgroups-tcp-xml / jgroups-ec2.xml), they might not be visible to the user application as they're shadowed by the default configuration files.
> Proposed solution:
> * place current jgroups configuration files into META-INF/configs folder (this folder doesn't have to have an obscure name such as "_internal" because of the following two points which complement the solution)
> * define order in which the config files are read by class loader (i.e. first scan user application, then path under META-INF/configs)
> * when Infinispan is started, log the path to the configuration file used, e.g.:
> {code}
> 2014-06-12 06:45:02,871 [thread-name] INFO [package-name] Using JGroups configuration file 'jar:META-INF/example_configurations/jgroups/udp.xml'
> 2014-06-12 06:45:02,871 [thread-name] INFO [package-name] Using JGroups configuration file 'file:/app_home/config/jgroups-udp.xml'
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (ISPN-4710) DistributedSegmentReadLocker should be allowed to skip ReadLocks on small files
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4710?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4710:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1166865|https://bugzilla.redhat.com/show_bug.cgi?id=1166865] from VERIFIED to CLOSED
> DistributedSegmentReadLocker should be allowed to skip ReadLocks on small files
> -------------------------------------------------------------------------------
>
> Key: ISPN-4710
> URL: https://issues.jboss.org/browse/ISPN-4710
> Project: Infinispan
> Issue Type: Enhancement
> Components: Lucene Directory
> Reporter: Sanne Grinovero
> Assignee: Gustavo Fernandes
> Fix For: 7.0.0.CR1
>
>
> Both of these methods:
> - {{org.infinispan.lucene.readlocks.DistributedSegmentReadLocker.deleteOrReleaseReadLock(String)}}
> - {{org.infinispan.lucene.readlocks.DistributedSegmentReadLocker.realFileDelete(FileReadLockKey, AdvancedCache<Object, Integer>, AdvancedCache<?, ?>, AdvancedCache<?, ?>, boolean)}}
> Are performing a lot of unnecessary operations - potentially on synchronous clustered caches - as we know in advance that files which are not being chunked don't need a read lock, and are not being chunked in smaller pieces (which affects how we delete things).
> The determining factor between the two styles is defined in:
> {{org.infinispan.lucene.impl.DirectoryLuceneV4.openInput(String, IOContext)}}
> {code} @Override
> public IndexInput openInput(final String name, final IOContext context) throws IOException {
> final IndexInputContext indexInputContext = impl.openInput(name);
> if ( indexInputContext.readLocks == null ) {
> return new SingleChunkIndexInput(indexInputContext);
> }
> else {
> return new InfinispanIndexInput(indexInputContext);
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (ISPN-4497) Race condition in LocalLockMergingSegmentReadLocker results in file content being deleted
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4497?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4497:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1166865|https://bugzilla.redhat.com/show_bug.cgi?id=1166865] from VERIFIED to CLOSED
> Race condition in LocalLockMergingSegmentReadLocker results in file content being deleted
> -----------------------------------------------------------------------------------------
>
> Key: ISPN-4497
> URL: https://issues.jboss.org/browse/ISPN-4497
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 5.2.6.Final
> Reporter: Anuj Shah
> Assignee: Sanne Grinovero
> Fix For: 7.0.0.Alpha5
>
>
> There is a race condition in LocalLockMergingSegmentReadLocker which can lead to more calls delete on the underlying DistributedSegmentReadLocker which results in the file being removed from the caches.
> This happens with three or more threads acquiring and releasing locks on the same file simultaneously:
> # Thread 1 (T1) acquires a lock and creates a {{LocalReadLock}}, call it L1 - the underlying lock is acquired
> # T2 starts to acquire and holds a reference to L1
> # T3 starts to acquire and holds a reference to L1
> # T1 releases - L1 at this stage only has value of 1 - so the underlying lock is released, and L1 is removed from the map
> # T2 continues - finds L1 with value 0 and acquires the underlying lock
> # T3 continues - increments L1 value to 2
> # T2 releases - creates a new {{LocalReadLock}}, L2 - this has zero value so the underlying lock is released, and L2 is removed from the map
> # T3 releases - creates a new {{LocalReadLock}}, L3 - this has zero value so the underlying lock is released, and L3 is removed from the map
> # The final step triggers a real file delete as underlying lock is released one too many times
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (ISPN-5149) Nested field is reported as non-indexed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5149?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5149:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1183322|https://bugzilla.redhat.com/show_bug.cgi?id=1183322] from VERIFIED to CLOSED
> Nested field is reported as non-indexed
> ---------------------------------------
>
> Key: ISPN-5149
> URL: https://issues.jboss.org/browse/ISPN-5149
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Querying
> Affects Versions: 7.1.0.Beta1
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 7.1.0.Final
>
>
> Steps to reproduce:
> 1. use the remote-query quickstart app (https://github.com/jboss-developer/jboss-jdg-quickstarts/tree/master/remo...) with an indexed cache config to add a Person and then a Memo object that has the Person as author.
> 2. try to query memos by author -> you get this exception
> {code}
> Jan 14, 2015 4:13:52 PM org.infinispan.client.hotrod.impl.protocol.Codec20 checkForErrorsInResponseStatus
> WARN: ISPN004005: Error received from the server: java.lang.IllegalArgumentException: Field author.name from type quickstart.Memo is not indexed
> org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[14] returned server error (status=0x85): java.lang.IllegalArgumentException: Field author.name from type quickstart.Memo is not indexed
> at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:321)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:111)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:97)
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56)
> at org.infinispan.client.hotrod.impl.operations.QueryOperation.executeOperation(QueryOperation.java:57)
> at org.infinispan.client.hotrod.impl.operations.QueryOperation.executeOperation(QueryOperation.java:24)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:50)
> at org.infinispan.client.hotrod.impl.query.RemoteQuery.executeQuery(RemoteQuery.java:72)
> at org.infinispan.client.hotrod.impl.query.RemoteQuery.list(RemoteQuery.java:62)
> at org.jboss.as.quickstarts.datagrid.hotrod.query.AddressBookManager.queryMemoByAuthor(AddressBookManager.java:285)
> at org.jboss.as.quickstarts.datagrid.hotrod.query.AddressBookManager.main(AddressBookManager.java:328)
> 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
> >
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (ISPN-5149) Nested field is reported as non-indexed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5149?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5149:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1183322|https://bugzilla.redhat.com/show_bug.cgi?id=1183322] from VERIFIED to CLOSED
> Nested field is reported as non-indexed
> ---------------------------------------
>
> Key: ISPN-5149
> URL: https://issues.jboss.org/browse/ISPN-5149
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Querying
> Affects Versions: 7.1.0.Beta1
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 7.1.0.Final
>
>
> Steps to reproduce:
> 1. use the remote-query quickstart app (https://github.com/jboss-developer/jboss-jdg-quickstarts/tree/master/remo...) with an indexed cache config to add a Person and then a Memo object that has the Person as author.
> 2. try to query memos by author -> you get this exception
> {code}
> Jan 14, 2015 4:13:52 PM org.infinispan.client.hotrod.impl.protocol.Codec20 checkForErrorsInResponseStatus
> WARN: ISPN004005: Error received from the server: java.lang.IllegalArgumentException: Field author.name from type quickstart.Memo is not indexed
> org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[14] returned server error (status=0x85): java.lang.IllegalArgumentException: Field author.name from type quickstart.Memo is not indexed
> at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:321)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:111)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:97)
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56)
> at org.infinispan.client.hotrod.impl.operations.QueryOperation.executeOperation(QueryOperation.java:57)
> at org.infinispan.client.hotrod.impl.operations.QueryOperation.executeOperation(QueryOperation.java:24)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:50)
> at org.infinispan.client.hotrod.impl.query.RemoteQuery.executeQuery(RemoteQuery.java:72)
> at org.infinispan.client.hotrod.impl.query.RemoteQuery.list(RemoteQuery.java:62)
> at org.jboss.as.quickstarts.datagrid.hotrod.query.AddressBookManager.queryMemoByAuthor(AddressBookManager.java:285)
> at org.jboss.as.quickstarts.datagrid.hotrod.query.AddressBookManager.main(AddressBookManager.java:328)
> 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
> >
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (ISPN-4654) AND over range queries does not work (indexless query)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4654?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4654:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1139650|https://bugzilla.redhat.com/show_bug.cgi?id=1139650] from VERIFIED to CLOSED
> AND over range queries does not work (indexless query)
> ------------------------------------------------------
>
> Key: ISPN-4654
> URL: https://issues.jboss.org/browse/ISPN-4654
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying, Remote Querying
> Affects Versions: 6.0.2.Final, 7.0.0.Beta1
> Reporter: Radim Vansa
> Assignee: Adrian Nistor
> Fix For: 7.0.0.Beta2
>
>
> Check this in QueryDslConditionsTest:
> {code}
> public void testAnd5() throws Exception {
> QueryFactory qf = getQueryFactory();
> // range queries use different code
> Query q = qf.from(getModelFactory().getUserImplClass())
> .having("id").lt(1000)
> .and().having("age").lt(1000)
> .toBuilder().build();
> List<User> list = q.list();
> assertEquals(3, list.size());
> }
> {code}
> The problem is that some subscription gets suspended and the second LT does not fire the second predicate update (and then neither the AND reevaluation).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months