Java iSeries上的NIO文件通道传输问题

在iSeries设备（JDK1.5）上运行的一些Java NIO代码有问题。基本上，代码是将一个文件分割成块，将一个文件的一部分分割成另一个较小的文件。同样的代码已经在其他iSeries设备上运行了一段时间，没有出现任何问题。下面是代码片段：

//copy original data file content to temp file
long startPos = dataFile.length() - remaining;
long transferSize = maxSizeBytes - size;
size += inChannel.transferTo(startPos, transferSize, outChannel); //exception here
remaining -= size;

以下是堆栈跟踪：

Caused by: java.io.IOException: Operation not supported. Map failed
 at java.lang.Throwable.<init>(Throwable.java:196)
 at java.lang.Exception.<init>(Exception.java:41)
 at java.io.IOException.<init>(IOException.java:40)
 at sun.nio.ch.FileChannelImpl.map0(Native Method)
 at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:742)
at sun.nio.ch.FileChannelImpl.transferToTrustedChannel(FileChannelImpl.java:448)
at sun.nio.ch.FileChannelImpl.transferTo(FileChannelImpl.java:521)

原因：java.io.IOException:不支持操作。映射失败
位于java.lang.Throwable。（Throwable.java:196）
位于java.lang.Exception。（Exception.java:41）
在java.io.IOException.（IOException.java:40）
位于sun.nio.ch.FileChannelImpl.map0（本机方法）
位于sun.nio.ch.FileChannelImpl.map（FileChannelImpl.java:742）
位于sun.nio.ch.FileChannelImpl.transferToTrustedChannel（FileChannelImpl.java:448）
位于sun.nio.ch.FileChannelImpl.transferTo（FileChannelImpl.java:521）

。。。还有11个

我做了一些调查，到目前为止，原因（父目录的文件权限、内存不足、共享内存控制QSHRMEMCTL关闭、使用SAN）都被证明是不成功的

有没有人有过这种特殊问题的经验

谢谢，

---

Brad。

根据（支持引用NIO源代码的参数），可能的原因是内存不足。

我一直认为，达到文件句柄限制可能会导致JVM引发不明显的异常

---

检查是否有足够的可用文件句柄<代码>ulimit将告诉您有多少可供您使用。（当然，如果JVM是守护进程，您会想知道运行JVM的用户的这个数字。）这个问题也可能是系统/用户特定的，这与您描述的在其他地方运行的情况非常吻合。

好的，另一个镜头：您可以发布更多的代码吗？就像所有viables和控制循环的初始化一样。即使你说在其他地方工作，我还是对一些事情感到好奇，所以我忽略了这一点

1: long startPos = dataFile.length() - remaining;
2: long transferSize = maxSizeBytes - size;
3: size += inChannel.transferTo(startPos, transferSize, outChannel); //exception here
4: remaining -= size;

剩余的
是否初始化为
dataFile.length（）
在循环之外？如果不是的话，那么它将从一开始就一直爆炸

size

可能更好地命名为

bytesttransfered

。我发现我自己被这件事搞混了

您不需要同时使用

剩余的

和

大小

变量。一个或另一个应该足够了

---

是

maxSizeBytes

初始化为一个值，是的，我一直在看这个值。我假设源代码是Sun JDK实现，所以不一定相同？假设是这样的话，我们使用一个测试类在一个小文件（两个K）上运行，成功地引发了同样的错误，但仍然失败了。另一个因素是，最初的错误是遇到2gig堆大小和376字节的数据文件！我想还是有可能的，但似乎不太可能。也许我应该尝试一些-Xmx实验。内存不足的情况可能是操作系统的一部分，而不是Java堆（因为您正在尝试执行mmap）。您能在这些行中显示更多代码吗？我对所有这些中大小变量的语义感到困惑。它发生在特定的块或字节计数上吗？还是启动时失败？或者它是随机发生的？它是哪个iSeries和哪个IBMJVM（32位还是64位）。据我所知，32位VM有3 GB的堆限制，NIO的限制更大。要补充我之前的评论：对未显示的代码进行一些假设，您可能会遇到负TransferSize或在源文件末尾运行。事实上，32位JVM使用4字节引用（而不是8字节）来寻址对象。。。但这将被抓住（希望如此）。我的意见是，选择的缓冲区太大（他的传输大小）。在内部，分配一个字节缓冲区。尽管如此，我希望他没有更改transferSize大小…Stu-在目标用户帐户下检查了此值，返回值为“无限”。Stu，感谢您再次查看此值。我对第一个答案中提到的传输大小的代码做了一些调整，但没有任何帮助。我们通过添加一个非NIO代码路径来解决这个问题，在我们看到这个问题的系统上，这个路径是可选的。谢谢你的帮助和关心。