[JBoss JIRA] (RTGOV-574) Investigate 'index already exists' exception when previous command indicates does not exist
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/RTGOV-574?page=com.atlassian.jira.plugin.... ]
Gary Brown commented on RTGOV-574:
----------------------------------
Removing association with version 2.0.0.Final as does not appear to be causing any adverse effect - however will keep open for now.
[~imckinle] Just wanted to check, is there a reason the mappings are applied regardless of whether the index is created or already exists? Does this need to be done for each restart - is it in case the mappings change?
> Investigate 'index already exists' exception when previous command indicates does not exist
> -------------------------------------------------------------------------------------------
>
> Key: RTGOV-574
> URL: https://issues.jboss.org/browse/RTGOV-574
> Project: RTGov (Run Time Governance)
> Issue Type: Task
> Reporter: Gary Brown
> Assignee: Gary Brown
>
> When updating to Elasticsearch 1.3.2 (RTGOV-568), noticed that when the EAP server was restarted, it resulted in an IndexAlreadyExistsException from ES.
> However this exception was generated from code called to create the indexes - however prior to that call it checks with the ES node whether the indexes already exist.
> Ivan McKinley found the following reference that may be relevant: http://stackoverflow.com/questions/23883110/elasticsearch-index-exists-no...
> He also suggests:
> "If this is the problem then we may have an impact from running “embedded” mode. The more data we have the longer response from the async process perhaps.
> externalising the es process may resolve this.. and another test is to remove the entire contents of the index/type/ to further prove that we are affect the amount of data.
> The various scenarios here are definitely interesting for us regarding documentation"
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (RTGOV-574) Investigate 'index already exists' exception when previous command indicates does not exist
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/RTGOV-574?page=com.atlassian.jira.plugin.... ]
Gary Brown updated RTGOV-574:
-----------------------------
Fix Version/s: (was: 2.0.0.Final)
> Investigate 'index already exists' exception when previous command indicates does not exist
> -------------------------------------------------------------------------------------------
>
> Key: RTGOV-574
> URL: https://issues.jboss.org/browse/RTGOV-574
> Project: RTGov (Run Time Governance)
> Issue Type: Task
> Reporter: Gary Brown
> Assignee: Gary Brown
>
> When updating to Elasticsearch 1.3.2 (RTGOV-568), noticed that when the EAP server was restarted, it resulted in an IndexAlreadyExistsException from ES.
> However this exception was generated from code called to create the indexes - however prior to that call it checks with the ES node whether the indexes already exist.
> Ivan McKinley found the following reference that may be relevant: http://stackoverflow.com/questions/23883110/elasticsearch-index-exists-no...
> He also suggests:
> "If this is the problem then we may have an impact from running “embedded” mode. The more data we have the longer response from the async process perhaps.
> externalising the es process may resolve this.. and another test is to remove the entire contents of the index/type/ to further prove that we are affect the amount of data.
> The various scenarios here are definitely interesting for us regarding documentation"
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (RTGOV-574) Investigate 'index already exists' exception when previous command indicates does not exist
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/RTGOV-574?page=com.atlassian.jira.plugin.... ]
Gary Brown commented on RTGOV-574:
----------------------------------
Your second reference says "All operations are completely asynchronous in nature (either accepts a listener, or returns a future)."
In this case it is receiving a 'future' and calling the 'actionGet()' on it, which would be blocking awaiting the result.
> Investigate 'index already exists' exception when previous command indicates does not exist
> -------------------------------------------------------------------------------------------
>
> Key: RTGOV-574
> URL: https://issues.jboss.org/browse/RTGOV-574
> Project: RTGov (Run Time Governance)
> Issue Type: Task
> Reporter: Gary Brown
> Assignee: Gary Brown
> Fix For: 2.0.0.Final
>
>
> When updating to Elasticsearch 1.3.2 (RTGOV-568), noticed that when the EAP server was restarted, it resulted in an IndexAlreadyExistsException from ES.
> However this exception was generated from code called to create the indexes - however prior to that call it checks with the ES node whether the indexes already exist.
> Ivan McKinley found the following reference that may be relevant: http://stackoverflow.com/questions/23883110/elasticsearch-index-exists-no...
> He also suggests:
> "If this is the problem then we may have an impact from running “embedded” mode. The more data we have the longer response from the async process perhaps.
> externalising the es process may resolve this.. and another test is to remove the entire contents of the index/type/ to further prove that we are affect the amount of data.
> The various scenarios here are definitely interesting for us regarding documentation"
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (SRAMP-29) Add support for Stored Queries
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/SRAMP-29?page=com.atlassian.jira.plugin.s... ]
Work on SRAMP-29 started by Brett Meyer.
----------------------------------------
> Add support for Stored Queries
> ------------------------------
>
> Key: SRAMP-29
> URL: https://issues.jboss.org/browse/SRAMP-29
> Project: S-RAMP
> Issue Type: Sub-task
> Reporter: Eric Wittmann
> Assignee: Brett Meyer
> Priority: Minor
> Fix For: 0.6.0
>
>
> Section 4.5 of the S-RAMP spec discusses stored queries. We need to add support for them.
> {quote}
> S-RAMP provides support for storing queries in the repository using the StoredQuery Artifact Type. This can be convenient because it allows quick execution of a frequently performed query. The syntax associated with creation, retrieval, update and deletion of a Stored Query is binding specific. Refer to the appropriate binding document of this specification for details.
>
> The StoredQuery Artifact Type does NOT extend BaseArtifactType as do most other Artifact Types in S-RAMP, which means it is simpler and possesses only these built-in attributes:
> queryName: The name of the Stored Query instance. This must be unique.
> queryExpression: The specification of the query expression.
>
> A StoredQuery MAY also contain a list of propertyName values. These are used to indicate to the server that the results returned from the execution of the query SHALL include values for those property names when they are present in the artifact instance(s) returned. This can be valuable in bindings that may not necessarily return the complete artifact in query results. The actual format of the query response is binding specific.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (RTGOV-574) Investigate 'index already exists' exception when previous command indicates does not exist
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/RTGOV-574?page=com.atlassian.jira.plugin.... ]
Gary Brown commented on RTGOV-574:
----------------------------------
Not yet, will try tomorrow - although this shouldn't change the result as it is a synchronous call, unless they have introduced a bug.
> Investigate 'index already exists' exception when previous command indicates does not exist
> -------------------------------------------------------------------------------------------
>
> Key: RTGOV-574
> URL: https://issues.jboss.org/browse/RTGOV-574
> Project: RTGov (Run Time Governance)
> Issue Type: Task
> Reporter: Gary Brown
> Assignee: Gary Brown
> Fix For: 2.0.0.Final
>
>
> When updating to Elasticsearch 1.3.2 (RTGOV-568), noticed that when the EAP server was restarted, it resulted in an IndexAlreadyExistsException from ES.
> However this exception was generated from code called to create the indexes - however prior to that call it checks with the ES node whether the indexes already exist.
> Ivan McKinley found the following reference that may be relevant: http://stackoverflow.com/questions/23883110/elasticsearch-index-exists-no...
> He also suggests:
> "If this is the problem then we may have an impact from running “embedded” mode. The more data we have the longer response from the async process perhaps.
> externalising the es process may resolve this.. and another test is to remove the entire contents of the index/type/ to further prove that we are affect the amount of data.
> The various scenarios here are definitely interesting for us regarding documentation"
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (RTGOV-574) Investigate 'index already exists' exception when previous command indicates does not exist
by ivan mckinley (JIRA)
[ https://issues.jboss.org/browse/RTGOV-574?page=com.atlassian.jira.plugin.... ]
ivan mckinley commented on RTGOV-574:
-------------------------------------
Did you test this ?
A quick test to verify if we are affected by this would be to sleep the method. or put a breakpoint in there
private boolean prepareIndex(Map<String, Object> defaultSettings) {
IndicesExistsResponse res = _client.admin().indices().prepareExists(_index).execute().actionGet();
thread.sleep(10000);
boolean created = false;
if (!res.isExists()) {
CreateIndexRequestBuilder req = _client.admin().indices().prepareCreate(_index);
req.setSettings(defaultSettings);
created = req.execute().actionGet().isAcknowledged();
if (!created) {
throw new RuntimeException("Could not create index [" + _index + "]");
}
}
return created;
}
> Investigate 'index already exists' exception when previous command indicates does not exist
> -------------------------------------------------------------------------------------------
>
> Key: RTGOV-574
> URL: https://issues.jboss.org/browse/RTGOV-574
> Project: RTGov (Run Time Governance)
> Issue Type: Task
> Reporter: Gary Brown
> Assignee: Gary Brown
> Fix For: 2.0.0.Final
>
>
> When updating to Elasticsearch 1.3.2 (RTGOV-568), noticed that when the EAP server was restarted, it resulted in an IndexAlreadyExistsException from ES.
> However this exception was generated from code called to create the indexes - however prior to that call it checks with the ES node whether the indexes already exist.
> Ivan McKinley found the following reference that may be relevant: http://stackoverflow.com/questions/23883110/elasticsearch-index-exists-no...
> He also suggests:
> "If this is the problem then we may have an impact from running “embedded” mode. The more data we have the longer response from the async process perhaps.
> externalising the es process may resolve this.. and another test is to remove the entire contents of the index/type/ to further prove that we are affect the amount of data.
> The various scenarios here are definitely interesting for us regarding documentation"
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (SRAMP-29) Add support for Stored Queries
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/SRAMP-29?page=com.atlassian.jira.plugin.s... ]
Brett Meyer updated SRAMP-29:
-----------------------------
Description:
Section 4.5 of the S-RAMP spec discusses stored queries. We need to add support for them.
{quote}
S-RAMP provides support for storing queries in the repository using the StoredQuery Artifact Type. This can be convenient because it allows quick execution of a frequently performed query. The syntax associated with creation, retrieval, update and deletion of a Stored Query is binding specific. Refer to the appropriate binding document of this specification for details.
The StoredQuery Artifact Type does NOT extend BaseArtifactType as do most other Artifact Types in S-RAMP, which means it is simpler and possesses only these built-in attributes:
queryName: The name of the Stored Query instance. This must be unique.
queryExpression: The specification of the query expression.
A StoredQuery MAY also contain a list of propertyName values. These are used to indicate to the server that the results returned from the execution of the query SHALL include values for those property names when they are present in the artifact instance(s) returned. This can be valuable in bindings that may not necessarily return the complete artifact in query results. The actual format of the query response is binding specific.
{quote}
was:Section 4.5 of the S-RAMP spec discusses stored queries. We need to add support for them.
> Add support for Stored Queries
> ------------------------------
>
> Key: SRAMP-29
> URL: https://issues.jboss.org/browse/SRAMP-29
> Project: S-RAMP
> Issue Type: Sub-task
> Reporter: Eric Wittmann
> Assignee: Brett Meyer
> Priority: Minor
> Fix For: 0.6.0
>
>
> Section 4.5 of the S-RAMP spec discusses stored queries. We need to add support for them.
> {quote}
> S-RAMP provides support for storing queries in the repository using the StoredQuery Artifact Type. This can be convenient because it allows quick execution of a frequently performed query. The syntax associated with creation, retrieval, update and deletion of a Stored Query is binding specific. Refer to the appropriate binding document of this specification for details.
>
> The StoredQuery Artifact Type does NOT extend BaseArtifactType as do most other Artifact Types in S-RAMP, which means it is simpler and possesses only these built-in attributes:
> queryName: The name of the Stored Query instance. This must be unique.
> queryExpression: The specification of the query expression.
>
> A StoredQuery MAY also contain a list of propertyName values. These are used to indicate to the server that the results returned from the execution of the query SHALL include values for those property names when they are present in the artifact instance(s) returned. This can be valuable in bindings that may not necessarily return the complete artifact in query results. The actual format of the query response is binding specific.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years