[JBoss JIRA] (ISPN-4630) DistributedEntryRetriever throws NPE if iterator is closed before processing all responses
by William Burns (JIRA)
William Burns created ISPN-4630:
-----------------------------------
Summary: DistributedEntryRetriever throws NPE if iterator is closed before processing all responses
Key: ISPN-4630
URL: https://issues.jboss.org/browse/ISPN-4630
Project: Infinispan
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Core
Affects Versions: 7.0.0.Alpha5
Reporter: William Burns
Assignee: William Burns
DistributedEntryRetriever itrerator needs to ignore responses from nodes if a iterator is closed early or if a rehash occurs causing some redundant requests to be sent.
This was covered in a previous version but refactoring lost it somehow and instead the code is using variables that cannot be null.
{code}
} else if (log.isTraceEnabled()) {
log.tracef("Ignoring values as identifier %s was marked as complete", identifier);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (ISPN-3950) Deploy user-code to Infinispan server
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3950?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-3950:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Deploy user-code to Infinispan server
> -------------------------------------
>
> Key: ISPN-3950
> URL: https://issues.jboss.org/browse/ISPN-3950
> Project: Infinispan
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Tristan Tarrant
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.Beta1, 7.0.0.Final
>
>
> Infinispan Server should allow deploying JARs which follow the standard Java service provider API.
> Support: groupers, listeners, map/reduce jobs, distexec jobs, interceptors, JPA entities, etc
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (ISPN-4626) Race condition in the LocalEntryRetriever between iterator() and hasNext()
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-4626?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-4626:
-------------------------------------
Integrated in master. Thanks!
> Race condition in the LocalEntryRetriever between iterator() and hasNext()
> --------------------------------------------------------------------------
>
> Key: ISPN-4626
> URL: https://issues.jboss.org/browse/ISPN-4626
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core
> Affects Versions: 7.0.0.Alpha5
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 7.0.0.Beta1
>
>
> The LocalEntryRetriver sometimes will erroneously return false for hasNext right after creation of the iterator, because initial retrieval is done on a separate thread and it may not finish on time.
> This is causing intermittent failures in the index-less query tests. See ISPN-4594
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (ISPN-4626) Race condition in the LocalEntryRetriever between iterator() and hasNext()
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-4626?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-4626:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 7.0.0.Beta1
Resolution: Done
> Race condition in the LocalEntryRetriever between iterator() and hasNext()
> --------------------------------------------------------------------------
>
> Key: ISPN-4626
> URL: https://issues.jboss.org/browse/ISPN-4626
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core
> Affects Versions: 7.0.0.Alpha5
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 7.0.0.Beta1
>
>
> The LocalEntryRetriver sometimes will erroneously return false for hasNext right after creation of the iterator, because initial retrieval is done on a separate thread and it may not finish on time.
> This is causing intermittent failures in the index-less query tests. See ISPN-4594
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (ISPN-4396) DSL Query: right condition lost
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4396?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4396:
-----------------------------------------------
Adrian Nistor <anistor(a)redhat.com> changed the Status of [bug 1108695|https://bugzilla.redhat.com/show_bug.cgi?id=1108695] from ASSIGNED to MODIFIED
> DSL Query: right condition lost
> -------------------------------
>
> Key: ISPN-4396
> URL: https://issues.jboss.org/browse/ISPN-4396
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Embedded Querying
> Affects Versions: 7.0.0.Alpha4
> Reporter: Radim Vansa
> Assignee: Adrian Nistor
> Fix For: 7.0.0.Alpha5
>
>
> Condition created through query like this:
> {code}
> Query q = qf.from(User.class)
> .not(
> qf.having("name").eq("John")
> .or(qf.having("surname").eq("Man")))
> .toBuilder().build();
> {code}
> is not correctly parsed into JPQL query; it is
> {code}
> FROM org.infinispan.query.dsl.embedded.sample_domain_model.User _gen0 WHERE NOT (_gen0.name = 'John')
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (ISPN-4396) DSL Query: right condition lost
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-4396?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-4396:
------------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> DSL Query: right condition lost
> -------------------------------
>
> Key: ISPN-4396
> URL: https://issues.jboss.org/browse/ISPN-4396
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Embedded Querying
> Affects Versions: 7.0.0.Alpha4
> Reporter: Radim Vansa
> Assignee: Adrian Nistor
> Fix For: 7.0.0.Alpha5
>
>
> Condition created through query like this:
> {code}
> Query q = qf.from(User.class)
> .not(
> qf.having("name").eq("John")
> .or(qf.having("surname").eq("Man")))
> .toBuilder().build();
> {code}
> is not correctly parsed into JPQL query; it is
> {code}
> FROM org.infinispan.query.dsl.embedded.sample_domain_model.User _gen0 WHERE NOT (_gen0.name = 'John')
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (ISPN-4627) QueryInterceptor start() event mutates the SearchFactory multiple times
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-4627?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-4627:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
Integrated in master. Thanks!
> QueryInterceptor start() event mutates the SearchFactory multiple times
> -----------------------------------------------------------------------
>
> Key: ISPN-4627
> URL: https://issues.jboss.org/browse/ISPN-4627
> Project: Infinispan
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Embedded Querying
> Reporter: Sanne Grinovero
> Assignee: Sanne Grinovero
> Priority: Minor
> Fix For: 7.0.0.Beta1
>
>
> Just spotted while reviewing unrelated patches:
> the {{@Start}} annotated method of component {{QueryInterceptor}} loops throught the known entries of the {{clusterRegistry}} field, and will reboot the {{SearchFactory}} once for each entry.
> It's important to use the capability to pass multiple class types at once when mutating the SearchFactory, as this is an extremely slow operation, and especially in this case, if it's a node joining an existing cluster we expect to see a considerable amount of indexed types (probably all of them).
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months