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
