[JBoss JIRA] (ISPN-5544) Deprecate eager near caching
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5544?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5544:
----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/3545
> Deprecate eager near caching
> ----------------------------
>
> Key: ISPN-5544
> URL: https://issues.jboss.org/browse/ISPN-5544
> Project: Infinispan
> Issue Type: Task
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 8.0.0.Beta1, 8.0.0.Final
>
>
> In it's current form, eager near caching can lead the server to run out of direct memory, see ISPN-5523. The reason that's happening is because we're having to send events containing keys + values for each put() operation, indiscriminately to clients. So, regardless of what the client stores in the near cache, the client receives key+value information for all keys, as each key is created/modified, and this is having a big toll on the capabilities of the server to push those events to clients.
> So, we have decided to deprecate eager near caching in Infinispan 8.0, and we'll remove it completely for Infinispan 9.0.
> Lazy near caching still remains and works well because events are smaller since no value is sent to clients. Lazy near caching is still indiscriminate but we have plans to make it more selective, so that for example, only modified/removed events are sent for those keys that are stored in the client near cache, which would reduce traffic considerably (new jira to be created).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (ISPN-5544) Deprecate eager near caching
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5544?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5544:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Deprecate eager near caching
> ----------------------------
>
> Key: ISPN-5544
> URL: https://issues.jboss.org/browse/ISPN-5544
> Project: Infinispan
> Issue Type: Task
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 8.0.0.Beta1, 8.0.0.Final
>
>
> In it's current form, eager near caching can lead the server to run out of direct memory, see ISPN-5523. The reason that's happening is because we're having to send events containing keys + values for each put() operation, indiscriminately to clients. So, regardless of what the client stores in the near cache, the client receives key+value information for all keys, as each key is created/modified, and this is having a big toll on the capabilities of the server to push those events to clients.
> So, we have decided to deprecate eager near caching in Infinispan 8.0, and we'll remove it completely for Infinispan 9.0.
> Lazy near caching still remains and works well because events are smaller since no value is sent to clients. Lazy near caching is still indiscriminate but we have plans to make it more selective, so that for example, only modified/removed events are sent for those keys that are stored in the client near cache, which would reduce traffic considerably (new jira to be created).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (ISPN-5544) Deprecate eager near caching
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5544?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5544:
----------------------------------
Description:
In its current form, eager near caching can lead the server to run out of direct memory, see ISPN-5523. The reason that's happening is because we're having to send events containing keys + values for each put() operation, indiscriminately to clients. So, regardless of what the client stores in the near cache, the client receives key+value information for all keys, as each key is created/modified, and this is having a big toll on the capabilities of the server to push those events to clients.
So, we have decided to deprecate eager near caching in Infinispan 8.0, and we'll remove it completely for Infinispan 9.0.
Lazy near caching still remains and works well because events are smaller since no value is sent to clients. Lazy near caching is still indiscriminate but we have plans to make it more selective, so that for example, only modified/removed events are sent for those keys that are stored in the client near cache, which would reduce traffic considerably (new jira to be created).
was:
In it's current form, eager near caching can lead the server to run out of direct memory, see ISPN-5523. The reason that's happening is because we're having to send events containing keys + values for each put() operation, indiscriminately to clients. So, regardless of what the client stores in the near cache, the client receives key+value information for all keys, as each key is created/modified, and this is having a big toll on the capabilities of the server to push those events to clients.
So, we have decided to deprecate eager near caching in Infinispan 8.0, and we'll remove it completely for Infinispan 9.0.
Lazy near caching still remains and works well because events are smaller since no value is sent to clients. Lazy near caching is still indiscriminate but we have plans to make it more selective, so that for example, only modified/removed events are sent for those keys that are stored in the client near cache, which would reduce traffic considerably (new jira to be created).
> Deprecate eager near caching
> ----------------------------
>
> Key: ISPN-5544
> URL: https://issues.jboss.org/browse/ISPN-5544
> Project: Infinispan
> Issue Type: Task
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 8.0.0.Beta1, 8.0.0.Final
>
>
> In its current form, eager near caching can lead the server to run out of direct memory, see ISPN-5523. The reason that's happening is because we're having to send events containing keys + values for each put() operation, indiscriminately to clients. So, regardless of what the client stores in the near cache, the client receives key+value information for all keys, as each key is created/modified, and this is having a big toll on the capabilities of the server to push those events to clients.
> So, we have decided to deprecate eager near caching in Infinispan 8.0, and we'll remove it completely for Infinispan 9.0.
> Lazy near caching still remains and works well because events are smaller since no value is sent to clients. Lazy near caching is still indiscriminate but we have plans to make it more selective, so that for example, only modified/removed events are sent for those keys that are stored in the client near cache, which would reduce traffic considerably (new jira to be created).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (ISPN-5046) PartitionHandling: split during commit can leave the cache inconsistent after merge
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5046?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-5046:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 8.0.0.Beta1
Resolution: Done
> PartitionHandling: split during commit can leave the cache inconsistent after merge
> -----------------------------------------------------------------------------------
>
> Key: ISPN-5046
> URL: https://issues.jboss.org/browse/ISPN-5046
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 7.0.2.Final, 7.1.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Priority: Critical
> Fix For: 8.0.0.Beta1, 8.0.0.Final
>
>
> Say we have a cluster ABCD; a transaction T was started on A, with B as the primary owner and C the backup owner. B and C both acknowledge the prepare, and the network splits into AB and CD right before A sends the commit command. Eventually A suspects C and D, but the commit still succeeds on B before C and D are suspected. And SuspectExceptions are ignored for commit commands, so the user won't see any error.
> However, C will eventually suspect A and B. When the CD cache topology is installed, it will roll back transaction T. After the merge, both partitions are in degraded mode, so we assume that they both have the latest data and the key is never updated on C.
> From C's point of view, this is very similar to ISPN-3421. The fix should also be similar, we could delay the transaction rollback on C until we get a confirmation from B that T was not committed there. Since B is inaccessible, it will eventually get a SuspectException and the CD cache topology, at which point the cache is in degraded mode and it can wait for a merge. On merge, it should check the status of the transaction on B again, and either commit or rollback based on what B did.
> We also need to suspend the cleanup of completed transactions while the cache is in degraded mode, otherwise C might not find T on B after the merge.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (ISPN-5564) AsyncCacheWriter stop() and clear() should not wait for space in the modifications queue
by Karsten Blees (JIRA)
Karsten Blees created ISPN-5564:
-----------------------------------
Summary: AsyncCacheWriter stop() and clear() should not wait for space in the modifications queue
Key: ISPN-5564
URL: https://issues.jboss.org/browse/ISPN-5564
Project: Infinispan
Issue Type: Enhancement
Reporter: Karsten Blees
AsyncCacheWriter.clear() invalidates all enqueued changes rather than adding more changes to the queue. Thus, clear should not wait if the queue is full.
AsyncCacheWriter.stop() should also take effect immediately (i.e. set the stopped flag *without* waiting if the queue is full).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (ISPN-5563) AsyncCacheLoader.load() may still return stale data
by Karsten Blees (JIRA)
Karsten Blees created ISPN-5563:
-----------------------------------
Summary: AsyncCacheLoader.load() may still return stale data
Key: ISPN-5563
URL: https://issues.jboss.org/browse/ISPN-5563
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 7.0.0.Final, 6.0.0.Final, 5.0.0.FINAL
Reporter: Karsten Blees
There's a race condition that allows AsyncCacheLoader.load() / State.get() to return stale data. If the coordinator thread moves a modification to the head state because of a key conflict with tail, State.get() may miss that modification and return data from the back-end store instead.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (ISPN-5562) AsyncCacheWriter should write all data to the back-end store before shutting down
by Karsten Blees (JIRA)
[ https://issues.jboss.org/browse/ISPN-5562?page=com.atlassian.jira.plugin.... ]
Karsten Blees updated ISPN-5562:
--------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/3548
> AsyncCacheWriter should write all data to the back-end store before shutting down
> ---------------------------------------------------------------------------------
>
> Key: ISPN-5562
> URL: https://issues.jboss.org/browse/ISPN-5562
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 5.2.0.Final, 6.0.0.Final, 7.0.0.Final
> Reporter: Karsten Blees
>
> There is a chance that AsyncCacheWriter may stop before writing all midifications to the back-end store. This can primarily happen when writing the same keys in rapid succession. The coordinator thread will move these modifications to the head state (because of conflicts with tail), which is not checked before shutdown.
> There are two other minor race conditions if stop() is called concurrently to write() or clear() - these cannot happen in practice because PassivationManager is stopped before PersistenceManager:
> 1. AsyncStoreCoordinator checks State.stopped and State.modifications.isEmpty() without holding the readLock(). This is not reliable because a concurrent write() or remove() may still add to the modifications map.
> 2. clear() just replaces the head state, without copying the stopped flag that may have been set by a concurrent stop().
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (ISPN-5562) AsyncCacheWriter should write all data to the back-end store before shutting down
by Karsten Blees (JIRA)
Karsten Blees created ISPN-5562:
-----------------------------------
Summary: AsyncCacheWriter should write all data to the back-end store before shutting down
Key: ISPN-5562
URL: https://issues.jboss.org/browse/ISPN-5562
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 7.0.0.Final, 6.0.0.Final, 5.2.0.Final
Reporter: Karsten Blees
There is a chance that AsyncCacheWriter may stop before writing all midifications to the back-end store. This can primarily happen when writing the same keys in rapid succession. The coordinator thread will move these modifications to the head state (because of conflicts with tail), which is not checked before shutdown.
There are two other minor race conditions if stop() is called concurrently to write() or clear() - these cannot happen in practice because PassivationManager is stopped before PersistenceManager:
1. AsyncStoreCoordinator checks State.stopped and State.modifications.isEmpty() without holding the readLock(). This is not reliable because a concurrent write() or remove() may still add to the modifications map.
2. clear() just replaces the head state, without copying the stopped flag that may have been set by a concurrent stop().
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 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 Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-5561?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-5561:
--------------------------------
Status: Open (was: New)
> 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
> Fix For: 7.2.3.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)
10 years, 10 months