Possible Length issue

[Dhaivat Pandya <dh...@gmail.com>]

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

[Colin McCabe <cm...@alumni.cmu.edu>]

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
<dh...@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

[Suresh Srinivas <su...@hortonworks.com>]

Can you please share the details on the issue you found?

Sent from phone

> On Dec 29, 2013, at 1:04 PM, Dhaivat Pandya <dh...@gmail.com> wrote:
> 
> 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 <dh...@gmail.com>wrote:
> 
>> Anyone?
>> 
>> 
>> On Sat, Dec 28, 2013 at 1:06 PM, Dhaivat Pandya <dh...@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
>>> 
>> 
>> 

-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

Re: Possible Length issue

[Dhaivat Pandya <dh...@gmail.com>]

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 <dh...@gmail.com>wrote:

> Anyone?
>
>
> On Sat, Dec 28, 2013 at 1:06 PM, Dhaivat Pandya <dh...@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

[Dhaivat Pandya <dh...@gmail.com>]

Anyone?


On Sat, Dec 28, 2013 at 1:06 PM, Dhaivat Pandya <dh...@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
>