5:46 a.m.
Hi, what do you think of adding a "status" attribute for datasources ?
It should have the same meaning of "status" for deployment.
The deployment have the status attribute, that says if the application
was properly deployed and is running.
/deployment=jboss-kitchensink.war:read-attribute(name=status)
{
"outcome" => "success",
"result" => "FAILED"
}
However there is no way in CLI mode to ask if a datasource (RA also)
is working, user must check for exceptions in the log.
The proposal is to add an attribute status to a datasource and RA, it
will be true if test-connection-in-pool returns true, otherwise false.
Every moment the datasource configuration changes, a test-connection
is performed.
I came to this suggestion, as was working for a customer that has 16
datasources (they are migrating from weblogic) and there were some
connections errors, but the user was unable to see at once which
connections failed, they needed to grep log. It would be very useful
to have this attribute.
Kind regards
--
Claudio Miranda
claudio(a)claudius.com.br
http://www.claudius.com.br
9:47 a.m.
Doesn't the enabled attribute serve the same purpose? Ort do I miss something?
On 17 Oct 2014, at 05:46, Claudio Miranda <claudio(a)claudius.com.br> wrote:
Hi, what do you think of adding a "status" attribute for
datasources ?
It should have the same meaning of "status" for deployment.
The deployment have the status attribute, that says if the application
was properly deployed and is running.
/deployment=jboss-kitchensink.war:read-attribute(name=status)
{
"outcome" => "success",
"result" => "FAILED"
}
However there is no way in CLI mode to ask if a datasource (RA also)
is working, user must check for exceptions in the log.
The proposal is to add an attribute status to a datasource and RA, it
will be true if test-connection-in-pool returns true, otherwise false.
Every moment the datasource configuration changes, a test-connection
is performed.
I came to this suggestion, as was working for a customer that has 16
datasources (they are migrating from weblogic) and there were some
connections errors, but the user was unable to see at once which
connections failed, they needed to grep log. It would be very useful
to have this attribute.
Kind regards
--
Claudio Miranda
claudio(a)claudius.com.br
http://www.claudius.com.br
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
3:03 p.m.
On Fri, Oct 17, 2014 at 4:47 AM, Heiko Braun <hbraun(a)redhat.com> wrote:
Doesn't the enabled attribute serve the same purpose? Ort do I
miss something?
The enabled attribute sets the datasource to start at boot time.
If you provoke an error in the datasource settings, the connection
stays in error state but there is no indicator in the datasource CLI.
--
Claudio Miranda
claudio(a)claudius.com.br
http://www.claudius.com.br
9:10 p.m.
On Fri, Oct 17, 2014 at 10:03 AM, Claudio Miranda
<claudio(a)claudius.com.br> wrote:
The enabled attribute sets the datasource to start at boot time.
If you provoke an error in the datasource settings, the connection
stays in error state but there is no indicator in the datasource CLI.
What do you think ? May I open an issue for this ?
--
Claudio Miranda
claudio(a)claudius.com.br
http://www.claudius.com.br
10:16 p.m.
You need buy-in from the JCA team, as they are the ones who'd need to
accept the server-side change. AIUI your proposal is that any config
change that effects a ds resource would trigger an automatic connection
test, with this attribute set to the result. That's 95%+ of the work.
Exposing the attribute value in the console is the trivial part.
On 10/17/14, 2:10 PM, Claudio Miranda wrote:
On Fri, Oct 17, 2014 at 10:03 AM, Claudio Miranda
<claudio(a)claudius.com.br> wrote:
> The enabled attribute sets the datasource to start at boot time.
> If you provoke an error in the datasource settings, the connection
> stays in error state but there is no indicator in the datasource CLI.
What do you think ? May I open an issue for this ?
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
4:02 p.m.
On 10/16/2014 11:46 PM, Claudio Miranda wrote:
Hi, what do you think of adding a "status" attribute for
datasources ?
It should have the same meaning of "status" for deployment.
The deployment have the status attribute, that says if the application
was properly deployed and is running.
/deployment=jboss-kitchensink.war:read-attribute(name=status)
{
"outcome" => "success",
"result" => "FAILED"
}
However there is no way in CLI mode to ask if a datasource (RA also)
is working, user must check for exceptions in the log.
The proposal is to add an attribute status to a datasource and RA, it
will be true if test-connection-in-pool returns true, otherwise false.
Every moment the datasource configuration changes, a test-connection
is performed.
I came to this suggestion, as was working for a customer that has 16
datasources (they are migrating from weblogic) and there were some
connections errors, but the user was unable to see at once which
connections failed, they needed to grep log. It would be very useful
to have this attribute.
:test-connection-in-pool may require credentials, so it will only be
'automatic' in some cases.
You could do your own 'extension' on top of the :test-connection-in-pool
though.
HTH.
Best regards,
Jesper
5:45 p.m.
On Mon, Oct 20, 2014 at 12:02 PM, Jesper Pedersen
<jesper.pedersen(a)redhat.com> wrote:
:test-connection-in-pool may require credentials, so it will only be
'automatic' in some cases.
Hi Jesper, the purpose is to add a "status" runtime attribute to the
datasource, see my initial post.
Instead of call test-connection-in-pool for every datasource change,
better to rely on current behavior, when application requests a new
connection, the status attribute is populated accordingly to the new
connection call, what do you think ?
This is to improve user experience with wildfly/eap customers, to
quickly see in the web console which datasources failed to open
connections.
------------
What do you think of adding a "status" attribute for datasources ?
It should have the same meaning of "status" for deployment.
The deployment have the status attribute, that says if the application
was properly deployed and is running.
/deployment=jboss-kitchensink.
war:read-attribute(name=status)
{
"outcome" => "success",
"result" => "FAILED"
}
However there is no way in CLI mode to ask if a datasource (RA also)
is working, user must check for exceptions in the log.
The proposal is to add an attribute status to a datasource and RA, it
will be true if test-connection-in-pool returns true, otherwise false.
Every moment the datasource configuration changes, a test-connection
is performed.
I came to this suggestion, as was working for a customer that has 16
datasources (they are migrating from weblogic) and there were some
connections errors, but the user was unable to see at once which
connections failed, they needed to grep log. It would be very useful
to have this attribute.
--
Claudio Miranda
claudio(a)claudius.com.br
http://www.claudius.com.br
6:56 p.m.
Hi,
On 10/20/2014 11:45 AM, Claudio Miranda wrote:
On Mon, Oct 20, 2014 at 12:02 PM, Jesper Pedersen
<jesper.pedersen(a)redhat.com> wrote:
> :test-connection-in-pool may require credentials, so it will only be
> 'automatic' in some cases.
Hi Jesper, the purpose is to add a "status" runtime attribute to the
datasource, see my initial post.
Instead of call test-connection-in-pool for every datasource change,
better to rely on current behavior, when application requests a new
connection, the status attribute is populated accordingly to the new
connection call, what do you think ?
That is not going to happen, as testing :test-connection-in-pool per
request could have a massive overhead depending on the pool status.
<validation> should be used to verify an active pool.
This is to improve user experience with wildfly/eap customers, to
quickly see in the web console which datasources failed to open
connections.
Yes, I know that - but I fail to see how a 'false' value would be of
benefit to the user experience even if the datasource is active and valid.
Standard scenarios: pool is full (check InUse count if statistics is
enabled), missing credentials (pass those in), ...
I would rather see a CLI script that goes through the different
scenarios that could occur and present the result. Same script could be
executed from the web console, or 'hidden' behind a special "Status"
field.
Best regards,
Jesper
3469
days inactive
3472
days old
8 comments
4 participants
participants (4)
-
Brian Stansberry -
Claudio Miranda -
Heiko Braun -
Jesper Pedersen