Open jguillaumes opened 4 years ago
This is interesting, if z/OS is reporting an HTTP 500 then the CLI should fail with an error (which is what normally occurs in this scenario). We will try to reproduce.
Hi everyone,
I have the same problem, I am trying to download a file, the command responds satisfactorily however in the destination the file is cut and ends with: Error 500: java.io.IOException: Error response could not be sent to client. See log for details.
I forgot to mention.....we've .... zowe --version (2.30.0), Is there any solution?.
Hi,
Sorry for the insistence, but there is some solution for this issue?. We are doing a PoC and we would need to download a large file.
Regards
To confirm that the issue still exists, please upgrade to the newest version of the lts-incremental distribution of Zowe CLI (version 2.36.1).
If the issue still persists there, please try the active development version of Zowe CLI (version 6.6.3). This version should have improved support for downloading large files.
Thank you.
Hi:
I installed the last one that Zowe CLI found from a local zowe-cli-package-1.7.1 package. npm --version 6.13.4 zowe --version 2.32.1
The same problem: The command responds satisfactorily however in the destination the file is cut and ends with: Error 500: java.io.IOException: The error response could not be sent to the client. See record for more details.
Hi,
I just tried with zowe-cli-package-2.x-ACTIVE-DEVELOPMENT \npm>zowe --version 6.0.1
.... And the problem continues.
Hi,
Sorry, again.
As we said, we are doing a PoCO and would need to download a large file. Will it be fixed soon?
Thanks and sorry for the insistence.
Regards
Another thing, do you know from what size it fails?.
Thanks.
Hi @George0013,
Could you please provide the following details? I will try to replicate it. File size: binary / text: origin (USS / Data Set):
Thanks
Hi,
Of course,
Data Set Name . . . . : SYST.TEMP.WLMXGB
Allocated tracks . : 4,345
Allocated extents . : 3
Device type . . . . : 3390
Organization . . . : PS Current Utilization
Record format . . . : FB Used tracks . . . . : 4,345
Record length . . . : 100 Used extents . . . : 3
Block size . . . . : 27900
1st extent tracks . : 22
Secondary tracks . : 15000
Data set name type : LARGE
SMS Compressible . : NO
D:\APPSYS\ZOWE\npm>zowe zos-files --zosmf-profile CTA1POCZOWE dl ds "SYST.TEMP.WLMXGB" Data set downloaded successfully. Destination: syst/temp/wlmxgb.txt
As you see, the origin is Data set and the file size is about 250MB.
Regards
Hi,
Additionally, I have seen in the mainframe side the following error: ÝERROR ~ SRVE0777E: Exception thrown by application class 'com.ibm.zoszmf.restfiles.TsoServletProxy.sendErrorResponse:394' java.io.IOException: Error response could not be sent to client. See log for details.at com.ibm.zoszmf.restfiles.TsoServletProxy.sendErrorResponse(TsoServletProxy..java:394) at com.ibm.zoszmf.restfiles.TsoServletProxy.service(TsoServletProxy.java:165) at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
And the task cancels: IZUFPROC IZUFPROC - ABEND=S222 U0000 REASON=00000000 637
Tt does not seem to depend on the size because in several downloads of exactly the same file cuts at different points and even sometimes it finishs correctly.
Regards
Hi @George0013
I don't have any conclusive findings yet regarding your specific error, but I wanted to update you on my testing progress:
data set used:
Allocated tracks . : 19,400 Allocated extents . : 16 Device type . . . . : 3390 Data class . . . . . : USER Organization . . . : PS Record format . . . : FB Used tracks . . . . : 19,400 Record length . . . : 100 Used extents . . . : 16 Block size . . . . : 27900 1st extent tracks . : 4400 Secondary tracks . : 1000 Data set name type : LARGE SMS Compressible . : NO
In Windows this translates to about 250mb text file.
download failed:
JavaScript heap out of memory
[8336:0000022EA3260D30] 956803 ms: Mark-sweep 1238.3 (1245.5) -> 1238.3 (1244.5) MB, 165.9 / 0.0 ms (average mu = 0.533, current mu = 0.000) last resort GC in old space requested [8336:0000022EA3260D30] 956987 ms: Mark-sweep 1238.3 (1244.5) -> 1238.3 (1244.5) MB, 184.1 / 0.0 ms (average mu = 0.322, current mu = 0.000) last resort GC in old space requested
<--- JS stacktrace --->
==== JS stack trace =========================================
0: ExitFrame [pc: 000001911535C5C1]
1: StubFrame [pc: 000001911534E17D]
Security context: 0x036cb349e6e9
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory 1: 00007FF7D345DD8A v8::internal::GCIdleTimeHandler::GCIdleTimeHandler+4506 2: 00007FF7D3438886 node::MakeCallback+4534 3: 00007FF7D3439200 node_module_register+2032 4: 00007FF7D37530DE v8::internal::FatalProcessOutOfMemory+846 5: 00007FF7D375300F v8::internal::FatalProcessOutOfMemory+639 6: 00007FF7D3939804 v8::internal::Heap::MaxHeapGrowingFactor+9620 7: 00007FF7D3937CCB v8::internal::Heap::MaxHeapGrowingFactor+2651 8: 00007FF7D3A61B2B v8::internal::Factory::AllocateRawWithImmortalMap+59 9: 00007FF7D3A6449D v8::internal::Factory::NewRawOneByteString+77 10: 00007FF7D3AA93D3 v8::internal::interpreter::BytecodeArrayIterator::done+4563 11: 00007FF7D3B0968A v8::internal::WasmJs::Install+124170 12: 00007FF7D3B0BF11 v8::internal::WasmJs::Install+134545 13: 00007FF7D3B105CC v8::internal::WasmJs::Install+152652 14: 000001911535C5C1
download succeeded:
NOTE: Current Zowe LTS version (2.x) is using buffers for file management, but in Latest version (6.x) we switched to streams. Soon, Zowe v6.8.2 will become LTS and streams will be the default.
Also I have NodeJS v10.16.3
Maybe we need to look as this from z/OSMF perspective. I will try to talk with our sys progs.
If you have time, could you try to download it using Postman or cURL tools?
Thanks.
Hi,
I agree. It seems that the problem could be in the ZOSMF
And about downloading the file in other ways ..., the download is not important, as I said we are doing a PoC about ZOWE and what we want is to do it through ZOWE / ZOSMF.
regards
This I understand. The goal was to scope the error, if it really resides in the CLI or z/OSMF. If it's z/OSMF only, you should get the same error while calling the z/OSMF APIs directly.
Hi,
You're right. I tried to run itcalling the z/OSMF APIs directly (/zosmf/restfiles/ds/SYST.TEMP.WLMXGB) in the browser and and I get the same error "Error 500: java.io.IOException: Error response could not be sent to client. See log for details" at the end of the file.
Hi,
I've opened a z/OSMF restfile issue at IBM., i will tell you the conclusions.
Regards
Client version:
I've observed this with relatively big files. Console output:
But the last register (line) in the file contains:
(The
ACD 100806
is part of the record being transmitted when the problem happened)This is the content of the SYSPRINT file in the z/OS job:
I understand a long download can fail because of network problems (it shoud not, anyway!), my main compaint is the client part believes the download has succeed and appends the error message to the downloaded file!