Ticket #6483 (closed defect: fixed)

Opened 7 years ago

Last modified 6 years ago

Sharing doesn't work in Read Activity

Reported by: wad Owned by: mstone
Priority: blocker Milestone:
Component: telepathy-salut Version:
Keywords: read sharing release? Cc: tomeu, marco, jg, Collabora, cjb, walter
Action Needed: Verified: no
Deployments affected: Blocked By:
Blocking:

Description

On builds 656, 691 and 693, on production laptops (but with suspend inhibited), sharing of documents using the Read activity doesn't work.

This has been verified to fail in both the simple mesh and AP network modes, using both invites and joins as the method of sharing.

Documents downloaded to the laptop as well as documents on a USB stick were tested. All failed.

The method of failure is that the invitation (or shared document) appears fine on the other laptops. When selected, the Read activity is launched OK, but it never receives the document being shared. It just sits there with a blank screen.

Attachments

salut-stream-tube-fix.patch (14.3 kB) - added by gdesmott 7 years ago.
logs.SHF725003A0.2008-03-19.23-56-27.tar.bz2 (41.8 kB) - added by mstone 6 years ago.
logs from a failed join attempt
logs.SHF72500057.2008-03-19.23-00-12.tar.bz2 (80.2 kB) - added by mstone 6 years ago.
logs from a successful join attempt

Change History

  Changed 7 years ago by rwh

  • cc morgs, tomeu, marco, sjoerd added

