[JBoss JIRA] (ISPN-5626) Clean up missing parts for Distributed Streams
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5626?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-5626:
--------------------------------
Description:
There are some things left over that need to still be done possibly
# Investigate iterator parallel stream performance
# Add support for key filter applying to cache loader
# Add cache loader managed blocker
# Add tests for skip & limit.
# Add tests for containsValue requiring serialization overhead.
# Change isEmpty to use findAny
# Need to test a map/flatMap operation after an intermediate terminal operation such as sorted. This is to verify the iterator doesn't use the different map operation.
# Add timeout for remote operations to be equal to replication sync timeout
# Add new BitSetSet support to reduce segments footprint
# Support concurrent activations properly (this is also an issue with state transfer)
was:
There are some things left over that need to still be done possibly
# Investigate iterator parallel stream performance
# Add support for key filter applying to cache loader
# Add cache loader managed blocker
# Add tests for skip & limit.
# Add tests for containsValue requiring serialization overhead.
# Change isEmpty to use findAny
# Need to test a map/flatMap operation after an intermediate terminal operation such as sorted. This is to verify the iterator doesn't use the different map operation.
# Add timeout for remote operations to be equal to replication sync timeout
# Add new BitSetSet support to reduce segments footprint
> Clean up missing parts for Distributed Streams
> ----------------------------------------------
>
> Key: ISPN-5626
> URL: https://issues.jboss.org/browse/ISPN-5626
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Reporter: William Burns
> Assignee: William Burns
>
> There are some things left over that need to still be done possibly
> # Investigate iterator parallel stream performance
> # Add support for key filter applying to cache loader
> # Add cache loader managed blocker
> # Add tests for skip & limit.
> # Add tests for containsValue requiring serialization overhead.
> # Change isEmpty to use findAny
> # Need to test a map/flatMap operation after an intermediate terminal operation such as sorted. This is to verify the iterator doesn't use the different map operation.
> # Add timeout for remote operations to be equal to replication sync timeout
> # Add new BitSetSet support to reduce segments footprint
> # Support concurrent activations properly (this is also an issue with state transfer)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (ISPN-2976) Log4J dependencies in codebase to be cleaned up
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2976?page=com.atlassian.jira.plugin.... ]
Dan Berindei resolved ISPN-2976.
--------------------------------
Labels: (was: core)
Assignee: Tristan Tarrant
Fix Version/s: 8.0.0.Beta2
Resolution: Done
The dependencies in SampleConfigFilesCorrectnessTest, CompressedFileAppender, and ThreadNameFilter are required, but were updated to the log4j 2.0 SPI.
> Log4J dependencies in codebase to be cleaned up
> -----------------------------------------------
>
> Key: ISPN-2976
> URL: https://issues.jboss.org/browse/ISPN-2976
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 5.2.5.Final
> Reporter: Manik Surtani
> Assignee: Tristan Tarrant
> Fix For: 8.0.0.Beta2
>
>
> When attempting to move to Log4J 2.0, I've noticed a number of hard deps on log4j classes.
> {{SampleConfigFilesCorrectnessTest}} - this class makes use of a custom appender to analyse what a user is being warned of when a config file is parsed. Why are we using Log4J for this? Our own logging interface should be mocked and messages captured directly.
> {{RehashStressTest}} and {{NucleotideCache}} - seems like a bug, I presume the author intended to use {{org.infinispan.logging.Log}}.
> {{CompressedFileAppender}} and {{ThreadNameFilter}}- can this be written in a way that works with Log4J 1.x as well as 2.x? Or have the SPIs changed that much?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (ISPN-5626) Clean up missing parts for Distributed Streams
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5626?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-5626:
--------------------------------
Description:
There are some things left over that need to still be done possibly
# Investigate iterator parallel stream performance
# Add support for key filter applying to cache loader
# Add cache loader managed blocker
# Add tests for skip & limit.
# Add tests for containsValue requiring serialization overhead.
# Change isEmpty to use findAny
# Need to test a map/flatMap operation after an intermediate terminal operation such as sorted. This is to verify the iterator doesn't use the different map operation.
# Add timeout for remote operations to be equal to replication sync timeout
# Add new BitSetSet support to reduce segments footprint
was:
There are some things left over that need to still be done possibly
# Investigate iterator parallel stream performance
# Add support for key filter applying to cache loader
# Add cache loader managed blocker
# Add tests for skip & limit.
# Add tests for containsValue requiring serialization overhead.
# Change isEmpty to use findAny
# Need to test a map/flatMap operation after an intermediate terminal operation such as sorted. This is to verify the iterator doesn't use the different map operation.
# Add timeout to iterator to be equal to state transfer timeout.
# Add new BitSetSet support to reduce segments footprint
> Clean up missing parts for Distributed Streams
> ----------------------------------------------
>
> Key: ISPN-5626
> URL: https://issues.jboss.org/browse/ISPN-5626
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Reporter: William Burns
> Assignee: William Burns
>
> There are some things left over that need to still be done possibly
> # Investigate iterator parallel stream performance
> # Add support for key filter applying to cache loader
> # Add cache loader managed blocker
> # Add tests for skip & limit.
> # Add tests for containsValue requiring serialization overhead.
> # Change isEmpty to use findAny
> # Need to test a map/flatMap operation after an intermediate terminal operation such as sorted. This is to verify the iterator doesn't use the different map operation.
> # Add timeout for remote operations to be equal to replication sync timeout
> # Add new BitSetSet support to reduce segments footprint
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (ISPN-5633) Upgrade console to 8.0.0.Beta1
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-5633:
-------------------------------------
Summary: Upgrade console to 8.0.0.Beta1
Key: ISPN-5633
URL: https://issues.jboss.org/browse/ISPN-5633
Project: Infinispan
Issue Type: Component Upgrade
Components: Console
Affects Versions: 8.0.0.Beta1
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Fix For: 8.0.0.Beta2
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (ISPN-5561) Problem in dealing with the HQL queries that contain string comparison operations, when it involves empty string as an operand
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5561?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5561:
-----------------------------------------------
Adrian Nistor <anistor(a)redhat.com> changed the Status of [bug 1238866|https://bugzilla.redhat.com/show_bug.cgi?id=1238866] from MODIFIED to POST
> Problem in dealing with the HQL queries that contain string comparison operations, when it involves empty string as an operand
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-5561
> URL: https://issues.jboss.org/browse/ISPN-5561
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying, Remote Querying
> Affects Versions: 7.2.0.Final
> Environment: Infinispan version: Infinispan 7.2.0-Final
> Operating System: Linux
> Compatibility mode is enabled.
> Indexing is enabled and 'autoconfig' parameter is set to true.
> Reporter: Pavan Kundgol
> Assignee: Adrian Nistor
> Fix For: 8.0.0.Beta2, 7.2.4.Final, 8.0.0.Final
>
>
> When a HQL query that involves string comparison operation with the empty string matching is executed through hot rod client(java), it is resulting in the following error,
> org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[7] returned server error (status=0x85): org.hibernate.search.exception.EmptyQueryException: HSEARCH000146: The query string '' applied on field 'CITY' has no meaningful tokens to be matched. Validate the query input against the Analyzer applied on this field.
> The same problem may also occur when the string matching operation involves a string containing certain special keywords(hibernate search stop words), as operands.
> The problem seems to be assosiated with the the 'hibernate-hql-lucene' parser used by the 'infinispan-remote-query-server' module. The problem here is that the hibernate-hql-lucene parser is translating comparison operations directly into lucene keyword matching operations, irrespective of the field type, though the phrase matching is more appropriate for string fields. This leads to invalid query formation when the field in concern is of type string, and is matched against an empty string(or a string containing one or more hibernate search stop words).
> For example,
> the where condition city='' present in the following HQL query
> select name from com.test.User where city=''
> is tralated to lucene query, the hql-lucene parser is currently translating to
> queryBuilder.keyword().onField("city").matching("").createQuery()
> whereas recommended one is
> queryBuilder.phrase().onField("city").sentence("").createQuery()
> In the former way of translation, Hibernate Search query execution fails due to its usage of standard analyzer while executing the query. Hence, the problem can also be avoided by disabling the standard analyzer while executing the query.
> queryBuilder.keyword().onField("city").ignoreAnalyzer().matching("").createQuery()
> Preferred solution may be to enhance the 'hibernate-hql-lucene' library to do type specific translations, and to specifically translate the string comparison operations of hql query into phrase matching operations of lucene query(instead of keyword matching operations).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months