[JBoss JIRA] (ISPN-6247) Speed up DistWriteSkewTest and its subclasses
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6247?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-6247:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/4051
> Speed up DistWriteSkewTest and its subclasses
> ---------------------------------------------
>
> Key: ISPN-6247
> URL: https://issues.jboss.org/browse/ISPN-6247
> Project: Infinispan
> Issue Type: Task
> Components: Test Suite - Core
> Affects Versions: 8.2.0.Beta2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 8.2.0.CR1
>
>
> {{DistWriteSkewTest}} is annotated with {{@CleanupAfterMethod}}, so the cluster is recreated for each one of the test methods. Since there are a lot of test methods inherited from {{AbstractClusteredWriteSkewTest}}, the repeated cluster startup and shutdown add a lot of overhead.
> Since the test doesn't start or stop nodes, it should be possible to start the cluster only once for the whole class, eventually using different key names if leftover keys turn out to be a problem.
> The annotation is also used for {{ReplWriteSkewTest}}, {{DistL1WriteSkewTest}}, and {{DistTotalOrderWriteSkewTest}}. It should be possible to reuse the cluster for all of them.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (ISPN-6252) Upgrade to Apache Lucene 5.5
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-6252?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes commented on ISPN-6252:
-----------------------------------------
> If you make the Infinispan DirectoryProvider compatible with Hibernate Search / WildFly only, and give Infinispan Query a similar alternative we should be good and the two projects would > be able to have completely independent Lucene versions.
That separation makes sense, but I think it'd would not allow Infinispan to have a Lucene version different from Hibernate Search: Infinispan Query using "ram" or "fs" directory will still depends on Hibernate Search that has its own exported Lucene version. I suppose it'd cause issues should Infinispan decides to have a dependency on another Lucene version. Am I right?
> Upgrade to Apache Lucene 5.5
> ----------------------------
>
> Key: ISPN-6252
> URL: https://issues.jboss.org/browse/ISPN-6252
> Project: Infinispan
> Issue Type: Component Upgrade
> Components: Embedded Querying
> Reporter: Sanne Grinovero
> Assignee: Gustavo Fernandes
> Fix For: 8.2.0.CR1
>
>
> Apache Lucene 5.5 is released now, and is "drop-in compatible" with versions 5.3 and 5.4 so you don't have to wait for an Hibernate Search release.
> It's also being the last one for the 5.x series before 6, so I expect that we'll see some more micro releases for maintenance but essentially that this will be some form of long term commitment.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (ISPN-6252) Upgrade to Apache Lucene 5.5
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-6252?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes edited comment on ISPN-6252 at 2/29/16 8:34 AM:
------------------------------------------------------------------
> If you make the Infinispan DirectoryProvider compatible with Hibernate Search / WildFly only,
> and give Infinispan Query a similar alternative we should be good and the two projects would
> be able to have completely independent Lucene versions.
That separation makes sense, but I think it'd would not allow Infinispan to have a Lucene version different from Hibernate Search: Infinispan Query using "ram" or "fs" directory will still depends on Hibernate Search that has its own exported Lucene version. I suppose it'd cause issues should Infinispan decides to have a dependency on another Lucene version. Am I right?
was (Author: gustavonalle):
> If you make the Infinispan DirectoryProvider compatible with Hibernate Search / WildFly only, and give Infinispan Query a similar alternative we should be good and the two projects would > be able to have completely independent Lucene versions.
That separation makes sense, but I think it'd would not allow Infinispan to have a Lucene version different from Hibernate Search: Infinispan Query using "ram" or "fs" directory will still depends on Hibernate Search that has its own exported Lucene version. I suppose it'd cause issues should Infinispan decides to have a dependency on another Lucene version. Am I right?
> Upgrade to Apache Lucene 5.5
> ----------------------------
>
> Key: ISPN-6252
> URL: https://issues.jboss.org/browse/ISPN-6252
> Project: Infinispan
> Issue Type: Component Upgrade
> Components: Embedded Querying
> Reporter: Sanne Grinovero
> Assignee: Gustavo Fernandes
> Fix For: 8.2.0.CR1
>
>
> Apache Lucene 5.5 is released now, and is "drop-in compatible" with versions 5.3 and 5.4 so you don't have to wait for an Hibernate Search release.
> It's also being the last one for the 5.x series before 6, so I expect that we'll see some more micro releases for maintenance but essentially that this will be some form of long term commitment.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (ISPN-6288) Tests expecting a TimeoutException should use shorter timeouts
by Dan Berindei (JIRA)
Dan Berindei created ISPN-6288:
----------------------------------
Summary: Tests expecting a TimeoutException should use shorter timeouts
Key: ISPN-6288
URL: https://issues.jboss.org/browse/ISPN-6288
Project: Infinispan
Issue Type: Task
Components: Test Suite - Core
Affects Versions: 8.2.0.Beta2
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 8.2.0.CR1
E.g. {{LocalDistributedExecutorTest.SleepingSimpleCallable}} blocks the test for 10 seconds, or {{CleanupAfterFailTest}} waits 15 seconds for the replication to time out.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (ISPN-6252) Upgrade to Apache Lucene 5.5
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-6252?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes commented on ISPN-6252:
-----------------------------------------
> What do you mean by "manipulate it" and/or change the slot? Can this be done at runtime, on a per-deployment base?
Infinispan query depends on Hibernate Search that depends on Lucene. Hibernate Search 5.6.0.Alpha1 (the version Infinispan points to now) is currently on Lucene 5.4. The only way to have Infinispan on 5.5 without a Hibernate search release would be to manipulate/hack the Hibernate Search modules zip on our side to include 5.5 instead of 5.4, but this is not very nice.
> Upgrade to Apache Lucene 5.5
> ----------------------------
>
> Key: ISPN-6252
> URL: https://issues.jboss.org/browse/ISPN-6252
> Project: Infinispan
> Issue Type: Component Upgrade
> Components: Embedded Querying
> Reporter: Sanne Grinovero
> Assignee: Gustavo Fernandes
> Fix For: 8.2.0.CR1
>
>
> Apache Lucene 5.5 is released now, and is "drop-in compatible" with versions 5.3 and 5.4 so you don't have to wait for an Hibernate Search release.
> It's also being the last one for the 5.x series before 6, so I expect that we'll see some more micro releases for maintenance but essentially that this will be some form of long term commitment.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (ISPN-6252) Upgrade to Apache Lucene 5.5
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-6252?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-6252:
---------------------------------------
What do you mean by "manipulate it" and/or change the slot? Can this be done at runtime, on a per-deployment base?
We can not patch the static definition of existing modules, that would break other applications.
An alternative: as far as I remember the only module which needs both worlds in the same picture is the Infinispan DirectoryProvider for Hibernate Search: that's meant to link to the Hibernate Search instance included in WildFly/EAP, and therefore should be using its Lucene module (rather than the Infinispan/Lucene module).
Considering that Infinispan Query has its own very specific needs on how it sets up the Directory, I'm wondering if we should rather not share the DirectoryProvider module for both Query and Hibernate Search. If you make the Infinispan DirectoryProvider compatible with Hibernate Search / WildFly only, and give Infinispan Query a similar alternative we should be good and the two projects would be able to have completely independent Lucene versions.
> Upgrade to Apache Lucene 5.5
> ----------------------------
>
> Key: ISPN-6252
> URL: https://issues.jboss.org/browse/ISPN-6252
> Project: Infinispan
> Issue Type: Component Upgrade
> Components: Embedded Querying
> Reporter: Sanne Grinovero
> Assignee: Gustavo Fernandes
> Fix For: 8.2.0.CR1
>
>
> Apache Lucene 5.5 is released now, and is "drop-in compatible" with versions 5.3 and 5.4 so you don't have to wait for an Hibernate Search release.
> It's also being the last one for the 5.x series before 6, so I expect that we'll see some more micro releases for maintenance but essentially that this will be some form of long term commitment.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (ISPN-6286) Component registry should not allow registration during shutdown
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6286?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-6286:
-------------------------------
Status: Open (was: New)
> Component registry should not allow registration during shutdown
> ----------------------------------------------------------------
>
> Key: ISPN-6286
> URL: https://issues.jboss.org/browse/ISPN-6286
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.2.0.Beta2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 8.2.0.CR1
>
>
> {{AbstractComponentRegistry.getOrCreateComponent()}} is able to create and register a component even while the cache/cache manager is shutting down. The component isn't started though, which sometimes leads to {{NullPointerExceptions}} (e.g. ISPN-6277, {{ClusterTopologyManagerImpl}}).
> It shouldn't be possible to re-create a component after the registry enters the {{STOPPING}} status, and {{getOrCreateComponent()}} should instead throw an {{IllegalLifecycleStateException}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years