Ouch! I tested here on Salut back-end (either I can't get Gabble to work or olpc.collabora.co.uk is not functioning). I think there are two issues: the first is that the timeout for the (local) Activity.Join call is a bit short (anybody an idea what the default is?), and two: the stream tubes seem to have trouble transferring the whole file. I'm not sure where the problem is exactly, but the GlibURLDownloader always used to work. It checks whether the data blocks are the expected size (4096). I changed the code to just check whether there is data at all, and this is the result:

1203291580.779578 DEBUG read-activity: Downloaded 4096 bytes from tube 514189109...
1203291580.792029 DEBUG read-activity: Downloaded 8192 bytes from tube 514189109...
1203291580.795031 DEBUG read-activity: Downloaded 12288 bytes from tube 514189109...
1203291580.796583 DEBUG read-activity: Downloaded 12377 bytes from tube 514189109...
1203291580.798068 DEBUG read-activity: Downloaded 12377 bytes from tube 514189109...
1203291580.799587 DEBUG read-activity: Got document /tmp/1203291580 (1203291580) from tube 514189109

No more data seems to be coming, although the 'server' instance definitely writes the whole file.

Any ideas?

  Changed 7 years ago by rwh

  • cc smcv, jg added

Could anybody from collabora (or other presence developers) comment?

  Changed 7 years ago by morgs

  • cc Collabora added; morgs, sjoerd, smcv removed

  Changed 7 years ago by gdesmott

  • owner changed from rwh to Collabora
  • component changed from read-activity to telepathy-salut

This is a Salut bug. We don't flush the transport buffer when we disconnect it so we lose its data.

I'm working on a fix.

  Changed 7 years ago by gdesmott

Fixed in upstream.

Changed 7 years ago by gdesmott

  Changed 7 years ago by morgs

  • blocking 1 removed

telepathy-salut-0.2.2-2.olpc2 built in koji for joyride, with this patch included.

  Changed 7 years ago by morgs

Make that telepathy-salut-0.2.2-3.olpc2 actually :(

  Changed 7 years ago by gdesmott

As said previously they are at least 2 issues here. Let's focus on the stream tube problem in Salut, I'll open a new ticket about the other one.

Problem was Salut loosing data because it doesn't flush transport buffer. That should be fixed with the attached patch and in telepathy-salut-0.2.2-3.olpc2. I think we should consider to ship it for Update.1.

  Changed 7 years ago by gdesmott

See #6537 for the suspend issue.

  Changed 7 years ago by morgs

Joyride-1721 has telepathy-salut-0.2.2-3.olpc2

  Changed 6 years ago by walter

FYI, sharing still doesn't work on 699 with a simple mesh under a very light network load. The other activities I tried--Write and Distance--shared fine.

  Changed 6 years ago by wad

I just checked and I was able to share a PDF from one laptop to two other pretty well over a simple mesh. When I tried to share it to 8 other laptops, things broke down.

Laptops would start the application, but would never show any content. Quitting and re-joining the shared activity would sometimes work.

Build 699, Read-44, simple mesh, no other RF traffic on channel 1.

When things started falling apart, all of the laptops could no longer "see" one another in the neighborhood views.

This could be the multicast limited to single hop affecting us (it is definitely present in the packet traces). I will try to retest enabling multihop.

  Changed 6 years ago by wad

This definitely gets worse with multihop mesh re-enabled.

  Changed 6 years ago by gdesmott

Could be related to #6537. Can you try to disable read suspend (touch /etc/inhibit-ebook-sleep) please?

  Changed 6 years ago by cjb

  • cc cjb added

Could be related to #6537. Can you try to disable read suspend (touch /etc/inhibit-ebook-sleep) please?

Build 699 already has /etc/inhibit-ebook-sleep written, so I don't suspect that's it.

Wad, you might try seeing whether telepathy-salut is still running in the failing state -- perhaps this is another telepathy-salut crasher.

  Changed 6 years ago by mstone

  • owner changed from Collabora to mstone

  Changed 6 years ago by gdesmott

We'll need Read and Salut log: http://wiki.laptop.org/go/Telepathy-debug

Does it work fine with Gabble when trying the same use case?

  Changed 6 years ago by cjb

Michael and I caught an error with Read and Salut logging turned on last night. It'll be up here soonish.

Changed 6 years ago by mstone

logs from a failed join attempt

Changed 6 years ago by mstone

logs from a successful join attempt

  Changed 6 years ago by mstone

See http://lists.laptop.org/pipermail/devel/2008-March/011943.html for are more detailed description of the measurements that generated these logs.

  Changed 6 years ago by mstone

  • cc walter added

Walter and I briefly discussed the state of our knowledge about these failures and we reached the tentative conclusion that we should advise clients (particularly Peru) not to rely on Read-sharing as their primary mechanism for distributing etexts to children.

  Changed 6 years ago by walter

To expand upon Michael's post, presuming we have robust Journal-to-USB-to-Journal sharing, we have a fall-back position, hence I would assert we change this from blocker to high priority. That said, we should consider removing the share menu from read a la

toolbar = toolbox.get_activity_toolbar()

toolbar.share.hide()

so as to not give the impression that sharing works when it doesn't

  Changed 6 years ago by Blaketh

  • keywords release? added

in reply to: ↑ description   Changed 6 years ago by hhardy

Replying to wad:

I noted a similar behaviour at the OLPC Boston gathering last night. Sharing between my 702 build and their (probably) 656 builds failed when trying to use the measure activity. You could see the doc and try to share but the button for measure never un-greyed-out. Simple mesh, was also connected to COSI wifi. Same behaviour whether they or I initiated the activity. They could measure amongst themselves ok.

On builds 656, 691 and 693, on production laptops (but with suspend inhibited), sharing of documents using the Read activity doesn't work. This has been verified to fail in both the simple mesh and AP network modes, using both invites and joins as the method of sharing. Documents downloaded to the laptop as well as documents on a USB stick were tested. All failed. The method of failure is that the invitation (or shared document) appears fine on the other laptops. When selected, the Read activity is launched OK, but it never receives the document being shared. It just sits there with a blank screen.

  Changed 6 years ago by bemasc

The situation has actually gotten worse. In Update.1-702, when A shares an instance of Read, B sees A's XO jump in the mesh view, but no Read icon appears. Therefore, in this build Read can only be shared by invitations.

Document transfer does work, under ideal conditions (mesh with 2 XO's, no suspend). This has been the case for some time. Document transfer only fails on denser meshes, or when Read suspends and breaks the transfer.

  Changed 6 years ago by bemasc

Heisenbug! After a reboot, the exact same sequence works correctly, with the icon for A's Read session appearing as expected in B's mesh view, and the PDF file transferred as desired.

  Changed 6 years ago by gdesmott

Salut log from logs.SHF72500057.2008-03-19.23-00-12.tar.bz2 doesn't have the "---Finished joining phase!!!!---" so that could be the same bug as #6739. As for this bug, a tcpdump could be useful.

  Changed 6 years ago by gdesmott

  • status changed from new to closed
  • resolution set to fixed

Closing this bug as the original stream tubes bug was fixed and #6739 is already open about the joining problems.

  Changed 6 years ago by gregorio

  • milestone deleted

Milestone Never Assigned deleted

Note: See TracTickets for help on using tickets.