Bugzilla – Full Text Bug Listing
| Summary: | Incomplete file transfer from remote to local system | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Michael Spivak-Baranov <Michael.Spivak.Baranov> | ||||
| Component: | TPTP | Assignee: | Igor Alelekov <igor.alelekov> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P1 | CC: | igor.alelekov, karla.callaghan, kevin.p.o'leary, samwai | ||||
| Version: | unspecified | Keywords: | plan | ||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | closed460 | ||||||
| Attachments: |
|
||||||
|
Description
Michael Spivak-Baranov
Created attachment 55385 [details]
the patch fixes incorrect calculation of record boundary
Under some conditions last chunk of data isn't transfered
due to incorrect calculation of record boundary.
The suggested patch fixes this calculation.
Making Igor owner. Adding Samson to CC as this patch is in a lib shared with the RAC. Samson, please review and commit. Hi Igor. Can you describe why the file transfer is related to the shared memory code? Samson, File transfer agent uses shared memory to send/receve files. And under some conditions last data block isn't sent to AC and file transfer hangs. Hi Igor. So this is not related to the java-based file server in the backward compatibility layer? Since I think the java-based one does not use shared memory at all. (In reply to comment #5) > Hi Igor. So this is not related to the java-based file server in the backward > compatibility layer? Since I think the java-based one does not use shared > memory at all. Yes, It is not related to the java-based file server in the backward compatibility layer. It is related with data channels via shared memory in new AC. Hi Igor. I want to understand a bit further. This same piece of code has been used for many years for processing profiling data and we have not seen any bug reported. Is it true that the problem can only be uncovered when the record length perfectly alignes with the buffer (in the case it meets the ">=" condition") and it somehow mess up the calculation thereafter? Maybe it is just my stupid concern but I just don't want this fix to cause any regression :-) Hi Samson. If we got a whole record it should be flushed. However currently, if data length exactly equals buffer length, data are held off as in the case of incompleted record. It is not such important in profiling since in data flow next data block will push deferred one. In file transfer if last data block is held, transfer hangs. I've tested the patch on various platforms with pi and ti agents. No regression was found. Thanks Igor for explaining the fix. I am OK with the fix and will commit to 4.4 shortly. BTW I can see that there are 3 different places in the code which have the same ">=" check. Should I also update them as well? It seems that data could be defered in the first place only (in dataToFuncProcessor()). I don't see a problem with the other places. Fix reviewed and committed into CVS head stream at 2007/03/07 15:27 EST. Igor, please mark the bug as resolved. Thanks. Marked as resolved, thanks :) As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open. |