[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[ecf-dev] Re: eclipsefiletransfer

Hi Gerhard,

OK, I've finally had a chance to reproduced this bug and figure out what was going wrong.

There was a bug in the org.eclipse.ecf.example.collab.share.io.FileTransferSharedObject class. This bug was kind of subtle. What was happening was that when the user initiates a file send, an instance of EclipseFileTransfer was created/added to the container. EclipseFileTransfer extends FileTransferSharedObject, which extends TransactionSharedObject.

As part of the activation of FileTransferSharedObject (i.e. in the TransactionSharedObject.activate() method) the method TransactionSharedObject.addRemoteParticipants() method is called. This method is responsible for adding to the TransactionSharedObject.participantIDs the current group participants...i.e. on line 76 of TransactionSharedObject is this:


This adds *all* the group members to the list of transaction participants (those that are expected to respond before the sender considers the transaction committed). But note that for the case when the user is sending the file to just a *single* recipient (i.e. via drag and drop to an entry in the buddy list), that the other participants (i.e. the second slave) should *not* be added to this list of transaction participants...because the sender will wait until it gets a response of some kind from all participants. This is what was causing your transfers to timeout when three participants were included...the master/sender was waiting for a response from the recipient that wasn't ever intended to receive the file...and it would eventually just timeout and fail.

So, the fix for this is to override the addRemoteParticipants() method in FileTransferSharedObject and define it like this:

In FileTransferSharedObject

protected void addRemoteParticipants(ID ids[])
if (ids != null && participantIDs != null) {
for(int i=0; i < ids.length; i++) {
if (targetReceiver == null) {
if (!getHomeContainerID().equals(ids[i])) participantIDs.addElement(ids[i]);
} else {
if (targetReceiver.equals(ids[i])) participantIDs.addElement(ids[i]);


What this does is check to see if the *targetReceiver* is null. If it is null (which means 'send to everyone in group') it adds the participant to the participantIDs list and the sender waits for all receivers to respond before continuing with file transfer. If the targetReceiver is *not* null (which means the file is intended to be sent to a *specific* single recipient), then the ids[i] entry is only added if it matches the targetReceiver ID. The participantIDs list then only includes the targetReceiver, and so the sender just sends to that one receiver and doesn't incorrectly wait (in vain) for the others to respond.

I've checked these changes in. Unfortunately they didn't get into yesterday's 0.4.0 distribution so you will have to pick them up from CVS. We will be doing another build (0.4.1) within two weeks, and these changes will be in there.

NB: My intention is to soon define/create a 'file transfer' API plugin for ECF and rewrite/refactor *all* of this file transfer code that's in the org.eclipse.ecf.example.collab project. So all this is going away shortly to be replaced with 1) an API plugin for file transfer using ECF containers, and 2) some implementations that provide some of the same basic services but use the Eclipse extension point mechanisms and ECF extensibility API (i.e. IContainer.getAdapter()) to provider runtime access to the file transfer capabilities...hiding the specific implementation classes (like EclipseFileTransfer, FileTransferSharedObject, etc). Please let me know if you would like to help out with this...as perhaps some of the work you are doing on your system could inform this work...or you could even make a code contribution, etc and work with me/us to get this file transfer API defined and implemented within ECF.

Thanks for reporting the problems and being patient.  It's appreciated.


Gerhard Maier wrote:

Hi Scott,

my application:
1. create master

2. create slave client
3. master detects connectionevent from slave (ID)
3.1 create eclipsefiletransfer to send (only to ID; [targetID])

4. create slave2
.. (like 2+3)

in my application, which is heavily based on the collab example, on first connect a eclipsefiletransfer is created an may be done, when the second slave comes into play. But this is not depending on the sequence.

collab example: 1. variant (one application) - connect 3 clients via 3 projects - drop a file on one client in a buddy list to make transfer

2. variant (3 applications)
- each connecting to localhost via one project
- drop a file on one client in a buddy list to make transfer

here no eclipsefiletransfer exists 'til i drop a file in the buddy list and the problem is the same. I mean, i'm immediatlly getting the exception after the timeout, when i have 3 clients.

br gerhard

Scott Lewis wrote:

Hi Gerhard,

Gerhard Maier wrote:

hi Scott,

long time no 'hear'.

I've encountered a problem with the filetransfer.

I have a master client and 'slave' clients. If a the master detects a new slave client it tries to upload some required files.

Now the problem. It works just fine if i only have a single slave client connected. Do i connect another one, then i get on sender-side a 'TransactionSharedObject.waitToCommit' exception.

A question: *when* is this second slave client connected? So I understand...is the sequence:

1. Connect master client
2.  Connect slave client
3.  Create file transfer shared object
4.  Connect second slave client

or some other sequence? I think you've found a bug in the handling of these objects once an initial file transfer is complete. But I want to know the sequence here to make sure I understand what's going on.

org.eclipse.ecf.core.SharedObjectAddException: Container GUID[J4oTLqXy57B3EjZ8neDdwe5QE74-] had exception adding shared object StringID[-2855529713526529108]: org.eclipse.ecf.core.SharedObjectAddAbortException: Timeout waiting for create responses
at de.netallied.jviz.net.share.TransactionSharedObject.waitToCommit(TransactionSharedObject.java:184)

at org.eclipse.ecf.provider.generic.SOContainer.addSharedObjectAndWait(SOContainer.java:315)

at org.eclipse.ecf.provider.generic.SOManager.addSharedObject(SOManager.java:200)

at de.netallied.jviz.net.share.GenericSharedObject.makeObject(GenericSharedObject.java:492)


The curios thing is, i'm getting no exception or error message in the debug(..) methods on client side.

Is there a connection limit or something? (i don't think so, but who knows; i ask nevertheless)

No...but I think the master client is failing to send a request to create a shared object replica on the remote slave because it thinks it's job is done (incorrectly).

So please let me know about these sequence question and we'll debug. I suspect this will be easily fixed.



I've also tested it with the example/collab (checked out at 05.08.) and there it is the same. Connecting to 3 clients over resources (or making 3 eclipse applications) and try to send file to a specific client (i.e. by dropping a file on one member in the buddy list).

I also checked out current head of ecf from cvs and tested it with the collab example. Result is the same as above.

In specific:

1. receiver (FileTransferSharedObject):
- makes the output file (activated())
- calls super.activated() (TransactionSharedObject) in order to send the response and there seams nothing unusual here while debugging (0.3.3).

2. sender :
the sender seams not get a response while waiting to commit.

The created file is empty because no transfer takes place.

best regards