[JBoss JIRA] (RTGOV-495) Enable Elasticsearch response size to be configured
by Gary Brown (JIRA)
Gary Brown created RTGOV-495:
--------------------------------
Summary: Enable Elasticsearch response size to be configured
Key: RTGOV-495
URL: https://issues.jboss.org/browse/RTGOV-495
Project: RTGov (Run Time Governance)
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Gary Brown
Assignee: Gary Brown
Fix For: 2.0.0.Final
The response size currently defaults to 10, which is not high enough for many queries (especially for activity types).
We need to set a reasonable maximum, so will default to a higher value and enable it to be overridden by properties when necessary.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 10 months
[JBoss JIRA] (SRAMP-389) Performance issue in s-ramp client when using custom properties in query results
by Eric Wittmann (JIRA)
[ https://issues.jboss.org/browse/SRAMP-389?page=com.atlassian.jira.plugin.... ]
Work on SRAMP-389 started by Eric Wittmann.
> Performance issue in s-ramp client when using custom properties in query results
> --------------------------------------------------------------------------------
>
> Key: SRAMP-389
> URL: https://issues.jboss.org/browse/SRAMP-389
> Project: S-RAMP
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 0.4.0 - Tomcat Support
> Reporter: Eric Wittmann
> Assignee: Eric Wittmann
> Fix For: 0.5.0.Final
>
>
> There is a feature in s-ramp queries where the client can request that each artifact returned by a query also include a specific subset of the artifact's custom properties. This is in addition to the standard set of meta-data that is always returned when a query is performed.
> We currently use this feature in the dtgov WorkflowQueryService class to return the 'query' and 'workflow' custom properties (so they can be displayed in the UI list).
> Getting these custom properties while processing the result set is very slow (see ArtifactSummary::getCustomPropertyValue).
> I haven't actually verified this, but I *believe* the reason this is slow is because a new JAXB context is created for each ArtifactSummary in the query result list. Creating a JAXB context is a heavy weight operation.
> If this is truly the cause, we should try to share the JAXB context in some way. We need to determine whether it is thread-safe, in which case we should have a single JAXB context (singleton). If not, we should create it on a ThreadLocal.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 10 months
[JBoss JIRA] (SRAMP-389) Performance issue in s-ramp client when using custom properties in query results
by Eric Wittmann (JIRA)
[ https://issues.jboss.org/browse/SRAMP-389?page=com.atlassian.jira.plugin.... ]
Eric Wittmann reassigned SRAMP-389:
-----------------------------------
Assignee: Eric Wittmann (was: David virgil naranjo)
> Performance issue in s-ramp client when using custom properties in query results
> --------------------------------------------------------------------------------
>
> Key: SRAMP-389
> URL: https://issues.jboss.org/browse/SRAMP-389
> Project: S-RAMP
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 0.4.0 - Tomcat Support
> Reporter: Eric Wittmann
> Assignee: Eric Wittmann
> Fix For: 0.5.0.Final
>
>
> There is a feature in s-ramp queries where the client can request that each artifact returned by a query also include a specific subset of the artifact's custom properties. This is in addition to the standard set of meta-data that is always returned when a query is performed.
> We currently use this feature in the dtgov WorkflowQueryService class to return the 'query' and 'workflow' custom properties (so they can be displayed in the UI list).
> Getting these custom properties while processing the result set is very slow (see ArtifactSummary::getCustomPropertyValue).
> I haven't actually verified this, but I *believe* the reason this is slow is because a new JAXB context is created for each ArtifactSummary in the query result list. Creating a JAXB context is a heavy weight operation.
> If this is truly the cause, we should try to share the JAXB context in some way. We need to determine whether it is thread-safe, in which case we should have a single JAXB context (singleton). If not, we should create it on a ThreadLocal.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 10 months