I've detected different behavior between Version 0.2.1 and 0.2.3, using edrive as a Service in Windows 7:
When windows starts up, edrive-service starts before ethernet-connection (internet) is there. So edrive (version 0.2.1) gives an Error an retries setting up the connection in 5minutes: ERROR EDrive - Failed to create ESync [<name>]. If your connection is correct but the Repository is currently unavailable, EDrive will try to re-connect in 5 minutes.
In Version 0.2.3 edrive gives a different Error: ERROR EDrive - This is a newly defined Synchroniser [<name>] that probably has typos in the URL, Paths or userName password. Please recheck all the values you entered.
IMHO Version 0.2.1 reacts correctly by retrying after 5min: Not later than 5min, syncing works fine.
Version 0.2.3 does not retrying, so after a reboot (after ethernet is hooked up) I have to stop/start the service for starting sync.
Test-Environement:
- Server: Alfresco 4.2.c
- Client: Windows 7, Installed Service with Apache Commons Deamon
Regards
Last edit: javamixer 2013-04-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The new functionality is actually the more correct functionality.
The way it works is as follows.
If eDrive detects a serialised file for any of your synchronisers, it makes the assumption that the synchroniser has at some point been working. This does mean that eDrive will have needed to have been shutdown correctly at some stage for the serialised files to get created. Based on this assumption, it will re-queue the failed Synchroniser for retry in X seconds (defaults to 300) and continue to do so in the belief that either the Repository or File System is unavailable at the moment.
If eDrive does not find a serialised file, it assumes that the synchroniser has never previously run and the failure is due to an incorrect URL or File System / Repository path error or typo. This stops eDrive from unnecesarrily retrying in the case it could not possibly work.
To get a serialised file for each Synchroniser, eDrive does have to be shut down correctly, as the shutdownhook takes care of shutting down eDrive and all of it's managed Synchronisers nicely. You can use the shutdown command from the command server to generate the serialised files, or run eDrive directly in a console and then press ctl-c.
The serialised files also enable subsequent eDrive startups to start up much quicker and not place the initial load on your system that a first time startup will. The reason for this is that the serialised files contain the state of the last know snapshots from where it can continue (thats why it's important to shut down correctly).
The names of the serialised files match the concatenated paths to the sync root of the Repository and File System then sha-256'd to produce a unique file name in readable hex digits. If you CHANGE EITHER path for a Synchroniser, eDrive will no longer match this file and will consider the affected Synchroniser to be new and never run before.
However, given your use case i.e. where the actual ethernet connection is not yet available, and you don't have a serialised file, the previous functionaly was better. Can you try shutting down eDrive correctly and then check you get back your previous behaviour? The serialised files will be in the same directory from where you started eDrive.
I will however take a look at this and possibly treat this scenario in a slightly different way by queueing once, this should allow enough time for the network to come up.
Everything has it's pro's and con's, it's just a matter of trying to get the right balance.
Regards
Steve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi
I've detected different behavior between Version 0.2.1 and 0.2.3, using edrive as a Service in Windows 7:
When windows starts up, edrive-service starts before ethernet-connection (internet) is there. So edrive (version 0.2.1) gives an Error an retries setting up the connection in 5minutes: ERROR EDrive - Failed to create ESync [<name>]. If your connection is correct but the Repository is currently unavailable, EDrive will try to re-connect in 5 minutes.
In Version 0.2.3 edrive gives a different Error: ERROR EDrive - This is a newly defined Synchroniser [<name>] that probably has typos in the URL, Paths or userName password. Please recheck all the values you entered.
IMHO Version 0.2.1 reacts correctly by retrying after 5min: Not later than 5min, syncing works fine.
Version 0.2.3 does not retrying, so after a reboot (after ethernet is hooked up) I have to stop/start the service for starting sync.
Test-Environement:
- Server: Alfresco 4.2.c
- Client: Windows 7, Installed Service with Apache Commons Deamon
Regards
Last edit: javamixer 2013-04-29
Hi javamixer
The new functionality is actually the more correct functionality.
The way it works is as follows.
If eDrive detects a serialised file for any of your synchronisers, it makes the assumption that the synchroniser has at some point been working. This does mean that eDrive will have needed to have been shutdown correctly at some stage for the serialised files to get created. Based on this assumption, it will re-queue the failed Synchroniser for retry in X seconds (defaults to 300) and continue to do so in the belief that either the Repository or File System is unavailable at the moment.
If eDrive does not find a serialised file, it assumes that the synchroniser has never previously run and the failure is due to an incorrect URL or File System / Repository path error or typo. This stops eDrive from unnecesarrily retrying in the case it could not possibly work.
To get a serialised file for each Synchroniser, eDrive does have to be shut down correctly, as the shutdownhook takes care of shutting down eDrive and all of it's managed Synchronisers nicely. You can use the shutdown command from the command server to generate the serialised files, or run eDrive directly in a console and then press ctl-c.
The serialised files also enable subsequent eDrive startups to start up much quicker and not place the initial load on your system that a first time startup will. The reason for this is that the serialised files contain the state of the last know snapshots from where it can continue (thats why it's important to shut down correctly).
The names of the serialised files match the concatenated paths to the sync root of the Repository and File System then sha-256'd to produce a unique file name in readable hex digits. If you CHANGE EITHER path for a Synchroniser, eDrive will no longer match this file and will consider the affected Synchroniser to be new and never run before.
However, given your use case i.e. where the actual ethernet connection is not yet available, and you don't have a serialised file, the previous functionaly was better. Can you try shutting down eDrive correctly and then check you get back your previous behaviour? The serialised files will be in the same directory from where you started eDrive.
I will however take a look at this and possibly treat this scenario in a slightly different way by queueing once, this should allow enough time for the network to come up.
Everything has it's pro's and con's, it's just a matter of trying to get the right balance.
Regards
Steve