[JBoss JIRA] (WFLY-12114) Ability to configure configure an EJB to not be pooled
by Brad Maxwell (Jira)
Brad Maxwell created WFLY-12114:
-----------------------------------
Summary: Ability to configure configure an EJB to not be pooled
Key: WFLY-12114
URL: https://issues.jboss.org/browse/WFLY-12114
Project: WildFly
Issue Type: Feature Request
Components: EJB
Reporter: Brad Maxwell
Assignee: Cheng Fang
Ability to configure configure an EJB to not be pooled
Currently SLSB/MDB's by default use the strict-max-pool configuration and an EJB can use @Pool or jboss-ejb3.xml to specify that a particular EJB use a different pool configuration.
If the default pool configuration is removed, for example, removing the bean-instance-pool-ref in the ejb3 subsystem from the stateless, would change the default pool configuration use to be none. Then the default for all EJBs is to create an EJB instance on demand when needed and destroy it when done. And then particular EJBs could then use @Pool or jboss-ejb3.xml to specify a pool configuration to use if instance on demand is not wanted.
It would be good if there was a way to configure the reverse, where in there is a default pool configuration for the EJBs and then a particular EJB could use @Pool or jboss-ejb3.xml to specify instance on demand.
{code}
<stateless>
<bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
</stateless>
{code}
Currently it does not look like there is a way to create a configuration that is instance on demand and strict-max-bean-instance-pool does not allow a max-pool-size of 0.
{code}
/subsystem=ejb3/strict-max-bean-instance-pool=nopool:add(max-pool-size=0)
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0117: 0 is an invalid value for parameter max-pool-size. A minimum value of 1 is required",
"rolled-back" => true
}
{code}
So if we had a way to create a pool config where it is instance-on-demand such to indicate there is no pool, then user could use @Pool or jboss-ejb3.xml to use the no-pool. Since there are not really any config for the instance-on-demand, it could just be a constant config, though it is nice when the standalone.xml shows options that are available.
/subsystem=ejb3/instance-on-demand-bean-instance-pool=no-pool:add()
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11943) Statistics of REST endpoints
by r searls (Jira)
[ https://issues.jboss.org/browse/WFLY-11943?page=com.atlassian.jira.plugin... ]
r searls updated WFLY-11943:
----------------------------
Description:
Provide statistics on REST endpoints in the jaxrs subsystem.
CLI support "read-resource" operation for jax-rs subsystem in deployment:
/deployment=jaxrs-eap.war/subsystem=jaxrs:read-resource
Statistics should be added to results of this operation in this RFE.
There needs to be option to enable or disable collecting of these statistics, because collecting of statistics does probably some performance drop.
The change of statistic settings should not require server reload or restart.
was:
-deleted text-It would be useful to collect statistics for all deployment in jaxrs subsystem.
It would also be useful to have aggregated statistics for end-point invocations for all deployments together.
count of invocations
execution time
CLI support "read-resource" operation for jax-rs subsystem in deployment:
/deployment=jaxrs-eap.war/subsystem=jaxrs:read-resource
Statistics should be added to results of this operation in this RFE.
This cmd is obsolete, please ignore.
{color:#C1C7D0}This RFE needs to add new operation to jax-rs subsystem, name of this operation could be "show-aggregated-statistics":
/subsystem=jaxrs:show-aggregated-statistics(){color}
There needs to be option to enable or disable collecting of these statistics, because collecting of statistics does probably some performance drop.
The change of statistic settings should not require server reload or restart.
> Statistics of REST endpoints
> ----------------------------
>
> Key: WFLY-11943
> URL: https://issues.jboss.org/browse/WFLY-11943
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Affects Versions: 17.0.0.Final
> Reporter: r searls
> Assignee: r searls
> Priority: Major
>
> Provide statistics on REST endpoints in the jaxrs subsystem.
> CLI support "read-resource" operation for jax-rs subsystem in deployment:
> /deployment=jaxrs-eap.war/subsystem=jaxrs:read-resource
> Statistics should be added to results of this operation in this RFE.
> There needs to be option to enable or disable collecting of these statistics, because collecting of statistics does probably some performance drop.
> The change of statistic settings should not require server reload or restart.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11943) Statistics of REST endpoints
by r searls (Jira)
[ https://issues.jboss.org/browse/WFLY-11943?page=com.atlassian.jira.plugin... ]
r searls updated WFLY-11943:
----------------------------
Description:
-deleted text-It would be useful to collect statistics for all deployment in jaxrs subsystem.
It would also be useful to have aggregated statistics for end-point invocations for all deployments together.
count of invocations
execution time
CLI support "read-resource" operation for jax-rs subsystem in deployment:
/deployment=jaxrs-eap.war/subsystem=jaxrs:read-resource
Statistics should be added to results of this operation in this RFE.
This cmd is obsolete, please ignore.
{color:#C1C7D0}This RFE needs to add new operation to jax-rs subsystem, name of this operation could be "show-aggregated-statistics":
/subsystem=jaxrs:show-aggregated-statistics(){color}
There needs to be option to enable or disable collecting of these statistics, because collecting of statistics does probably some performance drop.
The change of statistic settings should not require server reload or restart.
was:
-deleted text-It would be useful to collect statistics for all deployment in jaxrs subsystem.
It would also be useful to have aggregated statistics for end-point invocations for all deployments together.
count of invocations
execution time
CLI support "read-resource" operation for jax-rs subsystem in deployment:
/deployment=jaxrs-eap.war/subsystem=jaxrs:read-resource
Statistics should be added to results of this operation in this RFE.
-This RFE needs to add new operation to jax-rs subsystem, name of this operation could be "show-aggregated-statistics":
/subsystem=jaxrs:show-aggregated-statistics()-
There needs to be option to enable or disable collecting of these statistics, because collecting of statistics does probably some performance drop.
The change of statistic settings should not require server reload or restart.
> Statistics of REST endpoints
> ----------------------------
>
> Key: WFLY-11943
> URL: https://issues.jboss.org/browse/WFLY-11943
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Affects Versions: 17.0.0.Final
> Reporter: r searls
> Assignee: r searls
> Priority: Major
>
> -deleted text-It would be useful to collect statistics for all deployment in jaxrs subsystem.
> It would also be useful to have aggregated statistics for end-point invocations for all deployments together.
> count of invocations
> execution time
> CLI support "read-resource" operation for jax-rs subsystem in deployment:
> /deployment=jaxrs-eap.war/subsystem=jaxrs:read-resource
> Statistics should be added to results of this operation in this RFE.
> This cmd is obsolete, please ignore.
> {color:#C1C7D0}This RFE needs to add new operation to jax-rs subsystem, name of this operation could be "show-aggregated-statistics":
> /subsystem=jaxrs:show-aggregated-statistics(){color}
> There needs to be option to enable or disable collecting of these statistics, because collecting of statistics does probably some performance drop.
> The change of statistic settings should not require server reload or restart.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11943) Statistics of REST endpoints
by r searls (Jira)
[ https://issues.jboss.org/browse/WFLY-11943?page=com.atlassian.jira.plugin... ]
r searls updated WFLY-11943:
----------------------------
Description:
-deleted text-It would be useful to collect statistics for all deployment in jaxrs subsystem.
It would also be useful to have aggregated statistics for end-point invocations for all deployments together.
count of invocations
execution time
CLI support "read-resource" operation for jax-rs subsystem in deployment:
/deployment=jaxrs-eap.war/subsystem=jaxrs:read-resource
Statistics should be added to results of this operation in this RFE.
-This RFE needs to add new operation to jax-rs subsystem, name of this operation could be "show-aggregated-statistics":
/subsystem=jaxrs:show-aggregated-statistics()-
There needs to be option to enable or disable collecting of these statistics, because collecting of statistics does probably some performance drop.
The change of statistic settings should not require server reload or restart.
was:
-deleted text-It would be useful to collect statistics for all deployment in jaxrs subsystem.
It would also be useful to have aggregated statistics for end-point invocations for all deployments together.
count of invocations
execution time
CLI support "read-resource" operation for jax-rs subsystem in deployment:
/deployment=jaxrs-eap.war/subsystem=jaxrs:read-resource
Statistics should be added to results of this operation in this RFE.
{color:red}This RFE needs to add new operation to jax-rs subsystem, name of this operation could be "show-aggregated-statistics":
/subsystem=jaxrs:show-aggregated-statistics(){color}
There needs to be option to enable or disable collecting of these statistics, because collecting of statistics does probably some performance drop.
The change of statistic settings should not require server reload or restart.
> Statistics of REST endpoints
> ----------------------------
>
> Key: WFLY-11943
> URL: https://issues.jboss.org/browse/WFLY-11943
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Affects Versions: 17.0.0.Final
> Reporter: r searls
> Assignee: r searls
> Priority: Major
>
> -deleted text-It would be useful to collect statistics for all deployment in jaxrs subsystem.
> It would also be useful to have aggregated statistics for end-point invocations for all deployments together.
> count of invocations
> execution time
> CLI support "read-resource" operation for jax-rs subsystem in deployment:
> /deployment=jaxrs-eap.war/subsystem=jaxrs:read-resource
> Statistics should be added to results of this operation in this RFE.
> -This RFE needs to add new operation to jax-rs subsystem, name of this operation could be "show-aggregated-statistics":
> /subsystem=jaxrs:show-aggregated-statistics()-
> There needs to be option to enable or disable collecting of these statistics, because collecting of statistics does probably some performance drop.
> The change of statistic settings should not require server reload or restart.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11943) Statistics of REST endpoints
by r searls (Jira)
[ https://issues.jboss.org/browse/WFLY-11943?page=com.atlassian.jira.plugin... ]
r searls updated WFLY-11943:
----------------------------
Description:
-deleted text-It would be useful to collect statistics for all deployment in jaxrs subsystem.
It would also be useful to have aggregated statistics for end-point invocations for all deployments together.
count of invocations
execution time
CLI support "read-resource" operation for jax-rs subsystem in deployment:
/deployment=jaxrs-eap.war/subsystem=jaxrs:read-resource
Statistics should be added to results of this operation in this RFE.
{color:red}This RFE needs to add new operation to jax-rs subsystem, name of this operation could be "show-aggregated-statistics":
/subsystem=jaxrs:show-aggregated-statistics(){color}
There needs to be option to enable or disable collecting of these statistics, because collecting of statistics does probably some performance drop.
The change of statistic settings should not require server reload or restart.
was:
It would be useful to collect statistics for all deployment in jaxrs subsystem.
It would also be useful to have aggregated statistics for end-point invocations for all deployments together.
count of invocations
execution time
CLI support "read-resource" operation for jax-rs subsystem in deployment:
/deployment=jaxrs-eap.war/subsystem=jaxrs:read-resource
Statistics should be added to results of this operation in this RFE.
This RFE needs to add new operation to jax-rs subsystem, name of this operation could be "show-aggregated-statistics":
/subsystem=jaxrs:show-aggregated-statistics()
There needs to be option to enable or disable collecting of these statistics, because collecting of statistics does probably some performance drop.
The change of statistic settings should not require server reload or restart.
> Statistics of REST endpoints
> ----------------------------
>
> Key: WFLY-11943
> URL: https://issues.jboss.org/browse/WFLY-11943
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Affects Versions: 17.0.0.Final
> Reporter: r searls
> Assignee: r searls
> Priority: Major
>
> -deleted text-It would be useful to collect statistics for all deployment in jaxrs subsystem.
> It would also be useful to have aggregated statistics for end-point invocations for all deployments together.
> count of invocations
> execution time
> CLI support "read-resource" operation for jax-rs subsystem in deployment:
> /deployment=jaxrs-eap.war/subsystem=jaxrs:read-resource
> Statistics should be added to results of this operation in this RFE.
> {color:red}This RFE needs to add new operation to jax-rs subsystem, name of this operation could be "show-aggregated-statistics":
> /subsystem=jaxrs:show-aggregated-statistics(){color}
> There needs to be option to enable or disable collecting of these statistics, because collecting of statistics does probably some performance drop.
> The change of statistic settings should not require server reload or restart.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11833) Stateful Session Bean affinity URI instead of cluster
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-11833?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz edited comment on WFLY-11833 at 5/22/19 12:22 PM:
----------------------------------------------------------------------
There are a couple of problems with this code.
Remember that this case involves a remote client invoking a method on a SLSB which creates a SFSB on the server (using an injected @EJB instance on in the SLSB) and then returns the proxy to the client. This involves three EJB client proxies:
* the proxy used by the remote client to make the invocation on the SLSB (remote client proxy)
* a proxy created for the @EJB injected instance to allow invocations on the Home interface (for creating the SFSB instance) (home instance proxy)
* a proxy created for the new SFSB instance, and which is returned to the client (SFSB proxy)
The first problem is that the SFSB proxy is being assigned Affinity.LOCAL when it is created, which assumes that the proxy will only be used locally. THis does not take into account the fact that the proxy will be returned as a result to the remote client.
The second problem is that when an EJB client in a deployment makes an in-container invocation on an EJB in another deployment (or even the same deployment), the results and the exceptions of that invocation are cloned before being returned (I assume so that they can be moved from the EJB's classloading environment to the caller's classloading environment). In particular, if the result of the invocation is a proxy, the proxy gets cloned. A proxy is basically a wrapped instance of EJBInvocationHandler. JBoss Marshalling is used to do this and has a class called SerializedEJBInvocationHandler which is responsible for marshalling and unmarshalling an EJBInvocationHandler. This class normally carries a strong affinity (it its Locator) and a weak affinity. When marshalled, SerializedEJBInvocationHandler only includes the Locator and does not include the weak affinity in the serialised state. When unmarshalled, it uses readReplace() to take the Locator, create an EJBInvocationHandler instance and incorrectly sets the weak affinity based on the strong affinity. The real weak affinity is getting lost. Consequently, during the EJB client Home interface invocation to create the SFSB, where a proxy for the new bean is created and returned as a result, the proxy affinities get whacked from (strong, weak) = (Cluster("ejb"), Node("node-1") to (strong, weak) = (Cluster("ejb"), Cluster("ejb")), which is not correct. This is the proxy that gets sent back to the remote client.
was (Author: rachmato):
There are a couple of problems with this code.
Remember that this case involves a client invoking a method on a SLSB which creates a SFSB on the server (using an injected @EJB instance on in the SLSB) and then returns the proxy to the client. This involves three EJB client proxies:
* the proxy used by the remote client to make the invocation on the SLSB (remote client proxy)
* a proxy created for the @EJB injected instance to allow invocations on the Home interface (for creating the SFSB instance) (home instance proxy)
* a proxy created for the new SFSB instance, and which is returned to the client (SFSB proxy)
The first problem is that the SFSB proxy is being assigned Affinity.LOCAL when it is created, which assumes that the proxy will only be used locally. THis does not take into account the fact that the proxy will be returned as a result to the remote client.
The second problem is that when an EJB client in a deployment makes an in-container invocation on an EJB in another deployment (or even the same deployment), the results and the exceptions of that invocation are cloned before being returned (I assume so that they can be moved from the EJB's classloading environment to the caller's classloading environment). In particular, if the result of the invocation is a proxy, the proxy gets cloned. A proxy is basically a wrapped instance of EJBInvocationHandler. JBoss Marshalling is used to do this and has a class called SerializedEJBInvocationHandler which is responsible for marshalling and unmarshalling an EJBInvocationHandler. This class normally carries a strong affinity (it its Locator) and a weak affinity. When marshalled, SerializedEJBInvocationHandler only includes the Locator and does not include the weak affinity in the serialised state. When unmarshalled, it uses readReplace() to take the Locator, create an EJBInvocationHandler instance and incorrectly sets the weak affinity based on the strong affinity. The real weak affinity is getting lost. Consequently, during the EJB client Home interface invocation to create the SFSB, where a proxy for the new bean is created and returned as a result, the proxy affinities get whacked from (strong, weak) = (Cluster("ejb"), Node("node-1") to (strong, weak) = (Cluster("ejb"), Cluster("ejb")), which is not correct. This is the proxy that gets sent back to the remote client.
> Stateful Session Bean affinity URI instead of cluster
> -----------------------------------------------------
>
> Key: WFLY-11833
> URL: https://issues.jboss.org/browse/WFLY-11833
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 16.0.0.Final
> Environment: WildFly cluster having SFSB deployed.
> Reporter: Joerg Baesner
> Assignee: Richard Achmatowicz
> Priority: Major
> Labels: downstream_dependency
> Attachments: stateful-timeout.zip
>
>
> Deployed is an application with the following setup:
> * Containing a SFSB (_with passivationCapable="true"_)
> * A SLSB exposing a _remote_ method to a standalone client returning an instance of the SFSB
> Scenario:
> A standalone client is invoking the _remote_ method on the Stateless Session Bean and a new instance of the Stateful Session Bean is returned.
> The issue is that the affinity of the returned Stateful Session Bean is URI instead of Cluster.
> See the attached Gradle reproducer application
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11833) Stateful Session Bean affinity URI instead of cluster
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-11833?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz edited comment on WFLY-11833 at 5/22/19 12:22 PM:
----------------------------------------------------------------------
There are a couple of problems with this code.
Remember that this case involves a remote client invoking a method on a SLSB which creates a SFSB on the server (using an injected @EJB instance on in the SLSB) and then returns the proxy for the SFSB to the client. This involves three EJB client proxies:
* the proxy used by the remote client to make the invocation on the SLSB (remote client proxy)
* a proxy created for the @EJB injected instance to allow invocations on the Home interface (for creating the SFSB instance) (home instance proxy)
* a proxy created for the new SFSB instance, and which is returned to the client (SFSB proxy)
The first problem is that the SFSB proxy is being assigned Affinity.LOCAL when it is created, which assumes that the proxy will only be used locally. THis does not take into account the fact that the proxy will be returned as a result to the remote client.
The second problem is that when an EJB client in a deployment makes an in-container invocation on an EJB in another deployment (or even the same deployment), the results and the exceptions of that invocation are cloned before being returned (I assume so that they can be moved from the EJB's classloading environment to the caller's classloading environment). In particular, if the result of the invocation is a proxy, the proxy gets cloned. A proxy is basically a wrapped instance of EJBInvocationHandler. JBoss Marshalling is used to do this and has a class called SerializedEJBInvocationHandler which is responsible for marshalling and unmarshalling an EJBInvocationHandler. This class normally carries a strong affinity (it its Locator) and a weak affinity. When marshalled, SerializedEJBInvocationHandler only includes the Locator and does not include the weak affinity in the serialised state. When unmarshalled, it uses readReplace() to take the Locator, create an EJBInvocationHandler instance and incorrectly sets the weak affinity based on the strong affinity. The real weak affinity is getting lost. Consequently, during the EJB client Home interface invocation to create the SFSB, where a proxy for the new bean is created and returned as a result, the proxy affinities get whacked from (strong, weak) = (Cluster("ejb"), Node("node-1") to (strong, weak) = (Cluster("ejb"), Cluster("ejb")), which is not correct. This is the proxy that gets sent back to the remote client.
was (Author: rachmato):
There are a couple of problems with this code.
Remember that this case involves a remote client invoking a method on a SLSB which creates a SFSB on the server (using an injected @EJB instance on in the SLSB) and then returns the proxy to the client. This involves three EJB client proxies:
* the proxy used by the remote client to make the invocation on the SLSB (remote client proxy)
* a proxy created for the @EJB injected instance to allow invocations on the Home interface (for creating the SFSB instance) (home instance proxy)
* a proxy created for the new SFSB instance, and which is returned to the client (SFSB proxy)
The first problem is that the SFSB proxy is being assigned Affinity.LOCAL when it is created, which assumes that the proxy will only be used locally. THis does not take into account the fact that the proxy will be returned as a result to the remote client.
The second problem is that when an EJB client in a deployment makes an in-container invocation on an EJB in another deployment (or even the same deployment), the results and the exceptions of that invocation are cloned before being returned (I assume so that they can be moved from the EJB's classloading environment to the caller's classloading environment). In particular, if the result of the invocation is a proxy, the proxy gets cloned. A proxy is basically a wrapped instance of EJBInvocationHandler. JBoss Marshalling is used to do this and has a class called SerializedEJBInvocationHandler which is responsible for marshalling and unmarshalling an EJBInvocationHandler. This class normally carries a strong affinity (it its Locator) and a weak affinity. When marshalled, SerializedEJBInvocationHandler only includes the Locator and does not include the weak affinity in the serialised state. When unmarshalled, it uses readReplace() to take the Locator, create an EJBInvocationHandler instance and incorrectly sets the weak affinity based on the strong affinity. The real weak affinity is getting lost. Consequently, during the EJB client Home interface invocation to create the SFSB, where a proxy for the new bean is created and returned as a result, the proxy affinities get whacked from (strong, weak) = (Cluster("ejb"), Node("node-1") to (strong, weak) = (Cluster("ejb"), Cluster("ejb")), which is not correct. This is the proxy that gets sent back to the remote client.
> Stateful Session Bean affinity URI instead of cluster
> -----------------------------------------------------
>
> Key: WFLY-11833
> URL: https://issues.jboss.org/browse/WFLY-11833
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 16.0.0.Final
> Environment: WildFly cluster having SFSB deployed.
> Reporter: Joerg Baesner
> Assignee: Richard Achmatowicz
> Priority: Major
> Labels: downstream_dependency
> Attachments: stateful-timeout.zip
>
>
> Deployed is an application with the following setup:
> * Containing a SFSB (_with passivationCapable="true"_)
> * A SLSB exposing a _remote_ method to a standalone client returning an instance of the SFSB
> Scenario:
> A standalone client is invoking the _remote_ method on the Stateless Session Bean and a new instance of the Stateful Session Bean is returned.
> The issue is that the affinity of the returned Stateful Session Bean is URI instead of Cluster.
> See the attached Gradle reproducer application
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11956) @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method
by Ronald Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ]
Ronald Sigal resolved WFLY-11956.
---------------------------------
Resolution: Done
> @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11956
> URL: https://issues.jboss.org/browse/WFLY-11956
> Project: WildFly
> Issue Type: Bug
> Components: Bean Validation, REST
> Affects Versions: 16.0.0.Final
> Reporter: Joerg Baesner
> Assignee: Ronald Sigal
> Priority: Major
> Fix For: 17.0.0.Beta1
>
> Attachments: logging.txt, playground.zip
>
>
> Having a bean class with {{@ApplicationScoped}}, which has a {{@PostConstruct}} and is implementing the following _Interface_:
> {code}
> @Path("/validated")
> public interface ValidatedJaxRsInterface {
>
> @GET
> @Valid
> @Produces(MediaType.APPLICATION_JSON)
> GreetingModel getHelloGreeting();
> }
> {code}
> will result in calling the {{getHelloGreeting}} method of the implementation class twice *_before_* the {{@PostConstruct}} is getting executed.
> This can be reproduced with the attached reproducer application...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months