[JBoss JIRA] (WFLY-9624) Improper handling of application exceptions on asynchronous ejb invocations
by Andrej Kolontai (JIRA)
[ https://issues.jboss.org/browse/WFLY-9624?page=com.atlassian.jira.plugin.... ]
Andrej Kolontai updated WFLY-9624:
----------------------------------
Description:
If an asynchronous invocation of an ejb method throws an application exception (declared exception) then the returned future will always return false on isDone(). That means: the client will never know that the operation has finished (unscuccessfully) unless get() is called which would rethrow the original exception.
This behavior has changed from wildfly 10.1.0.Final to 11.0.0.Final.
I pretty sure that the problem is in org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.
The isDone Method is implemented like this:
{noformat}
@Override
public boolean isDone() {
return status == ST_DONE;
}
{noformat}
But status can be one of:
{noformat}
private static final int ST_RUNNING = 0;
private static final int ST_DONE = 1;
private static final int ST_CANCELLED = 2;
private static final int ST_FAILED = 3;
{noformat}
And and exception sets the status to
{noformat}
private synchronized void setFailed(final Exception e) {
this.failed = e;
status = ST_FAILED;
done();
}
{noformat}
So it's pretty obvious.
The javadoc on java.util.concurrent.Future states:
{quote}
Completion may be due to normal termination, an exception, or cancellation -- in all of these cases, this method will return true.
{quote}
So the isDone() method should look more like this:
{noformat}
@Override
public boolean isDone() {
return status == ST_DONE || status == ST_FAILED || status == ST_CANCELLED;
}
{noformat}
In wildfly 10, there was a single boolean variable "done" which was set to true in all three cases:
* cancel()
* setResult(...) and
* setFailed(...)
was:
If an asynchronous invocation of an ejb method throws an application exception (declared exception) then the returned future will always return false on isDone(). That means: the client will never know that the operation has finished (unscuccessfully) unless get() is called which would rethrow the original exception.
This behavior has changed from wildfly 10.1.0.Final to 11.0.0.Final.
I pretty sure that the problem is in org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.
The isDone Method is implemented like this:
{{@Override
public boolean isDone() {
return status == ST_DONE;
}}}
But status can be one of:
{{
private static final int ST_RUNNING = 0;
private static final int ST_DONE = 1;
private static final int ST_CANCELLED = 2;
private static final int ST_FAILED = 3;
}}
And and exception sets the status to
{{
private synchronized void setFailed(final Exception e) {
this.failed = e;
status = ST_FAILED;
done();
}
}}
So it's pretty obvious.
The javadoc on java.util.concurrent.Future states:
{quote}
Completion may be due to normal termination, an exception, or cancellation -- in all of these cases, this method will return true.
{quote}
So the isDone() method should look more like this:
{{
@Override
public boolean isDone() {
return status == ST_DONE || status == ST_FAILED || status == ST_CANCELLED;
}
}}
In wildfly 10, there was a single boolean variable "done" which was set to true in all three cases:
* cancel()
* setResult(...) and
* setFailed(...)
> Improper handling of application exceptions on asynchronous ejb invocations
> ---------------------------------------------------------------------------
>
> Key: WFLY-9624
> URL: https://issues.jboss.org/browse/WFLY-9624
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 11.0.0.Final
> Reporter: Andrej Kolontai
>
> If an asynchronous invocation of an ejb method throws an application exception (declared exception) then the returned future will always return false on isDone(). That means: the client will never know that the operation has finished (unscuccessfully) unless get() is called which would rethrow the original exception.
> This behavior has changed from wildfly 10.1.0.Final to 11.0.0.Final.
> I pretty sure that the problem is in org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.
> The isDone Method is implemented like this:
> {noformat}
> @Override
> public boolean isDone() {
> return status == ST_DONE;
> }
> {noformat}
> But status can be one of:
> {noformat}
> private static final int ST_RUNNING = 0;
> private static final int ST_DONE = 1;
> private static final int ST_CANCELLED = 2;
> private static final int ST_FAILED = 3;
> {noformat}
> And and exception sets the status to
> {noformat}
> private synchronized void setFailed(final Exception e) {
> this.failed = e;
> status = ST_FAILED;
> done();
> }
> {noformat}
> So it's pretty obvious.
> The javadoc on java.util.concurrent.Future states:
> {quote}
> Completion may be due to normal termination, an exception, or cancellation -- in all of these cases, this method will return true.
> {quote}
> So the isDone() method should look more like this:
> {noformat}
> @Override
> public boolean isDone() {
> return status == ST_DONE || status == ST_FAILED || status == ST_CANCELLED;
> }
> {noformat}
> In wildfly 10, there was a single boolean variable "done" which was set to true in all three cases:
> * cancel()
> * setResult(...) and
> * setFailed(...)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (WFLY-9624) Improper handling of application exceptions on asynchronous ejb invocations
by Andrej Kolontai (JIRA)
[ https://issues.jboss.org/browse/WFLY-9624?page=com.atlassian.jira.plugin.... ]
Andrej Kolontai updated WFLY-9624:
----------------------------------
Steps to Reproduce:
Create the following ejb:
{noformat}
@Singleton
public class AsyncBean {
@Asynchronous
public Future<Void> doSomeStuff() throws MyException {
throw new MyException();
}
}
{noformat}
Call ths bean and poll the result via isDone(). It will never return true.
On wildfly 10, it would immidiatly return true.
was:
Create the following ejb:
{{
@Singleton
public class AsyncBean {
@Asynchronous
public Future<Void> doSomeStuff() throws MyException {
throw new MyException();
}
}
}}
Call ths bean and poll the result via isDone(). It will never return true.
On wildfly 10, it would immidiatly return true.
> Improper handling of application exceptions on asynchronous ejb invocations
> ---------------------------------------------------------------------------
>
> Key: WFLY-9624
> URL: https://issues.jboss.org/browse/WFLY-9624
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 11.0.0.Final
> Reporter: Andrej Kolontai
>
> If an asynchronous invocation of an ejb method throws an application exception (declared exception) then the returned future will always return false on isDone(). That means: the client will never know that the operation has finished (unscuccessfully) unless get() is called which would rethrow the original exception.
> This behavior has changed from wildfly 10.1.0.Final to 11.0.0.Final.
> I pretty sure that the problem is in org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.
> The isDone Method is implemented like this:
> {{@Override
> public boolean isDone() {
> return status == ST_DONE;
> }}}
> But status can be one of:
> {{
> private static final int ST_RUNNING = 0;
> private static final int ST_DONE = 1;
> private static final int ST_CANCELLED = 2;
> private static final int ST_FAILED = 3;
> }}
> And and exception sets the status to
> {{
> private synchronized void setFailed(final Exception e) {
> this.failed = e;
> status = ST_FAILED;
> done();
> }
> }}
> So it's pretty obvious.
> The javadoc on java.util.concurrent.Future states:
> {quote}
> Completion may be due to normal termination, an exception, or cancellation -- in all of these cases, this method will return true.
> {quote}
> So the isDone() method should look more like this:
> {{
> @Override
> public boolean isDone() {
> return status == ST_DONE || status == ST_FAILED || status == ST_CANCELLED;
> }
> }}
> In wildfly 10, there was a single boolean variable "done" which was set to true in all three cases:
> * cancel()
> * setResult(...) and
> * setFailed(...)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (LOGMGR-139) Add maxBackupIndex to periodic-rotating-file-handlers
by Roland Brackmann (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-139?page=com.atlassian.jira.plugin... ]
Roland Brackmann commented on LOGMGR-139:
-----------------------------------------
Hi [~jamezp] for the record, this is a feature we were looking for aswell and opened this ticket hoping for an RFE :
https://access.redhat.com/support/cases/#/case/01989912
Our use case : being in docker and obliged to write on the filesystem for logging (not the container way of logging) it would be even more any container to spin up a cron job in the background...
> Add maxBackupIndex to periodic-rotating-file-handlers
> -----------------------------------------------------
>
> Key: LOGMGR-139
> URL: https://issues.jboss.org/browse/LOGMGR-139
> Project: JBoss Log Manager
> Issue Type: Enhancement
> Reporter: Rémy Garrigue
> Priority: Minor
>
> That's all in the title.
> We would like to have a daily log, keeping 15 days of log. Actually there's no way to do that except maybe custom handler which we can't get to work. That'ld be far easier if there was the same maxBackupIndex option as in size rotating handler.
> Regards,
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (WFLY-9624) Improper handling of application exceptions on asynchronous ejb invocations
by Andrej Kolontai (JIRA)
[ https://issues.jboss.org/browse/WFLY-9624?page=com.atlassian.jira.plugin.... ]
Andrej Kolontai updated WFLY-9624:
----------------------------------
Description:
If an asynchronous invocation of an ejb method throws an application exception (declared exception) then the returned future will always return false on isDone(). That means: the client will never know that the operation has finished (unscuccessfully) unless get() is called which would rethrow the original exception.
This behavior has changed from wildfly 10.1.0.Final to 11.0.0.Final.
I pretty sure that the problem is in org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.
The isDone Method is implemented like this:
{{@Override
public boolean isDone() {
return status == ST_DONE;
}}}
But status can be one of:
{{
private static final int ST_RUNNING = 0;
private static final int ST_DONE = 1;
private static final int ST_CANCELLED = 2;
private static final int ST_FAILED = 3;
}}
And and exception sets the status to
{{
private synchronized void setFailed(final Exception e) {
this.failed = e;
status = ST_FAILED;
done();
}
}}
So it's pretty obvious.
The javadoc on java.util.concurrent.Future states:
{quote}
Completion may be due to normal termination, an exception, or cancellation -- in all of these cases, this method will return true.
{quote}
So the isDone() method should look more like this:
{{
@Override
public boolean isDone() {
return status == ST_DONE || status == ST_FAILED || status == ST_CANCELLED;
}
}}
In wildfly 10, there was a single boolean variable "done" which was set to true in all three cases:
* cancel()
* setResult(...) and
* setFailed(...)
was:
If an asynchronous invocation of an ejb method throws an application exception (declared exception) then the returned future will always return false on isDone(). That means: the client will never know that the operation has finished (unscuccessfully) unless get() is called which would rethrow the original exception.
This behavior has changed from wildfly 10.1.0.Final to 11.0.0.Final.
I pretty sure that the problem is in org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.
The isDone Method is implemented like this:
{{
@Override
public boolean isDone() {
return status == ST_DONE;
}
}}
But status can be one of:
{{
private static final int ST_RUNNING = 0;
private static final int ST_DONE = 1;
private static final int ST_CANCELLED = 2;
private static final int ST_FAILED = 3;
}}
And and exception sets the status to
{{
private synchronized void setFailed(final Exception e) {
this.failed = e;
status = ST_FAILED;
done();
}
}}
So it's pretty obvious.
The javadoc on java.util.concurrent.Future states:
{quote}
Completion may be due to normal termination, an exception, or cancellation -- in all of these cases, this method will return true.
{quote}
So the isDone() method should look more like this:
{{
@Override
public boolean isDone() {
return status == ST_DONE || status == ST_FAILED || status == ST_CANCELLED;
}
}}
In wildfly 10, there was a single boolean variable "done" which was set to true in all three cases:
* cancel()
* setResult(...) and
* setFailed(...)
> Improper handling of application exceptions on asynchronous ejb invocations
> ---------------------------------------------------------------------------
>
> Key: WFLY-9624
> URL: https://issues.jboss.org/browse/WFLY-9624
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 11.0.0.Final
> Reporter: Andrej Kolontai
>
> If an asynchronous invocation of an ejb method throws an application exception (declared exception) then the returned future will always return false on isDone(). That means: the client will never know that the operation has finished (unscuccessfully) unless get() is called which would rethrow the original exception.
> This behavior has changed from wildfly 10.1.0.Final to 11.0.0.Final.
> I pretty sure that the problem is in org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.
> The isDone Method is implemented like this:
> {{@Override
> public boolean isDone() {
> return status == ST_DONE;
> }}}
> But status can be one of:
> {{
> private static final int ST_RUNNING = 0;
> private static final int ST_DONE = 1;
> private static final int ST_CANCELLED = 2;
> private static final int ST_FAILED = 3;
> }}
> And and exception sets the status to
> {{
> private synchronized void setFailed(final Exception e) {
> this.failed = e;
> status = ST_FAILED;
> done();
> }
> }}
> So it's pretty obvious.
> The javadoc on java.util.concurrent.Future states:
> {quote}
> Completion may be due to normal termination, an exception, or cancellation -- in all of these cases, this method will return true.
> {quote}
> So the isDone() method should look more like this:
> {{
> @Override
> public boolean isDone() {
> return status == ST_DONE || status == ST_FAILED || status == ST_CANCELLED;
> }
> }}
> In wildfly 10, there was a single boolean variable "done" which was set to true in all three cases:
> * cancel()
> * setResult(...) and
> * setFailed(...)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (WFLY-9624) Improper handling of application exceptions on asynchronous ejb invocations
by Andrej Kolontai (JIRA)
Andrej Kolontai created WFLY-9624:
-------------------------------------
Summary: Improper handling of application exceptions on asynchronous ejb invocations
Key: WFLY-9624
URL: https://issues.jboss.org/browse/WFLY-9624
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 11.0.0.Final
Reporter: Andrej Kolontai
If an asynchronous invocation of an ejb method throws an application exception (declared exception) then the returned future will always return false on isDone(). That means: the client will never know that the operation has finished (unscuccessfully) unless get() is called which would rethrow the original exception.
This behavior has changed from wildfly 10.1.0.Final to 11.0.0.Final.
I pretty sure that the problem is in org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.
The isDone Method is implemented like this:
{{
@Override
public boolean isDone() {
return status == ST_DONE;
}
}}
But status can be one of:
{{
private static final int ST_RUNNING = 0;
private static final int ST_DONE = 1;
private static final int ST_CANCELLED = 2;
private static final int ST_FAILED = 3;
}}
And and exception sets the status to
{{
private synchronized void setFailed(final Exception e) {
this.failed = e;
status = ST_FAILED;
done();
}
}}
So it's pretty obvious.
The javadoc on java.util.concurrent.Future states:
{quote}
Completion may be due to normal termination, an exception, or cancellation -- in all of these cases, this method will return true.
{quote}
So the isDone() method should look more like this:
{{
@Override
public boolean isDone() {
return status == ST_DONE || status == ST_FAILED || status == ST_CANCELLED;
}
}}
In wildfly 10, there was a single boolean variable "done" which was set to true in all three cases:
* cancel()
* setResult(...) and
* setFailed(...)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (WFCORE-3467) Require existence of the AttributeDefinition in AbstractWriteAttributeHandler
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3467:
----------------------------------------
Summary: Require existence of the AttributeDefinition in AbstractWriteAttributeHandler
Key: WFCORE-3467
URL: https://issues.jboss.org/browse/WFCORE-3467
Project: WildFly Core
Issue Type: Task
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
AbstractWriteAttributeHandler has logic to deal with the case where it has no reference to an AttributeDefinition for the relevant attribute. This is compatibility code from the days before AttributeDefinition. But using AD has been the standard for many years now, so lets drop this and fail if there is no AD.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (DROOLS-2193) MVEL Dialect cannot find the FH when using modify on a DataSource
by Lance Leverich (JIRA)
Lance Leverich created DROOLS-2193:
--------------------------------------
Summary: MVEL Dialect cannot find the FH when using modify on a DataSource
Key: DROOLS-2193
URL: https://issues.jboss.org/browse/DROOLS-2193
Project: Drools
Issue Type: Bug
Components: core engine
Reporter: Lance Leverich
Assignee: Mario Fusco
Attempting to use _modify_ on a fact that is retrieved from a DataSource will sometimes cause an error that reads:
{{Update error: handle not found for object: ...}}
Using dialect "java" fixes the issue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (WFCORE-3466) Add reflection option to org.jboss.as.controller.parsing.ExtensionParsingContext
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3466?page=com.atlassian.jira.plugi... ]
Brian Stansberry edited comment on WFCORE-3466 at 12/19/17 6:28 PM:
--------------------------------------------------------------------
Besides eliminating the cost of the Suppliers, we really want to get rid of the loading of the parser impl Class, and only load it if we actually encounter the namespace that demands it.
Exception being the current parser, which we often want to load during Extension.initializeParsers, since in most subsystems that means the subsystem static initialization stuff (AttributeDefinition etc) gets run during the concurrent part of boot.
was (Author: brian.stansberry):
Besides eliminating the cost of the Suppliers, we really want to get rid of the loading of the parser impl Class, and only load it if we actually encounter the namespace that demands it.
> Add reflection option to org.jboss.as.controller.parsing.ExtensionParsingContext
> --------------------------------------------------------------------------------
>
> Key: WFCORE-3466
> URL: https://issues.jboss.org/browse/WFCORE-3466
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: David Lloyd
>
> As a way to combat aggressive class initialization, WFCORE-1841 added a variant method to {{ExtensionParsingContext}} which allowed a supplier of a parser to be provided.
> This has resulted in an explosion of lambda usage; around 150 calls to this method exist, most of which supply constructor references as the {{Supplier}} argument.
> We can theoretically save considerable metaspace by doing one of the following:
> * Add a variation of the method which accepts a {{Class}} instead of a {{Supplier}}; it uses {{Class.newInstance()}} or {{Class.getConstructor().newInstance()}} to instantiate the parser on demand
> * Create a reflective {{Supplier}} implementation which, given a {{Class}}, uses it in this way to construct instances
> Performance impact should be very minimal, as the overhead of calling a constructor is less than that of compiling a method reference, and the overhead in metaspace is nearly non-existent in comparison.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (WFCORE-3466) Add reflection option to org.jboss.as.controller.parsing.ExtensionParsingContext
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3466?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3466:
------------------------------------------
Besides eliminating the cost of the Suppliers, we really want to get rid of the loading of the parser impl Class, and only load it if we actually encounter the namespace that demands it.
> Add reflection option to org.jboss.as.controller.parsing.ExtensionParsingContext
> --------------------------------------------------------------------------------
>
> Key: WFCORE-3466
> URL: https://issues.jboss.org/browse/WFCORE-3466
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: David Lloyd
>
> As a way to combat aggressive class initialization, WFCORE-1841 added a variant method to {{ExtensionParsingContext}} which allowed a supplier of a parser to be provided.
> This has resulted in an explosion of lambda usage; around 150 calls to this method exist, most of which supply constructor references as the {{Supplier}} argument.
> We can theoretically save considerable metaspace by doing one of the following:
> * Add a variation of the method which accepts a {{Class}} instead of a {{Supplier}}; it uses {{Class.newInstance()}} or {{Class.getConstructor().newInstance()}} to instantiate the parser on demand
> * Create a reflective {{Supplier}} implementation which, given a {{Class}}, uses it in this way to construct instances
> Performance impact should be very minimal, as the overhead of calling a constructor is less than that of compiling a method reference, and the overhead in metaspace is nearly non-existent in comparison.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months