#13 Conduitlist cleans after Quitting

[Torsten Kunkel]

Hi,

I think this is a bug of jsyncManager.
When starting the tool I can set up new conduits, after
shutting down and restarting it
the conduit is in the list, everythink is ok.
But when stopping jSyncManager with Strg-C in the
console the conduit-list is empty after restart.
I know quitting with strg-c isn't the fine way, but it
shouldn't clean the conduit-list I think.

This behavior is very disturbing when programming new
conduits.

Torsten

[David Bartmess]

Logged In: YES
user_id=290082

I'm assuming you mean Ctrl-C by strg-C? Aborting the program?

If so, this isn't so much of a bug as it is an enhancement
request, because we don't currently intercept aborts from
the console to be able to save the settings before it quits.

Personally, I'd rather not see a program save settings from
an aborted session, because it may overwrite good settings
with corrupted ones.

If you're doing development, that's one of the problems you
just have to deal with. If not, then the normal (i.e.,
somewhat standard)
way of dealing with this is as it is, just dump the settings
in the bitbucket and return to the previous settings. If the
previous settings are erased also, then this is a problem,
but I haven't been able to reproduce that sequence of events.

I'm marking this as closed because it could be a bad idea to
save possibly bad data as the settings for a future session.

[David Bartmess]

Logged In: YES
user_id=290082

With clarification from user below, this should not happen
if the jsyncmanager has already saved settings. Settings
should be maintained from session to session, and if the
session is aborted, the previous settings should be in
effect upon re-opening jsyncmanager.

Two examples:

a) opening JSynchmanager
adding a new conduit
conduit crashes (oder str-c is pressed)
after restarting jsyncmanager, this conduit isn't in the list

=> correct, jsynchmanager must not write the configurationfile

b) opening JSynchmanager
adding a new conduit
closing jsynchmanager

=> conduit is saved in the configurationfile

restarting jsynchmanager
conduit is still in the list
resynch stats
conduit crashes (oder str-c is pressed)
after restarting jsyncmanager, this conduit isn't in the list

=> correct?!

I think this is the bug, becaus in this case jsynchmanager
HAS rewritten the configurationfile

[Brad BARCLAY]

Logged In: YES
user_id=451396

Just as an addendum to the original problem, if you're doing
development and testing, you may want to think of scripting
the startup to do a few things:

- Clean out the old jSyncManager settings in .jsyncmanager
- Run the jSyncManager with the --inst-conduits option and a
list of your jConduit classes to install them
- Run the jSyncManager

This is a good way of doing jConduit testing during
development, as it ensures that problematic settings (or
settings from old versions) aren't being stored, and that
the jConduits you want to test are always setup (the whole
purpose of --inst-conduits is to allow installers and
scripts to do just this).

One thing to note is that if you're changing your jConduit
between invocations, it may not appear to be installed after
restart as its serialization ID may have changed. If this
ocurs, the jSyncManager will get an exception form the
Vector during deserialization, causing all jConduits to be
lost (a problem we need to work on). In order to prevent
this, you should setup a private static final long called
serialVersionUID, with a fixed numerical value. In this way
you can ensure that your serialization ID doesn't change
after a recompile if you add new methods and/or transient
fields (although you probably _should_ change it if you add
new non-transient fields, as this changes the way the data
is serialized/deserialized).

I hope this helps!

Brad BARCLAY