Karthik,

let me try again :

Karthik Nanjangude wrote:
Hi

Maybe you could try a capture from the client system (the one
w/ a browser open).

As I have already posted the form [ please check last few mails exchanged ]

If the Sample test on the web application is performed from Outer side world 
[http://www.xyx.com/abcd ]

Tcp dump captured on Apache Http Server, 2 Post request are clearly visible 
with 12 sec apart.

> If the Sample test on the same hosted web application performed from within the internally IP/Port hosted [ http://xyx/abcd ]
>
> Tcp dump captured on JBoss [Tomcat Built in ] 1 Post request is visible
>

Let me use my graphic artwork again :

case a)

client browser (port 2345) --(a)--> (port 80) apache ---(b)---> mod_jk (port 1234) ---(c)---> (port 8109) tomcat --> DB

result (per trace on (c)): 2 POSTs (and 2 rows in database DB)

case b)

client  browser (port 2345) ----(d)---> (port 8080 or 8180..) tomcat  --> DB

result (per trace on (d) ?): 1 POST (in database DB)


What you have told us so far, is that when you watch the TCP traffic in (c) above, you see 2 POST requests, from port 1234 (mod_jk) to port 8109 (tomcat AJP connector).

But because these are on the internal link between Apache and Tomcat, it is difficult for us to see if these are really the /same/ request, duplicated by Apache/mod_jk, or just two totally unrelated POST requests from different clients. That is because, at the level of (c), ALL requests will look like they come from port 1234 (mod_jk) to port 8109 (tomcat).


What you have NOT proven to us so far, is that those 2 POST requests are NOT 
also in (a).
THAT is what we want to know, at 100%.

We want to know this, because we believe that Apache or mod_jk do not just duplicate POST requests. We do not believe that they do that, because if they did that, then you would not be the only person to mention this problemm and there would be LOTS of peoplehaving problems with their bank accounts.

Currently, we believe that it is about 10,000 times more probable, that the 2 POST requests are generated by something not working as you expect, but /on the browser side/.

Maybe we are wrong.
But to change our belief, you will have to bring real proof.
You are going to have to show us a trace done at the level (a), showing 1 single POST request, and a trace done at the same time at the level (c), showing 2 POST requests.






