5:25 p.m.
Refactor Notifiers
------------------
Key: JBESB-452
URL: http://jira.jboss.com/jira/browse/JBESB-452
Project: JBoss ESB
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 4.0
Environment: any
Reporter: Kurt Stam
Assigned To: Mark Little
Priority: Critical
Fix For: 4.2
These comments are based on the JMS notifiers but will probably apply to the other
notifiers as well:
1. The notifiers should be more like listeners where you get one (or more instances).
Until they get recycled when there is a config change. Right now the JMS onces
connected and disconnect with every message, which causes stress on the JMS provider when
running in high load mode.
2. They should get their 'provider' configuration from the configuration, just
like the listeners. Right now you cannot connect to other JMS providers.
3. The notifiers should get hooked up to the same life cycle management as the listener
infrastructure.
In other words: They really should be 'inverse gateways', the model is broken and
there shouldn't be a distinction between notifying and sending a message via
couriers+listeners. The fact we support different transports (and in different ways) for
notifiers than for the "core" ESB is just wrong.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:37 p.m.
New subject: [JBoss JIRA] Updated: (JBESB-452) Refactor Notifiers
[ http://jira.jboss.com/jira/browse/JBESB-452?page=all ]
Mark Little updated JBESB-452:
------------------------------
Component/s: Rosetta
Refactor Notifiers
------------------
Key: JBESB-452
URL: http://jira.jboss.com/jira/browse/JBESB-452
Project: JBoss ESB
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Rosetta
Affects Versions: 4.0
Environment: any
Reporter: Kurt Stam
Assigned To: Mark Little
Priority: Critical
Fix For: 4.2
These comments are based on the JMS notifiers but will probably apply to the other
notifiers as well:
1. The notifiers should be more like listeners where you get one (or more instances).
Until they get recycled when there is a config change. Right now the JMS onces
connected and disconnect with every message, which causes stress on the JMS provider when
running in high load mode.
2. They should get their 'provider' configuration from the configuration, just
like the listeners. Right now you cannot connect to other JMS providers.
3. The notifiers should get hooked up to the same life cycle management as the listener
infrastructure.
In other words: They really should be 'inverse gateways', the model is broken and
there shouldn't be a distinction between notifying and sending a message via
couriers+listeners. The fact we support different transports (and in different ways) for
notifiers than for the "core" ESB is just wrong.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:43 a.m.
New subject: [JBoss JIRA] Work started: (JBESB-452) Refactor Notifiers
[ http://jira.jboss.com/jira/browse/JBESB-452?page=all ]
Work on JBESB-452 started by Mark Little.
Refactor Notifiers
------------------
Key: JBESB-452
URL: http://jira.jboss.com/jira/browse/JBESB-452
Project: JBoss ESB
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Rosetta
Affects Versions: 4.0
Environment: any
Reporter: Kurt Stam
Assigned To: Mark Little
Priority: Critical
Fix For: 4.2
These comments are based on the JMS notifiers but will probably apply to the other
notifiers as well:
1. The notifiers should be more like listeners where you get one (or more instances).
Until they get recycled when there is a config change. Right now the JMS onces
connected and disconnect with every message, which causes stress on the JMS provider when
running in high load mode.
2. They should get their 'provider' configuration from the configuration, just
like the listeners. Right now you cannot connect to other JMS providers.
3. The notifiers should get hooked up to the same life cycle management as the listener
infrastructure.
In other words: They really should be 'inverse gateways', the model is broken and
there shouldn't be a distinction between notifying and sending a message via
couriers+listeners. The fact we support different transports (and in different ways) for
notifiers than for the "core" ESB is just wrong.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:43 a.m.
New subject: [JBoss JIRA] Work logged: (JBESB-452) Refactor Notifiers
[ http://jira.jboss.com/jira/browse/JBESB-452?page=worklog#action_12363260 ]
Mark Little logged work on JBESB-452:
-------------------------------------
Time Spent: 4 hours
Remaining Estimate: 0 minutes
Time Spent: 4 hours
Collective discussions.
Refactor Notifiers
------------------
Key: JBESB-452
URL: http://jira.jboss.com/jira/browse/JBESB-452
Project: JBoss ESB
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Rosetta
Affects Versions: 4.0
Environment: any
Reporter: Kurt Stam
Assigned To: Mark Little
Priority: Critical
Fix For: 4.2
Time Spent: 4 hours
Remaining Estimate: 0 minutes
These comments are based on the JMS notifiers but will probably apply to the other
notifiers as well:
1. The notifiers should be more like listeners where you get one (or more instances).
Until they get recycled when there is a config change. Right now the JMS onces
connected and disconnect with every message, which causes stress on the JMS provider when
running in high load mode.
2. They should get their 'provider' configuration from the configuration, just
like the listeners. Right now you cannot connect to other JMS providers.
3. The notifiers should get hooked up to the same life cycle management as the listener
infrastructure.
In other words: They really should be 'inverse gateways', the model is broken and
there shouldn't be a distinction between notifying and sending a message via
couriers+listeners. The fact we support different transports (and in different ways) for
notifiers than for the "core" ESB is just wrong.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:58 a.m.
New subject: [JBoss JIRA] Work stopped: (JBESB-452) Refactor Notifiers
[ http://jira.jboss.com/jira/browse/JBESB-452?page=all ]
Work on JBESB-452 stopped by Mark Little.
Refactor Notifiers
------------------
Key: JBESB-452
URL: http://jira.jboss.com/jira/browse/JBESB-452
Project: JBoss ESB
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Rosetta
Affects Versions: 4.0
Environment: any
Reporter: Kurt Stam
Assigned To: Mark Little
Priority: Critical
Fix For: 4.2
Time Spent: 4 hours
Remaining Estimate: 0 minutes
These comments are based on the JMS notifiers but will probably apply to the other
notifiers as well:
1. The notifiers should be more like listeners where you get one (or more instances).
Until they get recycled when there is a config change. Right now the JMS onces
connected and disconnect with every message, which causes stress on the JMS provider when
running in high load mode.
2. They should get their 'provider' configuration from the configuration, just
like the listeners. Right now you cannot connect to other JMS providers.
3. The notifiers should get hooked up to the same life cycle management as the listener
infrastructure.
In other words: They really should be 'inverse gateways', the model is broken and
there shouldn't be a distinction between notifying and sending a message via
couriers+listeners. The fact we support different transports (and in different ways) for
notifiers than for the "core" ESB is just wrong.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:35 a.m.
New subject: [JBoss JIRA] Commented: (JBESB-452) Refactor Notifiers
[ http://jira.jboss.com/jira/browse/JBESB-452?page=comments#action_12366560 ]
Mark Little commented on JBESB-452:
-----------------------------------
No time to refactor and we'd have to support the old style anyway for backward
compatibility. Let's just make sure this code is hardened and encourage other
approaches (e.g., JCA) for getting outflow to non-ESB components in 4.2. After the GA we
can look at doing something else.
Refactor Notifiers
------------------
Key: JBESB-452
URL: http://jira.jboss.com/jira/browse/JBESB-452
Project: JBoss ESB
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Rosetta
Affects Versions: 4.0
Environment: any
Reporter: Kurt Stam
Assigned To: Mark Little
Priority: Critical
Fix For: 4.2
Time Spent: 4 hours
Remaining Estimate: 0 minutes
These comments are based on the JMS notifiers but will probably apply to the other
notifiers as well:
1. The notifiers should be more like listeners where you get one (or more instances).
Until they get recycled when there is a config change. Right now the JMS onces
connected and disconnect with every message, which causes stress on the JMS provider when
running in high load mode.
2. They should get their 'provider' configuration from the configuration, just
like the listeners. Right now you cannot connect to other JMS providers.
3. The notifiers should get hooked up to the same life cycle management as the listener
infrastructure.
In other words: They really should be 'inverse gateways', the model is broken and
there shouldn't be a distinction between notifying and sending a message via
couriers+listeners. The fact we support different transports (and in different ways) for
notifiers than for the "core" ESB is just wrong.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:28 a.m.
New subject: [JBoss JIRA] Assigned: (JBESB-452) Refactor Notifiers
[ http://jira.jboss.com/jira/browse/JBESB-452?page=all ]
Mark Little reassigned JBESB-452:
---------------------------------
Assignee: Daniel Bevenius (was: Mark Little)
Refactor Notifiers
------------------
Key: JBESB-452
URL: http://jira.jboss.com/jira/browse/JBESB-452
Project: JBoss ESB
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Rosetta
Affects Versions: 4.0
Environment: any
Reporter: Kurt Stam
Assigned To: Daniel Bevenius
Priority: Critical
Fix For: 4.2
Time Spent: 4 hours
Remaining Estimate: 0 minutes
These comments are based on the JMS notifiers but will probably apply to the other
notifiers as well:
1. The notifiers should be more like listeners where you get one (or more instances).
Until they get recycled when there is a config change. Right now the JMS onces
connected and disconnect with every message, which causes stress on the JMS provider when
running in high load mode.
2. They should get their 'provider' configuration from the configuration, just
like the listeners. Right now you cannot connect to other JMS providers.
3. The notifiers should get hooked up to the same life cycle management as the listener
infrastructure.
In other words: They really should be 'inverse gateways', the model is broken and
there shouldn't be a distinction between notifying and sending a message via
couriers+listeners. The fact we support different transports (and in different ways) for
notifiers than for the "core" ESB is just wrong.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:09 p.m.
New subject: [JBoss JIRA] Work started: (JBESB-452) Refactor Notifiers
[ http://jira.jboss.com/jira/browse/JBESB-452?page=all ]
Work on JBESB-452 started by Daniel Bevenius.
Refactor Notifiers
------------------
Key: JBESB-452
URL: http://jira.jboss.com/jira/browse/JBESB-452
Project: JBoss ESB
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Rosetta
Affects Versions: 4.0
Environment: any
Reporter: Kurt Stam
Assigned To: Daniel Bevenius
Priority: Critical
Fix For: 4.2
Time Spent: 4 hours
Remaining Estimate: 0 minutes
These comments are based on the JMS notifiers but will probably apply to the other
notifiers as well:
1. The notifiers should be more like listeners where you get one (or more instances).
Until they get recycled when there is a config change. Right now the JMS onces
connected and disconnect with every message, which causes stress on the JMS provider when
running in high load mode.
2. They should get their 'provider' configuration from the configuration, just
like the listeners. Right now you cannot connect to other JMS providers.
3. The notifiers should get hooked up to the same life cycle management as the listener
infrastructure.
In other words: They really should be 'inverse gateways', the model is broken and
there shouldn't be a distinction between notifying and sending a message via
couriers+listeners. The fact we support different transports (and in different ways) for
notifiers than for the "core" ESB is just wrong.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:22 a.m.
New subject: [JBoss JIRA] Commented: (JBESB-452) Refactor Notifiers
[ http://jira.jboss.com/jira/browse/JBESB-452?page=comments#action_12367436 ]
Daniel Bevenius commented on JBESB-452:
---------------------------------------
Progress update:
"Pulled up" the sendToAll method from NotifyQueues and NotifyTopics as most the
code was
duplicated in both classes.
Made sendToAll a template method that calls send on the specific
subclass (the code that was different in NotifyQueues and NotifyTopics.
sendToAll now throws JMSException is any of the send fail. This will still try to send to
all
configured queues/topics but will later throw a jms message with the error and stacktrace
of
all failed sends. Previously exceptions were simply being logged but no
NotificationException was
getting throws from sendNotfication().
Also added test for the methods in question (not added in both unit test as I it enough to
test one)
Commited revision: 12994
I'll go through and take a look at the other notifiers.
Refactor Notifiers
------------------
Key: JBESB-452
URL: http://jira.jboss.com/jira/browse/JBESB-452
Project: JBoss ESB
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Rosetta
Affects Versions: 4.0
Environment: any
Reporter: Kurt Stam
Assigned To: Daniel Bevenius
Priority: Critical
Fix For: 4.2
Time Spent: 4 hours
Remaining Estimate: 0 minutes
These comments are based on the JMS notifiers but will probably apply to the other
notifiers as well:
1. The notifiers should be more like listeners where you get one (or more instances).
Until they get recycled when there is a config change. Right now the JMS onces
connected and disconnect with every message, which causes stress on the JMS provider when
running in high load mode.
2. They should get their 'provider' configuration from the configuration, just
like the listeners. Right now you cannot connect to other JMS providers.
3. The notifiers should get hooked up to the same life cycle management as the listener
infrastructure.
In other words: They really should be 'inverse gateways', the model is broken and
there shouldn't be a distinction between notifying and sending a message via
couriers+listeners. The fact we support different transports (and in different ways) for
notifiers than for the "core" ESB is just wrong.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:07 p.m.
New subject: [JBoss JIRA] Commented: (JBESB-452) Refactor Notifiers
[ http://jira.jboss.com/jira/browse/JBESB-452?page=comments#action_12367483 ]
Mark Little commented on JBESB-452:
-----------------------------------
Sounds like excellent progress.
Refactor Notifiers
------------------
Key: JBESB-452
URL: http://jira.jboss.com/jira/browse/JBESB-452
Project: JBoss ESB
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Rosetta
Affects Versions: 4.0
Environment: any
Reporter: Kurt Stam
Assigned To: Daniel Bevenius
Priority: Critical
Fix For: 4.2
Time Spent: 4 hours
Remaining Estimate: 0 minutes
These comments are based on the JMS notifiers but will probably apply to the other
notifiers as well:
1. The notifiers should be more like listeners where you get one (or more instances).
Until they get recycled when there is a config change. Right now the JMS onces
connected and disconnect with every message, which causes stress on the JMS provider when
running in high load mode.
2. They should get their 'provider' configuration from the configuration, just
like the listeners. Right now you cannot connect to other JMS providers.
3. The notifiers should get hooked up to the same life cycle management as the listener
infrastructure.
In other words: They really should be 'inverse gateways', the model is broken and
there shouldn't be a distinction between notifying and sending a message via
couriers+listeners. The fact we support different transports (and in different ways) for
notifiers than for the "core" ESB is just wrong.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:17 a.m.
New subject: [JBoss JIRA] Commented: (JBESB-452) Refactor Notifiers
[ http://jira.jboss.com/jira/browse/JBESB-452?page=comments#action_12367510 ]
Daniel Bevenius commented on JBESB-452:
---------------------------------------
Additional work for JIRA: JBESB-452 "Refactor Notifiers":
NotifySqlTable SqlException is now being caught,logged and a
NotificationException is throw with the sql exception as cause
NotifySqlTableUnitTest Unit test for testing the exception handling
NotifyFilesTest methods stringNotification and objectNotification now
throw IOException. sendNotifcation catches IOException and
for every failure of notifying a file a error
message containing the filename and stacktrace is saved, and later
thrown with a NotifcationException.
NotifyFilesUnitTest Unit test for testing the exception handling
NotifyJMS Moved createException to NotifyUtil so the other
notification classes can use it.
NotifyTopicsUnitTest updated to reflect the move of createException mentioned
above.
Committed revision 13031.
NotifyConsole, NotfiyEmail,and NotifyFtp look ok to me in that they are catching and
rethrowing exceptions.
Refactor Notifiers
------------------
Key: JBESB-452
URL: http://jira.jboss.com/jira/browse/JBESB-452
Project: JBoss ESB
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Rosetta
Affects Versions: 4.0
Environment: any
Reporter: Kurt Stam
Assigned To: Daniel Bevenius
Priority: Critical
Fix For: 4.2
Time Spent: 4 hours
Remaining Estimate: 0 minutes
These comments are based on the JMS notifiers but will probably apply to the other
notifiers as well:
1. The notifiers should be more like listeners where you get one (or more instances).
Until they get recycled when there is a config change. Right now the JMS onces
connected and disconnect with every message, which causes stress on the JMS provider when
running in high load mode.
2. They should get their 'provider' configuration from the configuration, just
like the listeners. Right now you cannot connect to other JMS providers.
3. The notifiers should get hooked up to the same life cycle management as the listener
infrastructure.
In other words: They really should be 'inverse gateways', the model is broken and
there shouldn't be a distinction between notifying and sending a message via
couriers+listeners. The fact we support different transports (and in different ways) for
notifiers than for the "core" ESB is just wrong.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:49 a.m.
New subject: [JBoss JIRA] Work stopped: (JBESB-452) Refactor Notifiers
[ http://jira.jboss.com/jira/browse/JBESB-452?page=all ]
Work on JBESB-452 stopped by Daniel Bevenius.
Refactor Notifiers
------------------
Key: JBESB-452
URL: http://jira.jboss.com/jira/browse/JBESB-452
Project: JBoss ESB
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Rosetta
Affects Versions: 4.0
Environment: any
Reporter: Kurt Stam
Assigned To: Daniel Bevenius
Priority: Critical
Fix For: 4.2
Time Spent: 4 hours
Remaining Estimate: 0 minutes
These comments are based on the JMS notifiers but will probably apply to the other
notifiers as well:
1. The notifiers should be more like listeners where you get one (or more instances).
Until they get recycled when there is a config change. Right now the JMS onces
connected and disconnect with every message, which causes stress on the JMS provider when
running in high load mode.
2. They should get their 'provider' configuration from the configuration, just
like the listeners. Right now you cannot connect to other JMS providers.
3. The notifiers should get hooked up to the same life cycle management as the listener
infrastructure.
In other words: They really should be 'inverse gateways', the model is broken and
there shouldn't be a distinction between notifying and sending a message via
couriers+listeners. The fact we support different transports (and in different ways) for
notifiers than for the "core" ESB is just wrong.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:56 a.m.
New subject: [JBoss JIRA] Closed: (JBESB-452) Refactor Notifiers
[ http://jira.jboss.com/jira/browse/JBESB-452?page=all ]
Daniel Bevenius closed JBESB-452.
---------------------------------
Fix Version/s: 4.2 Milestone Release 3
(was: 4.2)
Resolution: Done
The hardening part of this task is done.
Refactor Notifiers
------------------
Key: JBESB-452
URL: http://jira.jboss.com/jira/browse/JBESB-452
Project: JBoss ESB
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Rosetta
Affects Versions: 4.0
Environment: any
Reporter: Kurt Stam
Assigned To: Daniel Bevenius
Priority: Critical
Fix For: 4.2 Milestone Release 3
Time Spent: 4 hours
Remaining Estimate: 0 minutes
These comments are based on the JMS notifiers but will probably apply to the other
notifiers as well:
1. The notifiers should be more like listeners where you get one (or more instances).
Until they get recycled when there is a config change. Right now the JMS onces
connected and disconnect with every message, which causes stress on the JMS provider when
running in high load mode.
2. They should get their 'provider' configuration from the configuration, just
like the listeners. Right now you cannot connect to other JMS providers.
3. The notifiers should get hooked up to the same life cycle management as the listener
infrastructure.
In other words: They really should be 'inverse gateways', the model is broken and
there shouldn't be a distinction between notifying and sending a message via
couriers+listeners. The fact we support different transports (and in different ways) for
notifiers than for the "core" ESB is just wrong.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6359
days inactive
6481
days old
12 comments
3 participants
participants (3)
-
Daniel Bevenius (JIRA) -
Kurt Stam (JIRA)
-
Mark Little (JIRA)