⇤ ← Revision 1 as of 2009-09-03 14:03:14
2025
Comment:
|
2048
|
Deletions are marked like this. | Additions are marked like this. |
Line 9: | Line 9: |
Line 12: | Line 11: |
{{{ | {{{ |
Line 16: | Line 15: |
{{{ | {{{ |
Line 21: | Line 21: |
Line 28: | Line 27: |
|| 197 || This is unneccessary synchronization || Cosmetic || NOTOK || | || 197 || This is unneccessary synchronization || Cosmetic || OK || |
Line 31: | Line 30: |
|| General || Sanity test by killing and starting JMS connection in TEST system || Minor || NOTOK || || 62 || I've noticed some variety in how the Log is created in NetarchiveSuite. We currently use besides getLog(TheNameOfTheClass.class) also getLog(getClass()), and getLog(getClass().getName(), and getLog(TheNameOfTheclass.class.getName()). This should probably be standardized. || Cosmetic || NOTOK || || 87 || It may be possible to use just one session, and then simplify code further || Cosmetic || NOTOK || || 240 || Consider deprecating reply, and using only specialised reply messages. Post an FR on this || Minor || NOTOK || || 624-625 || Shouldn't the log message be after the call to onException(e)? This is seen in other methods as well. || Cosmetic || NOTOK || |
|| General || Sanity test by killing and starting JMS connection in TEST system || Minor || (OK)Done locally not to disturb TEST system || || 62 || I've noticed some variety in how the Log is created in NetarchiveSuite. We currently use besides getLog(TheNameOfTheClass.class) also getLog(getClass()), and getLog(getClass().getName(), and getLog(TheNameOfTheclass.class.getName()). This should probably be standardized. || Cosmetic ||POSTPONED || || 87 || It may be possible to use just one session, and then simplify code further || Cosmetic || OK || || 240 || Consider deprecating reply, and using only specialised reply messages. Post an FR on this || Minor || OK || || 624-625 || Shouldn't the log message be after the call to onException(e)? This is seen in other methods as well. || Cosmetic || OK || |
Line 38: | Line 38: |
|| 62-63 || Add that filesFailed may be null || Cosmetic || NOTOK || | || 62-63 || Add that filesFailed may be null || Cosmetic || OK || |
Review (NS-83): Bug 555: JMS Connection reconnect
Author |
Kåre |
Moderator |
Kåre |
State |
Closed |
Objectives
Code updated to do exception handling on all JMSExceptions where it seems reasonable. Also: Much better synchronization when reconnecting.
Summary
KFC follows up
Total Time Used (Coding,Documentation,Review):
Time used: KFC: 2md SVC: 1md
General comments:
Description |
Classification |
Status |
Comments on file 'trunk/src/dk/netarkivet/common/distribute/JMSConnectionSunMQ.java', revision 964
Lines |
Description |
Classification |
Status |
197 |
This is unneccessary synchronization |
Cosmetic |
OK |
Comments on file 'trunk/src/dk/netarkivet/common/distribute/JMSConnection.java', revision 963
Lines |
Description |
Classification |
Status |
|| General || Sanity test by killing and starting JMS connection in TEST system || Minor || (OK)Done locally not to disturb TEST system ||
62 |
I've noticed some variety in how the Log is created in NetarchiveSuite. We currently use besides getLog(TheNameOfTheClass.class) also getLog(getClass()), and getLog(getClass().getName(), and getLog(TheNameOfTheclass.class.getName()). This should probably be standardized. |
Cosmetic |
POSTPONED |
87 |
It may be possible to use just one session, and then simplify code further |
Cosmetic |
OK |
240 |
Consider deprecating reply, and using only specialised reply messages. Post an FR on this |
Minor |
OK |
624-625 |
Shouldn't the log message be after the call to onException(e)? This is seen in other methods as well. |
Cosmetic |
OK |
Comments on file 'trunk/src/dk/netarkivet/archive/bitarchive/distribute/BatchReplyMessage.java', revision 963
Lines |
Description |
Classification |
Status |
62-63 |
Add that filesFailed may be null |
Cosmetic |
OK |