If the Sample test on the same hosted web application performed from within the 
internally IP/Port hosted [ http://xyx/abcd ]

Tcp dump captured on JBoss [Tomcat Built in ] 1 Post request is visible




Both of the samples were verified in 2 Browsers [IE 7+ / FF3 +] more then 6 
times and the info is captured via tcp Dump.


request with wget rather than browsers

Since the Application is in Production and need some Window Time for taking 
samples.

I would definitely get back with the results  by EOD 2 morrow


With regards
Karthik


-----Original Message-----
From: David Smith [mailto:d...@cornell.edu]
Sent: Wednesday, August 11, 2010 7:23 PM
To: Tomcat Users List
Subject: Re: 2 POST requests to underlying Server

Any chance we could see a snippet of access log showing the two
requests?  All I really see here is two packet captures that *look* like
they are from in between tomcat and iis (or whatever you are running as
a front-end web server).  Since 10 addresses are not routeable this
looks like all internal traffic.  Any chance you could verify this is
happening (or not) between the client browser and your front-end web
server?  Maybe you could try a capture from the client system (the one
w/ a browser open).

--David

On 8/11/10 2:08 AM, Karthik Nanjangude wrote:
Hi

Ok I have copied the wire shark test samples for the 2 Post Requests [ Apache 
to JBOSS (Tomcat Internal )..This was taken Aug 9, 2010




~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1nd Post Request

No.     Time        Source                Destination           Protocol Info
  10022 30.516874   10.151.41.160         10.151.41.163         TCP      33403 
> 8109 [PSH, ACK] Seq=2079 Ack=4544 Win=15600 Len=65 TSV=2265749122 
TSER=2977204079

Frame 10022 (131 bytes on wire, 131 bytes captured)
    Arrival Time: Aug  9, 2010 15:30:35.485640000
    [Time delta from previous captured frame: 0.000024000 seconds]
    [Time delta from previous displayed frame: 30.516874000 seconds]
    [Time since reference or first frame: 30.516874000 seconds]
    Frame Number: 10022
    Frame Length: 131 bytes
    Capture Length: 131 bytes
    [Frame is marked: True]
    [Protocols in frame: eth:ip:tcp:data]
    [Coloring Rule Name: TCP]
    [Coloring Rule String: tcp]
Ethernet II, Src: HewlettP_f8:fc:ea (00:24:81:f8:fc:ea), Dst: HewlettP_f8:7d:9c 
(00:24:81:f8:7d:9c)
    Destination: HewlettP_f8:7d:9c (00:24:81:f8:7d:9c)
        Address: HewlettP_f8:7d:9c (00:24:81:f8:7d:9c)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address 
(factory default)
    Source: HewlettP_f8:fc:ea (00:24:81:f8:fc:ea)
        Address: HewlettP_f8:fc:ea (00:24:81:f8:fc:ea)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address 
(factory default)
    Type: IP (0x0800)
Internet Protocol, Src: 10.151.41.160 (10.151.41.160), Dst: 10.151.41.163 
(10.151.41.163)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 117
    Identification: 0x0d18 (3352)
    Flags: 0x02 (Don't Fragment)
        0.. = Reserved bit: Not Set
        .1. = Don't fragment: Set
        ..0 = More fragments: Not Set
    Fragment offset: 0
    Time to live: 64
    Protocol: TCP (0x06)
    Header checksum: 0xc4fa [correct]
        [Good: True]
        [Bad : False]
    Source: 10.151.41.160 (10.151.41.160)
    Destination: 10.151.41.163 (10.151.41.163)
Transmission Control Protocol, Src Port: 33403 (33403), Dst Port: 8109 (8109), 
Seq: 2079, Ack: 4544, Len: 65
    Source port: 33403 (33403)
    Destination port: 8109 (8109)
    [Stream index: 64]
    Sequence number: 2079    (relative sequence number)
    [Next sequence number: 2144    (relative sequence number)]
    Acknowledgement number: 4544    (relative ack number)
    Header length: 32 bytes
    Flags: 0x18 (PSH, ACK)
        0... .... = Congestion Window Reduced (CWR): Not set
        .0.. .... = ECN-Echo: Not set
        ..0. .... = Urgent: Not set
        ...1 .... = Acknowledgement: Set
        .... 1... = Push: Set
        .... .0.. = Reset: Not set
        .... ..0. = Syn: Not set
        .... ...0 = Fin: Not set
    Window size: 15600 (scaled)
    Checksum: 0x2b50 [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
    Options: (12 bytes)
        NOP
        NOP
        Timestamps: TSval 2265749122, TSecr 2977204079
    [SEQ/ACK analysis]
        [Number of bytes in flight: 1134]
Data (65 bytes)

0000  12 34 00 3d 00 3b 73 69 6d 3d 38 39 36 30 31 39   .4.=.;sim=896019
0010  39 39 30 30 32 30 34 32 36 33 37 35 26 63 61 6e   990020426375&can
0020  6d 73 69 73 64 6e 3d 31 30 35 32 37 37 37 37 37   msisdn=105277777
0030  26 61 63 63 6f 75 6e 74 69 64 3d 36 37 39 37 35   &accountid=67975
0040  31                                                1
    Data: 1234003D003B73696D3D3839363031393939303032303432...
    [Length: 65]



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2nd Post Request

No.     Time        Source                Destination           Protocol Info
  15548 42.619208   10.151.41.160         10.151.41.163         TCP      33418 
> 8109 [PSH, ACK] Seq=1075 Ack=6 Win=5840 Len=65 TSV=2265761224 TSER=2977216182

Frame 15548 (131 bytes on wire, 131 bytes captured)
    Arrival Time: Aug  9, 2010 15:30:47.587974000
    [Time delta from previous captured frame: 0.000009000 seconds]
    [Time delta from previous displayed frame: 12.102334000 seconds]
    [Time since reference or first frame: 42.619208000 seconds]
    Frame Number: 15548
    Frame Length: 131 bytes
    Capture Length: 131 bytes
    [Frame is marked: True]
    [Protocols in frame: eth:ip:tcp:data]
    [Coloring Rule Name: TCP]
    [Coloring Rule String: tcp]
Ethernet II, Src: HewlettP_f8:fc:ea (00:24:81:f8:fc:ea), Dst: HewlettP_f8:7d:9c 
(00:24:81:f8:7d:9c)
    Destination: HewlettP_f8:7d:9c (00:24:81:f8:7d:9c)
        Address: HewlettP_f8:7d:9c (00:24:81:f8:7d:9c)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address 
(factory default)
    Source: HewlettP_f8:fc:ea (00:24:81:f8:fc:ea)
        Address: HewlettP_f8:fc:ea (00:24:81:f8:fc:ea)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address 
(factory default)
    Type: IP (0x0800)
Internet Protocol, Src: 10.151.41.160 (10.151.41.160), Dst: 10.151.41.163 
(10.151.41.163)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 117
    Identification: 0x2ad0 (10960)
    Flags: 0x02 (Don't Fragment)
        0.. = Reserved bit: Not Set
        .1. = Don't fragment: Set
        ..0 = More fragments: Not Set
    Fragment offset: 0
    Time to live: 64
    Protocol: TCP (0x06)
    Header checksum: 0xa742 [correct]
        [Good: True]
        [Bad : False]
    Source: 10.151.41.160 (10.151.41.160)
    Destination: 10.151.41.163 (10.151.41.163)
Transmission Control Protocol, Src Port: 33418 (33418), Dst Port: 8109 (8109), 
Seq: 1075, Ack: 6, Len: 65
    Source port: 33418 (33418)
    Destination port: 8109 (8109)
    [Stream index: 257]
    Sequence number: 1075    (relative sequence number)
    [Next sequence number: 1140    (relative sequence number)]
    Acknowledgement number: 6    (relative ack number)
    Header length: 32 bytes
    Flags: 0x18 (PSH, ACK)
        0... .... = Congestion Window Reduced (CWR): Not set
        .0.. .... = ECN-Echo: Not set
        ..0. .... = Urgent: Not set
        ...1 .... = Acknowledgement: Set
        .... 1... = Push: Set
        .... .0.. = Reset: Not set
        .... ..0. = Syn: Not set
        .... ...0 = Fin: Not set
    Window size: 5840 (scaled)
    Checksum: 0xbd20 [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
    Options: (12 bytes)
        NOP
        NOP
        Timestamps: TSval 2265761224, TSecr 2977216182
    [SEQ/ACK analysis]
        [Number of bytes in flight: 1134]
Data (65 bytes)

0000  12 34 00 3d 00 3b 73 69 6d 3d 38 39 36 30 31 39   .4.=.;sim=896019
0010  39 39 30 30 32 30 34 32 36 33 37 35 26 63 61 6e   990020426375&can
0020  6d 73 69 73 64 6e 3d 31 30 35 32 37 37 37 37 37   msisdn=105277777
0030  26 61 63 63 6f 75 6e 74 69 64 3d 36 37 39 37 35   &accountid=67975
0040  31                                                1
    Data: 1234003D003B73696D3D3839363031393939303032303432...
    [Length: 65]



With regards
Karthik








-----Original Message-----
From: Karthik Nanjangude [mailto:karthik.nanjang...@xius-bcgi.com]
Sent: Wednesday, August 11, 2010 11:03 AM
To: Tomcat Users List
Subject: RE: 2 POST requests to underlying Server

Hi


wireshark or tcpdump running on the external + internal segments simultaneously.

I can provide u the tcp dump samples which we used to validate using White 
shark.


Of course I need some time (probably by EOD ) to get permission from my 
authorities for the same.

Is this ok with u


With regards
KArthik

-----Original Message-----
From: Hassan Schroeder [mailto:hassan.schroe...@gmail.com]
Sent: Wednesday, August 11, 2010 10:49 AM
To: Tomcat Users List
Subject: Re: 2 POST requests to underlying Server

On Tue, Aug 10, 2010 at 10:07 PM, Karthik Nanjangude
<karthik.nanjang...@xius-bcgi.com> wrote:


The same test performed on the Internal IP (http://<ip:port>/ABCD), and was 
observed that the single Post request was observed with single Insertion to DB ... 
compared to 2 POST request via External IO ( http://ABCD.com )

So how does this prove that the JavaScript as stated below is not working .... 
:(

Forget the browser and the JavaScript -- reproduce the problem using
wget or curl or something basic to initiate your request, with wireshark
or tcpdump running on the external + internal segments simultaneously.

Then you'll have some interesting data :-)

--
Hassan Schroeder ------------------------ hassan.schroe...@gmail.com
twitter: @hassan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to