Bug 1014103 - Issue warning when user sets non-existent DLQ/expiry address to address settings in CLI
Issue warning when user sets non-existent DLQ/expiry address to address setti...
Status: NEW
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: HornetQ (Show other bugs)
6.2.0
Unspecified Unspecified
unspecified Severity low
: ---
: ---
Assigned To: Clebert Suconic
Miroslav Novak
:
Depends On: 1014095
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-01 08:25 EDT by Martin Svehla
Modified: 2017-10-09 20:20 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Feature Request
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Martin Svehla 2013-10-01 08:25:29 EDT
Description of problem:
Issue warning to user when she tries to set address-settings dead letter address and/or expiry address to non-existent destination in CLI client.


Version-Release number of selected component (if applicable):
EAP 6.2.0.ER3, HornetQ 2.3.8.Final
Comment 1 Martin Svehla 2013-10-01 08:27:20 EDT
See #1014095 for related discussion.
Comment 2 Martin Svehla 2013-10-01 08:30:04 EDT
Proper link: bug 1014095
Comment 3 Jeff Mesnil 2014-01-29 10:09:49 EST
I am not sure how we can fix this in the messaging component. HornetQ does not provide a way to tell if an address exists or not in their management API.

Once they add this, we can provide some checks when the user sets them in the address-settings.
Comment 4 Clebert Suconic 2014-01-29 17:56:35 EST
I'm working on the implementation and there's a side effect on this.


the DLQ and Expiry are deployed through address settings which are using matching algorithms.


I'm implementing a listener on the address settings to verify it any time the settings have changed.

If you have a wrong address, it will throw the log.warn every time the settings are changed. Say if you deploy a new element all the queues will be validated again.


So, if you deploy a wrong address... say.. IDONTExist.. and later you deploy AD1.. AD2... AD3.. say 5 minutes apart... IDONTEXIST will be logged 3 times.


Anyone sees a problem on this approach?
Comment 5 Clebert Suconic 2014-01-29 18:02:01 EST
Never mind, I will add a check and only throw the exception once for a given address
Comment 6 Clebert Suconic 2014-01-29 18:02:13 EST
I meant the log.warn
Comment 7 Martin Svehla 2014-01-30 02:39:36 EST
Does that mean that if the user changes address-settings in WildFly's CLI client, she will only see the warn message in server log or are we gonna be able to get the warning to CLI client as well?

While I would prefer warning in CLI client too, if that's too much hassle I'm ok with it just being in the server log. In that case I would close this bug, since there won't be any work necessary on integration side, and we'll move this under bug 1014095
Comment 8 Clebert Suconic 2014-01-30 09:32:25 EST
I'm doing it at the server's log...

I'm adding a method that Jeff can use to make it on the CLI.
Comment 9 Martin Svehla 2014-01-30 10:03:38 EST
@Clebert, awesome, thanks

Note You need to log in before you can comment on or make changes to this bug.