[JBoss JIRA] (ISPN-9805) Use remote-timeout instead of state-transfer timeout for leave requests
by Dan Berindei (Jira)
Dan Berindei created ISPN-9805:
----------------------------------
Summary: Use remote-timeout instead of state-transfer timeout for leave requests
Key: ISPN-9805
URL: https://issues.jboss.org/browse/ISPN-9805
Project: Infinispan
Issue Type: Enhancement
Components: Core
Affects Versions: 9.4.3.Final, 10.0.0.Alpha1
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 10.0.0.Alpha2
Normally the leave request should not block, but in rare cases it does. E.g. because of ISPN-9588, sometimes the leave request never gets a response, and only gives up after the state-transfer timeout expires (4 minutes by default). If the test has more than one cache (e.g. `org.infinispan.CONFIG` is running), it will be killed by `TestNGLongTestsHook` after 5 minutes.
We should use the smaller `remote-timeout` so that nodes block for a shorter time before leaving.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (ISPN-9805) Use remote-timeout instead of state-transfer timeout for leave requests
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-9805?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-9805:
-------------------------------
Status: Open (was: New)
> Use remote-timeout instead of state-transfer timeout for leave requests
> -----------------------------------------------------------------------
>
> Key: ISPN-9805
> URL: https://issues.jboss.org/browse/ISPN-9805
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 10.0.0.Alpha1, 9.4.3.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.0.0.Alpha2
>
>
> Normally the leave request should not block, but in rare cases it does. E.g. because of ISPN-9588, sometimes the leave request never gets a response, and only gives up after the state-transfer timeout expires (4 minutes by default). If the test has more than one cache (e.g. `org.infinispan.CONFIG` is running), it will be killed by `TestNGLongTestsHook` after 5 minutes.
> We should use the smaller `remote-timeout` so that nodes block for a shorter time before leaving.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (ISPN-8535) Rest API redesign
by Gustavo Fernandes (Jira)
[ https://issues.jboss.org/browse/ISPN-8535?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes commented on ISPN-8535:
-----------------------------------------
Transaction is an interesting one. We could expose it as a resource maybe, allowing a tx to be created, getting back a txid, and use this id on other operations maybe?
> Rest API redesign
> -----------------
>
> Key: ISPN-8535
> URL: https://issues.jboss.org/browse/ISPN-8535
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 9.2.0.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> Infinispan REST API deals with only one resource, (the cache) and maps all operations on the cache using HTTP verbs and request parameters. The API assumes the URI is related to the cache making it hard to add new kinds of resources without causing ambiguous references.
> Since we now have other types of entities, such as counters, scripts, templates, etc, and each one of them can involve different operations, we should make the API more "Restful" by using more than one resource and collections of resources, plus HTTP verbs and operations on them. Examples:
> * Create a cache: POST /rest/caches
> * Delete a cache: DELETE /rest/caches/myCache
> * Create a template: POST /rest/templates
> * Delete a template: DELETE /rest/templates/myTemplate
> * Create an entry: POST /rest/caches/myCache/1
> * Create a counter: POST /rest/counters
> * Get a counter value: GET /rest/counters/mycounter
> * Increment a counter: GET /rest/counters/mycounter?action=increment
> * Search a cache: GET /rest/caches/myCache?action=search
> * Create a script: POST /rest/scripts/
> * Get a script source: GET /rest/scritps/myScript
> * Execute a script: GET /rest/scripts/myScript?action=execute¶m1=foo
> * Stop individual servers and the full cluster
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (ISPN-8535) Rest API redesign
by Gustavo Fernandes (Jira)
[ https://issues.jboss.org/browse/ISPN-8535?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-8535:
------------------------------------
Description:
Infinispan REST API deals with only one resource, (the cache) and maps all operations on the cache using HTTP verbs and request parameters. The API assumes the URI is related to the cache making it hard to add new kinds of resources without causing ambiguous references.
Since we now have other types of entities, such as counters, scripts, templates, etc, and each one of them can involve different operations, we should make the API more "Restful" by using more than one resource and collections of resources, plus HTTP verbs and operations on them. Examples:
* Create a cache: POST /rest/caches
* Delete a cache: DELETE /rest/caches/myCache
* Create a template: POST /rest/templates
* Delete a template: DELETE /rest/templates/myTemplate
* Create an entry: POST /rest/caches/myCache/1
* Create a counter: POST /rest/counters
* Get a counter value: GET /rest/counters/mycounter
* Increment a counter: GET /rest/counters/mycounter?action=increment
* Search a cache: GET /rest/caches/myCache?action=search
* Create a script: POST /rest/scripts/
* Get a script source: GET /rest/scritps/myScript
* Execute a script: GET /rest/scripts/myScript?action=execute¶m1=foo
* Stop individual servers and the full cluster
was:
Infinispan REST API deals with only one resource, (the cache) and maps all operations on the cache using HTTP verbs and request parameters. The API assumes the URI is related to the cache making it hard to add new kinds of resources without causing ambiguous references.
Since we now have other types of entities, such as counters, scripts, templates, etc, and each one of them can involve different operations, we should make the API more "Restful" by using more than one resource and collections of resources, plus HTTP verbs and operations on them. Examples:
* Create a cache: POST /rest/caches
* Delete a cache: DELETE /rest/caches/myCache
* Create a template: POST /rest/templates
* Delete a template: DELETE /rest/templates/myTemplate
* Create an entry: POST /rest/caches/myCache/1
* Create a counter: POST /rest/counters
* Get a counter value: GET /rest/counters/mycounter
* Increment a counter: GET /rest/counters/mycounter?action=increment
* Search a cache: GET /rest/caches/myCache?action=search
* Create a script: POST /rest/scripts/
* Get a script source: GET /rest/scritps/myScript
* Execute a script: GET /rest/scripts/myScript?action=execute¶m1=foo
> Rest API redesign
> -----------------
>
> Key: ISPN-8535
> URL: https://issues.jboss.org/browse/ISPN-8535
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 9.2.0.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> Infinispan REST API deals with only one resource, (the cache) and maps all operations on the cache using HTTP verbs and request parameters. The API assumes the URI is related to the cache making it hard to add new kinds of resources without causing ambiguous references.
> Since we now have other types of entities, such as counters, scripts, templates, etc, and each one of them can involve different operations, we should make the API more "Restful" by using more than one resource and collections of resources, plus HTTP verbs and operations on them. Examples:
> * Create a cache: POST /rest/caches
> * Delete a cache: DELETE /rest/caches/myCache
> * Create a template: POST /rest/templates
> * Delete a template: DELETE /rest/templates/myTemplate
> * Create an entry: POST /rest/caches/myCache/1
> * Create a counter: POST /rest/counters
> * Get a counter value: GET /rest/counters/mycounter
> * Increment a counter: GET /rest/counters/mycounter?action=increment
> * Search a cache: GET /rest/caches/myCache?action=search
> * Create a script: POST /rest/scripts/
> * Get a script source: GET /rest/scritps/myScript
> * Execute a script: GET /rest/scripts/myScript?action=execute¶m1=foo
> * Stop individual servers and the full cluster
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (ISPN-8535) Rest API redesign
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-8535?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant commented on ISPN-8535:
---------------------------------------
we need some admin ops:
* shutdown node
* suhtdown cluster
* ...
> Rest API redesign
> -----------------
>
> Key: ISPN-8535
> URL: https://issues.jboss.org/browse/ISPN-8535
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 9.2.0.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> Infinispan REST API deals with only one resource, (the cache) and maps all operations on the cache using HTTP verbs and request parameters. The API assumes the URI is related to the cache making it hard to add new kinds of resources without causing ambiguous references.
> Since we now have other types of entities, such as counters, scripts, templates, etc, and each one of them can involve different operations, we should make the API more "Restful" by using more than one resource and collections of resources, plus HTTP verbs and operations on them. Examples:
> * Create a cache: POST /rest/caches
> * Delete a cache: DELETE /rest/caches/myCache
> * Create a template: POST /rest/templates
> * Delete a template: DELETE /rest/templates/myTemplate
> * Create an entry: POST /rest/caches/myCache/1
> * Create a counter: POST /rest/counters
> * Get a counter value: GET /rest/counters/mycounter
> * Increment a counter: GET /rest/counters/mycounter?action=increment
> * Search a cache: GET /rest/caches/myCache?action=search
> * Create a script: POST /rest/scripts/
> * Get a script source: GET /rest/scritps/myScript
> * Execute a script: GET /rest/scripts/myScript?action=execute¶m1=foo
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (ISPN-8535) Rest API redesign
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-8535?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant commented on ISPN-8535:
---------------------------------------
Transaction support
> Rest API redesign
> -----------------
>
> Key: ISPN-8535
> URL: https://issues.jboss.org/browse/ISPN-8535
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 9.2.0.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> Infinispan REST API deals with only one resource, (the cache) and maps all operations on the cache using HTTP verbs and request parameters. The API assumes the URI is related to the cache making it hard to add new kinds of resources without causing ambiguous references.
> Since we now have other types of entities, such as counters, scripts, templates, etc, and each one of them can involve different operations, we should make the API more "Restful" by using more than one resource and collections of resources, plus HTTP verbs and operations on them. Examples:
> * Create a cache: POST /rest/caches
> * Delete a cache: DELETE /rest/caches/myCache
> * Create a template: POST /rest/templates
> * Delete a template: DELETE /rest/templates/myTemplate
> * Create an entry: POST /rest/caches/myCache/1
> * Create a counter: POST /rest/counters
> * Get a counter value: GET /rest/counters/mycounter
> * Increment a counter: GET /rest/counters/mycounter?action=increment
> * Search a cache: GET /rest/caches/myCache?action=search
> * Create a script: POST /rest/scripts/
> * Get a script source: GET /rest/scritps/myScript
> * Execute a script: GET /rest/scripts/myScript?action=execute¶m1=foo
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (ISPN-3835) Index Update command is processed before the registry listener is triggered
by Galder Zamarreño (Jira)
[ https://issues.jboss.org/browse/ISPN-3835?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-3835:
-----------------------------------
Fix Version/s: 9.4.5.Final
(was: 9.4.4.Final)
> Index Update command is processed before the registry listener is triggered
> ---------------------------------------------------------------------------
>
> Key: ISPN-3835
> URL: https://issues.jboss.org/browse/ISPN-3835
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 6.0.0.Final
> Reporter: Sanne Grinovero
> Priority: Critical
> Labels: 64QueryBlockers
> Fix For: 9.4.5.Final
>
>
> When using the InfinispanIndexManager backend the master node might receive an index update command about an index which it hasn't defined yet.
> Index definitions are triggered by the type registry, which in turn is driven by the ClusterRegistry and an event listener on the ClusterRegistry. It looks like slaves are sending update requests before the master has processed the configuration event.
> This leads to index update commands to be lost (with a stacktrace logged)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months