Re: Possible Length issue
There is a maximum length for message buffers that was introduced by HADOOP-9676. So messages with length 1752330339 should not be accepted. best, Colin On Sat, Dec 28, 2013 at 11:06 AM, Dhaivat Pandya dhaivatpan...@gmail.com wrote: Hi, I've been working a lot with the Hadoop NameNode IPC protocol (while building a cache layer on top of Hadoop). I've noticed that for request packets coming from the default DFS client that do not have a method name, the length field is often *completely *off. For example, I've been looking at packets with length 1752330339. I thought this might have been an issue with my cache layer, so I checked with Wireshark, and found packets with such absurd length parameters (obviously, the packets themselves weren't actually that long; the length field was misrepresented). Unfortunately, I haven't had the opportunity to test this issue on other machines and setups (the reproducing steps should be running an ls / with the default DFS client and sniffing the packets to find the length parameter, release 1.2.1). Is this normal behavior, a bug or something I'm missing? Thank you, Dhaivat
Re: Possible Length issue
Anyone? On Sat, Dec 28, 2013 at 1:06 PM, Dhaivat Pandya dhaivatpan...@gmail.comwrote: Hi, I've been working a lot with the Hadoop NameNode IPC protocol (while building a cache layer on top of Hadoop). I've noticed that for request packets coming from the default DFS client that do not have a method name, the length field is often *completely *off. For example, I've been looking at packets with length 1752330339. I thought this might have been an issue with my cache layer, so I checked with Wireshark, and found packets with such absurd length parameters (obviously, the packets themselves weren't actually that long; the length field was misrepresented). Unfortunately, I haven't had the opportunity to test this issue on other machines and setups (the reproducing steps should be running an ls / with the default DFS client and sniffing the packets to find the length parameter, release 1.2.1). Is this normal behavior, a bug or something I'm missing? Thank you, Dhaivat
Re: Possible Length issue
Actually, we can relegate this as a non-issue; I have found a different source of error in the system. On Sun, Dec 29, 2013 at 3:03 PM, Dhaivat Pandya dhaivatpan...@gmail.comwrote: Anyone? On Sat, Dec 28, 2013 at 1:06 PM, Dhaivat Pandya dhaivatpan...@gmail.comwrote: Hi, I've been working a lot with the Hadoop NameNode IPC protocol (while building a cache layer on top of Hadoop). I've noticed that for request packets coming from the default DFS client that do not have a method name, the length field is often *completely *off. For example, I've been looking at packets with length 1752330339. I thought this might have been an issue with my cache layer, so I checked with Wireshark, and found packets with such absurd length parameters (obviously, the packets themselves weren't actually that long; the length field was misrepresented). Unfortunately, I haven't had the opportunity to test this issue on other machines and setups (the reproducing steps should be running an ls / with the default DFS client and sniffing the packets to find the length parameter, release 1.2.1). Is this normal behavior, a bug or something I'm missing? Thank you, Dhaivat
Possible Length issue
Hi, I've been working a lot with the Hadoop NameNode IPC protocol (while building a cache layer on top of Hadoop). I've noticed that for request packets coming from the default DFS client that do not have a method name, the length field is often *completely *off. For example, I've been looking at packets with length 1752330339. I thought this might have been an issue with my cache layer, so I checked with Wireshark, and found packets with such absurd length parameters (obviously, the packets themselves weren't actually that long; the length field was misrepresented). Unfortunately, I haven't had the opportunity to test this issue on other machines and setups (the reproducing steps should be running an ls / with the default DFS client and sniffing the packets to find the length parameter, release 1.2.1). Is this normal behavior, a bug or something I'm missing? Thank you, Dhaivat
