I think that is a version problem too. Newer version new problems xD.
Now, I've a Ubuntu 10.04 machine (64 bits) and I've tests. VenueClient works
fine, but, VenueServer works like Ubuntu 9.04 (problems uploading files) with a
new problem.
I'm developing shared applications for AG, and, I've created a "Shared Hello
World": A simple program with a text and button, and, when you click the button
some text appears.
Well, call a new shared Application on the VenueClient (Application
Sessions->Add X application) doen't refresh (like adding files). I have to
enter again to the venue for refresh. Then, when the Shared Application appears
(my "Shared Hello World"), the VenueServer doesn't take the events. I mean, I
click the button, I send a event to the venue for participants receive, but
when I send the event, the participants receive nothing.
Firstly, I thought that was a problem of my application (bad code), but, I've
executed the same application on Windows 7 and Ubuntu 9.04, and my "Shared
Hello World" works perfectly.
So, I think like Christoph, there is a version problem. Christoph, do you think
if the uploading files problem fix it, fix the event problem? I hope so xD.
Well, I'll try install older version of Ubuntu o another linux distribution
while the problem is fixing ^^.
Regards!!
PD: Sorry, a question about development on AG. How I can know if a participant
is the creator of the shared app? I mean, I would like to show a different
buttons on a window, for the participant that call the shared app (the
"creator") and the rest of participants that recieve the invitation of this
shared app. It could possible? Regards again and thanks!
El dia 29 abr 2010 04:40, Thomas Uram <tu...@mcs.anl.gov> escribió:
Fwiw, I've reproduced the problem on xubuntu 9.04 so will be able to
investigate the problem further. At this point, I'm suspecting that the client
fails to begin sending after initiating the transfer, but more investigation
will tell for sure.
Tom
On Apr 28, 2010, at 8:10 PM, Christoph Willing wrote:
Well my hunch is that the server side of this fault is a python version
issue - based on the following:
1. on a broken system, I've replaced all relevant application packages
with versions used on a working system. These replaced packages included zsi
(and therefore AG itself), m2crypto and openssl. The problem persists.
2. in all the different Linux versions I've been able to test, the broken
systems are all running python 2.6; all working systems are running 2.5 or
lower.
2b. I don't have any experience of AG on Windows (where there is
apparently no data upload problem) but from the download page it looks like
python 2.4 is being used.
3. while looking through some m2crypto documentation, I found an article
(http://www.heikkitoivonen.net/blog/2008/10/14/ssl-in-python-26/) which talks
about some level of SSL support having been introduced into python 2.6. My
guess is that this added functionality is somehow interfering with the way we
use m2crypto - maybe there's now a duplicated function name and the wrong one
is being executed ...
chris
On 28/04/2010, at 6:08 PM, Jesus Cea Oliva wrote:
Good morning list :). Here I attached the logs of VenueServer:
- Log_Ubuntu_Fail: Part of a VenueServer Loggin on a Ubuntu 9.10 (x64)
machine. Upload fails trying upload the file
"/home/ercea/Documentos/PFC/ag-guide.pdf"
- Log_Ubuntu_Success: Part of a VenueServer Loggin on a Ubuntu 9.10
(x64) machine. Upload success with file
/home/ercea/.AccessGrid3/local_services/AudioService/AudioService.py
- Log_WindowsXP_Sucess: Part of a VenueServer Loggin on a Windows XP
(x86) machine. Upload success with file "C:\Documents and
Settings\Administrator\Mis Documentos\Presentacion.zip"
I hope this logs helps to find the problem ;)
Regards!
El dia 28 abr 2010 02:08, Christoph Willing <c.will...@uq.edu.au>
escribió:
Sorry, the output of a _successful_ upload which I sent previously was
incomplete. Here's the complete transaction:
04/28/10 09:57:58 -1245000816 FTPSServer ftps_server.py:338 INFO
Connection from 130.102.78.192:53807
04/28/10 09:57:58 -1245000816 FTPSServer ftps_server.py:271 INFO ==>
220 vv3 M2Crypto (Medusa) FTP/TLS server v0.18 ready.
04/28/10 09:57:58 -1245000816 FTPSServer ftps_server.py:271 INFO <==
AUTH TLS
04/28/10 09:57:58 -1245000816 FTPSServer ftps_server.py:271 INFO ==>
234 AUTH TLS successful
04/28/10 09:57:58 -1245000816 FTPSServer ftps_server.py:271 INFO <==
PBSZ 0
04/28/10 09:57:58 -1245000816 FTPSServer ftps_server.py:271 INFO ==>
200 PBSZ=0 successful.
04/28/10 09:57:58 -1245000816 FTPSServer ftps_server.py:271 INFO <==
PROT P
04/28/10 09:57:58 -1245000816 FTPSServer ftps_server.py:271 INFO ==>
200 Protection set to Private
04/28/10 09:57:58 -1245000816 FTPSServer ftps_server.py:271 INFO <==
USER 0a0101d80c2020bf185599cb7beea8bb
04/28/10 09:57:58 -1245000816 FTPSServer ftps_server.py:271 INFO ==>
331 Password required.
04/28/10 09:57:58 -1245000816 FTPSServer ftps_server.py:271 INFO <==
PASS <password>
04/28/10 09:57:58 -1245000816 VenueServer VenueServer.py:432 INFO in
authorizeDataTransferCB <AccessGrid.FTPS.ftps_server.ftp_tls_channel connected
130.102.78.192:53807 at 0x907eb8c> 0a0101d80c2020bf18
5599cb7beea8bb 82664eb24cd2202bad54cf1e46bb0501
04/28/10 09:57:58 -1245000816 VenueServer VenueServer.py:458 INFO
authorizeDataTransferCB: user in venue, authorized Jaunty64 Test to transfer
files to venue Test Room
04/28/10 09:57:58 -1245000816 FTPSServer ftps_server.py:271 INFO ==>
230 Ok.
04/28/10 09:57:58 -1245000816 FTPSServer ftps_server.py:275 INFO
Successful login: Filesystem=<unix-style fs root:Data wd:/>
04/28/10 09:57:58 -1245000816 FTPSServer ftps_server.py:271 INFO <==
cwd /0a0101d80c2020bf185599cb7beea8bb
04/28/10 09:57:58 -1245000816 FTPSServer ftps_server.py:271 INFO ==>
250 CWD command successful.
04/28/10 09:57:58 -1245000816 FTPSServer ftps_server.py:271 INFO <==
TYPE I
04/28/10 09:57:58 -1245000816 FTPSServer ftps_server.py:271 INFO ==>
200 Type set to Binary.
04/28/10 09:57:58 -1245000816 FTPSServer ftps_server.py:271 INFO <==
PASV
04/28/10 09:57:58 -1245000816 FTPSServer ftps_server.py:271 INFO ==>
227 Entering Passive Mode (130,102,78,178,195,93)
04/28/10 09:57:58 -1245000816 FTPSServer ftps_server.py:271 INFO <==
stor killall.diff
04/28/10 09:57:58 -1245000816 FTPSServer ftps_server.py:271 INFO ==>
150 Opening Binary connection for killall.diff
04/28/10 09:57:58 -1245000816 FTPSServer ftps_server.py:271 INFO ==>
226 Transfer complete.
04/28/10 09:57:58 -1245000816 VenueServer VenueServer.py:468 DEBUG
dataActivityCB: command = RECV
04/28/10 09:57:58 -1245000816 VenueServer VenueServer.py:469 INFO
dataActivityCB: command = RECV
04/28/10 09:57:58 -1245000816 VenueServer VenueServer.py:470 INFO
dataActivityCB: line = Data/0a0101d80c2020bf185599cb7beea8bb/ killall.diff
04/28/10 09:57:58 -1245000816 VenueServer VenueServer.py:474 DEBUG
dataActivityCB: Pathpart is: Data
04/28/10 09:57:58 -1245000816 VenueServer VenueServer.py:474 DEBUG
dataActivityCB: Pathpart is: 0a0101d80c2020bf185599cb7beea8bb
04/28/10 09:57:58 -1245000816 VenueServer VenueServer.py:474 DEBUG
dataActivityCB: Pathpart is: killall.diff
04/28/10 09:57:58 -1245000816 VenueServer VenueServer.py:486 DEBUG
dataActivityCB: VenueID 0a0101d80c2020bf185599cb7beea8bb ; Filename:
killall.diff
04/28/10 09:57:58 -1245000816 VenueServer VenueServer.py:489 DEBUG
dataActivityCB: Venue is: 0a0101d80c2020bf6aaa4d18fcbbdee7
04/28/10 09:57:58 -1245000816 VenueServer VenueServer.py:489 DEBUG
dataActivityCB: Venue is: 0a0101d80c0620949d2e08d15558b0bc
04/28/10 09:57:58 -1245000816 VenueServer VenueServer.py:489 DEBUG
dataActivityCB: Venue is: 0a0101d80c0a209f1c9d810227f4cc4b
[snip] all venues are inspected but omitted here for brevity ...
04/28/10 09:57:59 -1245000816 VenueServer VenueServer.py:489 DEBUG
dataActivityCB: Venue is: 82664ec0087e59823554e75b6a03e049
04/28/10 09:57:59 -1245000816 VenueServer VenueServer.py:491 DEBUG
dataActivityCB: Key existing? 1
04/28/10 09:57:59 -1245000816 DataStore DataStore.py:796 DEBUG
GetDownLoadDescriptor: Pathname is Data/0a0101d80c2020bf185599cb7beea8bb
04/28/10 09:57:59 -1245000816 DataStore DataStore.py:797 DEBUG
GetDownLoadDescriptor: Filename is killall.diff
04/28/10 09:57:59 -1245000816 DataStore DataStore.py:801 DEBUG
GetDownLoadDescriptor: Joined Path is Data/
0a0101d80c2020bf185599cb7beea8bb/killall.diff
04/28/10 09:57:59 -1245000816 FTPSServer FTPSServer.py:104 DEBUG
Entered FTPSServer.GetDownloadDescriptor
04/28/10 09:57:59 -1245000816 FTPSServer FTPSServer.py:110 DEBUG
descriptor =
ftps://vv3.ap-accessgrid.org:8006/0a0101d80c2020bf185599cb7beea8bb/killall.diff
04/28/10 09:57:59 -1245000816 DataStore DataStore.py:934 DEBUG
AddFile: URL to download location is:
ftps://vv3.ap-accessgrid.org:8006/0a0101d80c2020bf185599cb7beea8bb/killall.diff
04/28/10 09:57:59 -1245000816 DataStore DataStore.py:935 DEBUG
AddFile: Path to FTP location of file is: Data/
0a0101d80c2020bf185599cb7beea8bb/killall.diff
04/28/10 09:57:59 -1245000816 DataStore DataStore.py:951 DEBUG
AddFile: Determined parentID is: -1
04/28/10 09:57:59 -1245000816 DataStore DataStore.py:961 DEBUG
AddFile: URI is
ftps://vv3.ap-accessgrid.org:8006/0a0101d80c2020bf185599cb7beea8bb/killall.diff
04/28/10 09:57:59 -1245000816 VenueServer Venue.py:1859 DEBUG
DataDescription value: DataDescription: {'status': 'present', 'description':
None, 'checksum': None, 'parentId': '-1', 'uri': 'ftps://vv3.ap
-accessgrid.org:8006/0a0101d80c2020bf185599cb7beea8bb/killall.diff',
'name': 'killall.diff', 'lastModified': 'Wed, Apr 28, 2010, 09:57:59', 'owner':
'', 'hierarchyLevel': -2, 'objectType': 'File', 'type': N
one, 'id': '82664eb24cd2202bb7f27e7e11f0e457', 'size': 428}
04/28/10 09:57:59 -1245000816 FTPSServer ftps_server.py:271 INFO <==
QUIT
04/28/10 09:57:59 -1245000816 FTPSServer ftps_server.py:271 INFO ==>
221 Goodbye.
On 28/04/2010, at 7:11 AM, Christoph Willing wrote:
On 28/04/2010, at 6:38 AM, Vine, Derek A wrote:
At least in my case, I connect to the venue locally from the venue
server, I can upload files like expected. Connecting from any other node will
not allow upload of files, at least not "live". Sometimes after you try to
upload a file and leave and come back the file is there.
Derek,
That looks like a network problem then, like when I was testing from
home and small file uploads were OK but large ones didn't seem to work - it was
just that big files took a lot longer to via the relatively slow ADSL upload
bandwidth.
All,
For comparison with previous log output, here's the server log output
of a successful upload:
[snip]
Christoph Willing +61 7 3365 8316
QCIF Access Grid Manager
University of Queensland
<Log_Ubuntu_Fail.log><Log_Ubuntu_Sucess.log><Log_WindowsXP_Success.log>
Christoph Willing +61 7 3365 8316
QCIF Access Grid Manager
University of Queensland
