You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Karthik Nanjangude <ka...@xius-bcgi.com> on 2010/08/10 09:38:30 UTC
2 POST requests to underlying Server
Hi
Spec
Java 1.5
O/s : Linux
APP Server : JBOSS4.2.1 (Tomcat built with)
HTTP Server : apache_2.2.11 [ With out SSL ]
Mod library : mod_jk-1.2.28-httpd-2.2.X.so
LB 1 Apache : 1 JBOSS:Port of application
Question : Some times We have observed that on WEB Application ( click on button in jsp )
Apache is sending 2 POST requests to underlying JBOSS ( Tomcat server ).
Note: We even put a Java script filter to disable multiple Clicks for the page,
How we Observed : Via TCP Thread dump using command "tcpdump -i bond0 -s 1500 -w / tmp / test.pcap "
Can this configuration "worker.node1.socket_timeout=10" got any thing to do with this multiple request activity?
with regards
N.S.Karthik
Re: 2 POST requests to underlying Server
Posted by André Warnier <aw...@ice-sa.com>.
Karthik Nanjangude wrote:
> Hi
>
>>> Have you really traced the browser -> server side to see if the duplicate POST request
>
> As I have already said by using the TCP Thread dump using command
> "tcpdump -i bond0 -s 1500 -w / tmp / test.pcap "
>
> We are clearly able to see the IP Address of Apache written 2 times POST for the JBOSS ( Tomcat built in) being called with in 12 seconds apart.
>
> We also made sure there is no traffic /users using the web application during the tcp dump taken.
>
>
>>> Are they really the same, from the same client, with the same content
>
> For simple test case we used 1 simple transaction Page to do the activity
> For insertion, but the since 2 request to web server ,we see 2 rows inserted in DB
>
> This has happened in spite of blocking multiple button clicks on jsp page using jscript filter.
>
>
>>> claim that Apache or mod_jk or Tomcat duplicates a POST
>
> My Observation as per TCP dump command, we clearly see multiple request being sent from Apache to web server.
>
>
Ok then, suppose that I believe you.
Then look at the following page :
http://tomcat.apache.org/connectors-doc/webserver_howto/apache.html
section : Logging
Use these mod_jk configuration instructions in Apache to set the mod_jk log level to
"debug" and retry your test.
Then look at the mod_jk logfile, find the section(s) relevant to the two consecutive POST
requests, and see if you find a reason why mod_jk would send these two requests.
If it is as a result of an error, there should be error messages.
If you do not see the error, copy the the relevant lines here.
(really paste it, do not add it as attachment. This list generally strips them).
>
>
> With regards
> KArthik
>
>
>
> -----Original Message-----
> From: André Warnier [mailto:aw@ice-sa.com]
> Sent: Tuesday, August 10, 2010 4:48 PM
> To: Tomcat Users List
> Subject: Re: 2 POST requests to underlying Server
>
> Karthik Nanjangude wrote:
>> Hi
>>
>>>> (*) do you have any particular reason to use this setting, instead of the default ? Or is
>> it just something you copied from some blog page ?
>>
>>
>> 1) I have not copied the same from any Blog , it is as defined
>> configuration as is from the N/w team
>>
>> 2) Where can I fine the default settings for the same ?
>
> In the on-line documentation, at
> http://tomcat.apache.org/connectors-doc/reference/workers.html
>
>>
>> 3) As I have already said We have put a Java script filter to disable
>> multiple Clicks for dual request from the Browser ( IE 7+ / FF 3+ )
>>
>
> Well, maybe it is not working. Have you really traced the browser -> server side to see
> if the duplicate POST request originates there ?
>
> Plus, in your original message, you do not define very clearly what these 2 POST requests
> are. Are they really the same, from the same client, with the same content ? how close to
> one another do they arrive ?
>
> If it was mod_jk resending the same request after the socket_timeout of 10 s, then the 2
> POST requests should be separated by at least 10 s. Are they ?
>
> As someone once said : Extraordinary claims require extraordinary proof.
>
> In other words : you seem to claim that Apache or mod_jk or Tomcat duplicates a POST
> request. This is not the behaviour experienced by the vast majority of Apache + mod_jk +
> Tomcat installations. So you need data a bit more solid than what you have supplied so
> far, before someone will believe that there is another reason than the user clicking twice.
>
>
>
>>
>>
>>
>> With regards
>> karthik
>>
>>
>>
>> -----Original Message-----
>> From: André Warnier [mailto:aw@ice-sa.com]
>> Sent: Tuesday, August 10, 2010 4:10 PM
>> To: Tomcat Users List
>> Subject: Re: 2 POST requests to underlying Server
>>
>> Karthik Nanjangude wrote:
>>> Hi
>>>
>>> Spec
>>> Java 1.5
>>> O/s : Linux
>>> APP Server : JBOSS4.2.1 (Tomcat built with)
>>> HTTP Server : apache_2.2.11 [ With out SSL ]
>>> Mod library : mod_jk-1.2.28-httpd-2.2.X.so
>>> LB 1 Apache : 1 JBOSS:Port of application
>>>
>>>
>>> Question : Some times We have observed that on WEB Application ( click on button in jsp )
>>> Apache is sending 2 POST requests to underlying JBOSS ( Tomcat server ).
>>>
>>> Note: We even put a Java script filter to disable multiple Clicks for the page,
>>>
>>>
>>> How we Observed : Via TCP Thread dump using command "tcpdump -i bond0 -s 1500 -w / tmp / test.pcap "
>>>
>>>
>>> Can this configuration "worker.node1.socket_timeout=10" got any thing to do with this multiple request activity?
>>>
>> Unlikely, but :
>>
>> 1) simple test : remove this setting, and see if the issue still appears (*)
>> (By removing the setting, you make the timeout infinite)
>>
>> 2) use the mod_jk logging level TRACE, to see exactly what mod_jk is sending to Tomcat
>>
>> 3) It is unlikely that any Apache or mod_jk or Tomcat component would repeat a POST
>> request, because that kind of violates the HTTP RFC. So chances are, that the double POST
>> request is /still/ coming from the browser.
>>
>>
>> (*) do you have any particular reason to use this setting, instead of the default ? Or is
>> it just something you copied from some blog page ?
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 2 POST requests to underlying Server
Posted by David Fisher <df...@jmlafferty.com>.
There should be one or more devices inserted in (a)
> client browser (port 2345) --(a)--> (port 80) apache ---(b)---> mod_jk (port 1234) ---(c)---> (port 8109) tomcat --> DB
There should be a firewall, or who knows what a hacker may have inserted.
There might be a load balancer.
If either of these is misconfigured then who knows.
The technique that everyone is suggesting is a form of "Divide and Conquer" - and is something that every programmer must learn to employ. Refusal is a waste of everyone's time including the OP.
http://en.wikipedia.org/wiki/Divide_and_conquer_algorithm
Regards,
Dave
On Aug 11, 2010, at 9:04 AM, André Warnier wrote:
> 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:dns4@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.nanjangude@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.schroeder@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
>>> <ka...@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.schroeder@gmail.com
>>> twitter: @hassan
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 2 POST requests to underlying Server
Posted by André Warnier <aw...@ice-sa.com>.
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:dns4@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.nanjangude@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.schroeder@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
>> <ka...@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.schroeder@gmail.com
>> twitter: @hassan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 2 POST requests to underlying Server
Posted by David Smith <dn...@cornell.edu>.
Let me demonstrate I have read the *entire* thread:
You stated on 8/10/2010 at 8:16am EDT:
> We also made sure there is no traffic /users using the web application during the tcp dump taken.
>
How? Are you absolutely sure *no* client generated the POST request?
> ... This has happened in spite of blocking multiple button clicks on jsp page using jscript filter.
>
Are you sure? As has been recommended, remove the browser and all it's
javascript from the equation. Use wget or curl to manually fire just
*one* request and see what happens.
> My Observation as per TCP dump command, we clearly see multiple request being sent from Apache to web server.
Not in question at all... but we've not seen any evidence the requests
were sourced from Apache. They could just as easily come from a client
brower, a firewall or even a proxy server and passed on by Apache.
Stated multiple times in various messages of this thread:
> For simple test case we used 1 simple transaction Page to do the
> activity For insertion, but the since 2 request to web server ,we see
> 2 rows inserted in DB
>
>
Still have the browser and it's javascript in the equation. Plus I've
yet to see any evidence these requests are sourced from httpd or
mod_jk. This could easily be the browser or some component between
httpd and the client.
You stated on 8/11/2010 at 1:07am EDT:
> 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 )
>
We have only ever seen a tcp dump in between Apache httpd and jboss and
only fragments at that. Certainly not enough to believe the two are
requests are in any way related. The POST command, headers, etc., ...
are far better evidence.
You stated on 8/11/2010 at 6:37am EDT:
> If needed I can even share the "Access Logs" of Apache so that the browser details match [ IE 7+ / FFox 3+ ] are as available.
>
I believe at least one of us has already asked for this. Don't make me
dig up the quote(s).
Let me recap so I am very clear. We have not seen any evidence that
these requests are from Apache and/or mod_jk. They could very easily be
from:
-- a misbehaving client (client in this case is very broad including
hack attempts, search crawlers, browsers, etc., ...)
-- firewall
-- proxy server
Just to make matters a little more interesting, client id signatures can
easily be faked for any browser you can think of. Just because it
claims to be IE doesn't mean it is.
A lot of us use mod_jk to connect apache to tomcat. On the rare event
this kind of issue has cropped up it seems to always be as a result of
something outside apache mod_jk and tomcat.
--David
On 8/11/10 10:06 AM, 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
>
>
>
>
> 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:dns4@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:
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: 2 POST requests to underlying Server
Posted by Karthik Nanjangude <ka...@xius-bcgi.com>.
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
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:dns4@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.nanjangude@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.schroeder@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
> <ka...@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.schroeder@gmail.com
> twitter: @hassan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 2 POST requests to underlying Server
Posted by Hassan Schroeder <ha...@gmail.com>.
On Wed, Aug 11, 2010 at 5:29 AM, Karthik Nanjangude
<ka...@xius-bcgi.com> wrote:
> As requested by the Form I have provided the TCP Dump details.
No you haven't. I, at least, wouldn't assume this is a mod_jk/httpd problem
*until* I see simultaneous traces from *both sides* of the box, proving that
*one* client request is reaching the httpd, and *two* requests are coming
out the other side to Tomcat.
> I have provided most of the Info using the tools the form has asked me to.
And again, it's totally trivial to create a simple test request with wget
rather than browsers with JavaScript enabled, running who knows
what.
If, with that test, you see a failure, the "steps-to-reproduce" becomes
much easier for other people to try...
FWIW,
--
Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
twitter: @hassan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: 2 POST requests to underlying Server
Posted by Karthik Nanjangude <ka...@xius-bcgi.com>.
Hi
I am not Complaining about TOMCAT and have been using this form since year 2000
My Request to the Form is about the Tomcat Connector (mod_jk-1.2.28-httpd-2.2.3.so ) which Connects between 1 APACHE HTTP and 1 JBOSS (Tomcat built in)
As requested by the Form I have provided the TCP Dump details.
>> You are the one who wants help.
Does this mean if some body out there ( 1 out of 100000... Installers ) is reporting a flaw ...would be snubbed.
>> But it is not as clear to someone who is not at your location, cannot see
your systems or your screen, does not know your code, and has to rely *exclusively* on
what you write to this list.
I have provided most of the Info using the tools the form has asked me to.
>> So when someone is asking you, nicely, to simplify the problem, eliminate the browser, and
use wget or something similar to make the request, it is not in order to bug you.
My sincere Apologies if I have offended the form users
>>Similarly, when you say "when the same test cases were done from INTERNAL IP on the same
Application", that is not clear at all to some of us.
Can you explain, in detail, what that means ?
An WEB - Application of ours in Production is hosted on JBOSS( Tomcat built in ) and uses mod_jk-1.2.28-httpd-2.2.3.so, Apache 2.2.1 to the INTERNET
as http://www.xyx.com/abcd
In this case the TCP Dump displays 2 Post requests. ........... :(
The Application is also accessible via internal port of JBOSS (Tomcat built in ) via INTRANET as http://<IP>:<Port>/abcd
In this case the TCP Dump displays 1 Post requests. .............. :)
With regards
Karthik
-----Original Message-----
From: André Warnier [mailto:aw@ice-sa.com]
Sent: Wednesday, August 11, 2010 5:43 PM
To: Tomcat Users List
Subject: Re: 2 POST requests to underlying Server
Karthik Nanjangude wrote:
> Hi
>
>>> So do both browsers report the same error?
>
> If needed I can even share the "Access Logs" of Apache so that the browser details match [ IE 7+ / FFox 3+ ] are as available.
>
>>> And what was the period in each case? Exactly 12.1 seconds? For both
> Browsers types?
>
> Yes Approximately 12 sec in case of both browsers.
>
>>> what is the resource type being generated a JSP or another file type?
>
> I presume the u are asking about the Controller page which is of type JSP /Struts based application at the JBOSS(Tomcat built in)
>
>
> I am still confused when the same test cases were done from INTERNAL IP on the same Application as per tcp dump displays 1 Post request.
>
>
Karthik,
Just some basic observations for your consideration :
1) Tomcat is free and open-source software. It is made by volunteers, on their free time.
You are free to use it, but there is no guarantee of any kind.
2) This list is also managed and answered by volunteers, who do their best, on their own
free time. There is no guarantee of support, it is all on a best effort base.
3) You are the one who wants help.
Yes ?
4) Your configuration and your setup, and what you see in your logfiles, may all be very
clear to you. But it is not as clear to someone who is not at your location, cannot see
your systems or your screen, does not know your code, and has to rely *exclusively* on
what you write to this list.
Specially, when you report a problem that, to many here, seems very unlikely.
What I am saying above, is that it belongs to you to provide clear and detailed
information, so that someone here can (maybe) help you.
It is not the reverse, where people here have to squeeze information out from you, and
spend a lot of time doing so. Many people just do not have the time and patience to do that.
So when someone is asking you, nicely, to simplify the problem, eliminate the browser, and
use wget or something similar to make the request, it is not in order to bug you.
It is so that they have one less possible cause of trouble to worry about, and can
concentrate on the (possible) problem with mod_jk or Tomcat.
Similarly, when you say "when the same test cases were done from INTERNAL IP on the same
Application", that is not clear at all to some of us.
Can you explain, in detail, what that means ?
If it helps, make a picture, like :
case a)
client -> apache -> mod_jk -> tomcat
result : 2 POSTs
case b)
client -> Tomcat
result : 1 POST
Is is that ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 2 POST requests to underlying Server
Posted by André Warnier <aw...@ice-sa.com>.
Karthik Nanjangude wrote:
> Hi
>
>>> So do both browsers report the same error?
>
> If needed I can even share the "Access Logs" of Apache so that the browser details match [ IE 7+ / FFox 3+ ] are as available.
>
>>> And what was the period in each case? Exactly 12.1 seconds? For both
> Browsers types?
>
> Yes Approximately 12 sec in case of both browsers.
>
>>> what is the resource type being generated a JSP or another file type?
>
> I presume the u are asking about the Controller page which is of type JSP /Struts based application at the JBOSS(Tomcat built in)
>
>
> I am still confused when the same test cases were done from INTERNAL IP on the same Application as per tcp dump displays 1 Post request.
>
>
Karthik,
Just some basic observations for your consideration :
1) Tomcat is free and open-source software. It is made by volunteers, on their free time.
You are free to use it, but there is no guarantee of any kind.
2) This list is also managed and answered by volunteers, who do their best, on their own
free time. There is no guarantee of support, it is all on a best effort base.
3) You are the one who wants help.
Yes ?
4) Your configuration and your setup, and what you see in your logfiles, may all be very
clear to you. But it is not as clear to someone who is not at your location, cannot see
your systems or your screen, does not know your code, and has to rely *exclusively* on
what you write to this list.
Specially, when you report a problem that, to many here, seems very unlikely.
What I am saying above, is that it belongs to you to provide clear and detailed
information, so that someone here can (maybe) help you.
It is not the reverse, where people here have to squeeze information out from you, and
spend a lot of time doing so. Many people just do not have the time and patience to do that.
So when someone is asking you, nicely, to simplify the problem, eliminate the browser, and
use wget or something similar to make the request, it is not in order to bug you.
It is so that they have one less possible cause of trouble to worry about, and can
concentrate on the (possible) problem with mod_jk or Tomcat.
Similarly, when you say "when the same test cases were done from INTERNAL IP on the same
Application", that is not clear at all to some of us.
Can you explain, in detail, what that means ?
If it helps, make a picture, like :
case a)
client -> apache -> mod_jk -> tomcat
result : 2 POSTs
case b)
client -> Tomcat
result : 1 POST
Is is that ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: 2 POST requests to underlying Server
Posted by Karthik Nanjangude <ka...@xius-bcgi.com>.
Hi
>>So do both browsers report the same error?
If needed I can even share the "Access Logs" of Apache so that the browser details match [ IE 7+ / FFox 3+ ] are as available.
>> And what was the period in each case? Exactly 12.1 seconds? For both
Browsers types?
Yes Approximately 12 sec in case of both browsers.
>> what is the resource type being generated a JSP or another file type?
I presume the u are asking about the Controller page which is of type JSP /Struts based application at the JBOSS(Tomcat built in)
I am still confused when the same test cases were done from INTERNAL IP on the same Application as per tcp dump displays 1 Post request.
With regards
karthik
-----Original Message-----
From: Pid [mailto:pid@pidster.com]
Sent: Wednesday, August 11, 2010 3:45 PM
To: Tomcat Users List
Subject: Re: 2 POST requests to underlying Server
On 11/08/2010 09:25, Karthik Nanjangude wrote:
> Hi
>
>>> #1 I'm not sure the JavaScript you posted will work in all browsers.
>
> Absolutely Correct the Application is limited to usage of 2 browsers Via Browser Filter [ IE 7+ ot FF3+ ] Tests carried out from the same.
So do both browsers report the same error?
>>> #2 These two requests are around 12 seconds apart. Perform exactly the same test at least 10 more times and report what the period between the pair of requests is.
>
> The sample give was 1 out of 6 times done on the same day
And what was the period in each case? Exactly 12.1 seconds? For both
browsers types?
>>> #3 I can't see from the trace above what the resource type is, but if it's a PDF for example, the browser (+plugin) may be attempting to open
> multiple connections with different byte ranges.
>
> This process does not use any Plugin, it just sends the info to underlying Business Layer and finally on to DataBase.
what does? the browser? the point is that browsers can behave
differently for different resource types.
what is the resource type being generated a JSP or another file type?
p
> -----Original Message-----
> From: Pid [mailto:pid@pidster.com]
> Sent: Wednesday, August 11, 2010 1:41 PM
> To: Tomcat Users List
> Subject: Re: 2 POST requests to underlying Server
>
> On 11/08/2010 07:08, 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
>
>
>> 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
>
>
>> 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]
>
>
> #1 I'm not sure the JavaScript you posted will work in all browsers.
>
> #2 These two requests are around 12 seconds apart. Perform exactly the
> same test at least 10 more times and report what the period between the
> pair of requests is.
>
> #3 I can't see from the trace above what the resource type is, but if
> it's a PDF for example, the browser (+plugin) may be attempting to open
> multiple connections with different byte ranges.
>
>
> p
>
>> -----Original Message-----
>> From: Karthik Nanjangude [mailto:karthik.nanjangude@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.schroeder@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
>> <ka...@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.schroeder@gmail.com
>> twitter: @hassan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 2 POST requests to underlying Server
Posted by Pid <pi...@pidster.com>.
On 11/08/2010 09:25, Karthik Nanjangude wrote:
> Hi
>
>>> #1 I'm not sure the JavaScript you posted will work in all browsers.
>
> Absolutely Correct the Application is limited to usage of 2 browsers Via Browser Filter [ IE 7+ ot FF3+ ] Tests carried out from the same.
So do both browsers report the same error?
>>> #2 These two requests are around 12 seconds apart. Perform exactly the same test at least 10 more times and report what the period between the pair of requests is.
>
> The sample give was 1 out of 6 times done on the same day
And what was the period in each case? Exactly 12.1 seconds? For both
browsers types?
>>> #3 I can't see from the trace above what the resource type is, but if it's a PDF for example, the browser (+plugin) may be attempting to open
> multiple connections with different byte ranges.
>
> This process does not use any Plugin, it just sends the info to underlying Business Layer and finally on to DataBase.
what does? the browser? the point is that browsers can behave
differently for different resource types.
what is the resource type being generated a JSP or another file type?
p
> -----Original Message-----
> From: Pid [mailto:pid@pidster.com]
> Sent: Wednesday, August 11, 2010 1:41 PM
> To: Tomcat Users List
> Subject: Re: 2 POST requests to underlying Server
>
> On 11/08/2010 07:08, 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
>
>
>> 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
>
>
>> 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]
>
>
> #1 I'm not sure the JavaScript you posted will work in all browsers.
>
> #2 These two requests are around 12 seconds apart. Perform exactly the
> same test at least 10 more times and report what the period between the
> pair of requests is.
>
> #3 I can't see from the trace above what the resource type is, but if
> it's a PDF for example, the browser (+plugin) may be attempting to open
> multiple connections with different byte ranges.
>
>
> p
>
>> -----Original Message-----
>> From: Karthik Nanjangude [mailto:karthik.nanjangude@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.schroeder@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
>> <ka...@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.schroeder@gmail.com
>> twitter: @hassan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
RE: 2 POST requests to underlying Server
Posted by Karthik Nanjangude <ka...@xius-bcgi.com>.
Hi
>> #1 I'm not sure the JavaScript you posted will work in all browsers.
Absolutely Correct the Application is limited to usage of 2 browsers Via Browser Filter [ IE 7+ ot FF3+ ] Tests carried out from the same.
>>#2 These two requests are around 12 seconds apart. Perform exactly the same test at least 10 more times and report what the period between the pair of requests is.
The sample give was 1 out of 6 times done on the same day
>>#3 I can't see from the trace above what the resource type is, but if it's a PDF for example, the browser (+plugin) may be attempting to open
multiple connections with different byte ranges.
This process does not use any Plugin, it just sends the info to underlying Business Layer and finally on to DataBase.
With regards
karthik
-----Original Message-----
From: Pid [mailto:pid@pidster.com]
Sent: Wednesday, August 11, 2010 1:41 PM
To: Tomcat Users List
Subject: Re: 2 POST requests to underlying Server
On 11/08/2010 07:08, 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
> 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
> 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]
#1 I'm not sure the JavaScript you posted will work in all browsers.
#2 These two requests are around 12 seconds apart. Perform exactly the
same test at least 10 more times and report what the period between the
pair of requests is.
#3 I can't see from the trace above what the resource type is, but if
it's a PDF for example, the browser (+plugin) may be attempting to open
multiple connections with different byte ranges.
p
> -----Original Message-----
> From: Karthik Nanjangude [mailto:karthik.nanjangude@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.schroeder@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
> <ka...@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.schroeder@gmail.com
> twitter: @hassan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: 2 POST requests to underlying Server
Posted by Karthik Nanjangude <ka...@xius-bcgi.com>.
Hi
The Window for activation " mod_jk logging" is requested and would provide the same as soon as I get them from the N/w Maintancence guy [ may take another 2 or more days] Since the application is on Production and cannot be disturbed as of traffic.
With regards
Karthik
-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net]
Sent: Wednesday, August 11, 2010 10:37 PM
To: Tomcat Users List
Subject: Re: 2 POST requests to underlying Server
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pid,
On 8/11/2010 4:11 AM, Pid wrote:
> #1 I'm not sure the JavaScript you posted will work in all browsers.
+1
It's better to simply disable the button or the form than doing this
click counting stuff.
> #2 These two requests are around 12 seconds apart. Perform exactly the
> same test at least 10 more times and report what the period between the
> pair of requests is.
>
> #3 I can't see from the trace above what the resource type is, but if
> it's a PDF for example, the browser (+plugin) may be attempting to open
> multiple connections with different byte ranges.
+1
The presented data does not even include a full POST... just some random
data in the middle.
I still don't know why Karthik is unwilling to enable mod_jk logging and
use that: it's sooo much easier to read and will likely tell us
everything we need to know.
I'm done replying until we get some real data to look at.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxi2MwACgkQ9CaO5/Lv0PCqYgCgwEsO5ifT+tPn37enjXZmFsDu
AN8An3fmZyIgfGvFisFO9N9mqnETR9th
=1/YA
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 2 POST requests to underlying Server
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pid,
On 8/11/2010 4:11 AM, Pid wrote:
> #1 I'm not sure the JavaScript you posted will work in all browsers.
+1
It's better to simply disable the button or the form than doing this
click counting stuff.
> #2 These two requests are around 12 seconds apart. Perform exactly the
> same test at least 10 more times and report what the period between the
> pair of requests is.
>
> #3 I can't see from the trace above what the resource type is, but if
> it's a PDF for example, the browser (+plugin) may be attempting to open
> multiple connections with different byte ranges.
+1
The presented data does not even include a full POST... just some random
data in the middle.
I still don't know why Karthik is unwilling to enable mod_jk logging and
use that: it's sooo much easier to read and will likely tell us
everything we need to know.
I'm done replying until we get some real data to look at.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxi2MwACgkQ9CaO5/Lv0PCqYgCgwEsO5ifT+tPn37enjXZmFsDu
AN8An3fmZyIgfGvFisFO9N9mqnETR9th
=1/YA
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 2 POST requests to underlying Server
Posted by Pid <pi...@pidster.com>.
On 11/08/2010 07:08, 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
> 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
> 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]
#1 I'm not sure the JavaScript you posted will work in all browsers.
#2 These two requests are around 12 seconds apart. Perform exactly the
same test at least 10 more times and report what the period between the
pair of requests is.
#3 I can't see from the trace above what the resource type is, but if
it's a PDF for example, the browser (+plugin) may be attempting to open
multiple connections with different byte ranges.
p
> -----Original Message-----
> From: Karthik Nanjangude [mailto:karthik.nanjangude@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.schroeder@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
> <ka...@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.schroeder@gmail.com
> twitter: @hassan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: 2 POST requests to underlying Server
Posted by David Smith <dn...@cornell.edu>.
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.nanjangude@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.schroeder@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
> <ka...@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.schroeder@gmail.com
> twitter: @hassan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: 2 POST requests to underlying Server
Posted by Karthik Nanjangude <ka...@xius-bcgi.com>.
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.nanjangude@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.schroeder@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
<ka...@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.schroeder@gmail.com
twitter: @hassan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: 2 POST requests to underlying Server
Posted by Karthik Nanjangude <ka...@xius-bcgi.com>.
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.schroeder@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
<ka...@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.schroeder@gmail.com
twitter: @hassan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 2 POST requests to underlying Server
Posted by Hassan Schroeder <ha...@gmail.com>.
On Tue, Aug 10, 2010 at 10:07 PM, Karthik Nanjangude
<ka...@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.schroeder@gmail.com
twitter: @hassan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: 2 POST requests to underlying Server
Posted by Karthik Nanjangude <ka...@xius-bcgi.com>.
Hi
>> the point
is your JavaScript "filter to disable multiple Clicks" may not be as
fool proof as you think.
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 .... :(
var no_clicks=0;
function isClicked(){
if(no_clicks == 0 ){
no_clicks++;
document.xxx.action="abcd.jsp";
document.xxx.submit();
}else{
return false;
}
}
With regards
KArthik
-----Original Message-----
From: Ðavîd Låndïs [mailto:dlandis@gmail.com]
Sent: Wednesday, August 11, 2010 2:54 AM
To: Tomcat Users List
Subject: Re: 2 POST requests to underlying Server
3) As I have already said We have put a Java script filter to disable
multiple Clicks for dual request from the Browser ( IE 7+ / FF 3+ )
I had a similar issue once due to jQuery. If you attach the same click
listener twice to the same button, it'll submit 2 POST's or GET's for
one mouse click (in the latest version of jQuery). There may be other
ways to accomplish that as well with other libraries, etc -- the point
is your JavaScript "filter to disable multiple Clicks" may not be as
fool proof as you think.
On Tue, Aug 10, 2010 at 12:29 PM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Karthik,
>
> On 8/10/2010 9:08 AM, Karthik Nanjangude wrote:
>> Problem exists ,Proof given
>
> No: Problem is observed, very little in the way of proof has been given.
>
> You've made assertions about the circumstances and observed results.
>
> You have actually provided no data at all. Instead, you've merely stated
> that you've read the logs and they prove something is wrong.
>
> Since apparently nobody believes that you are interpreting the logs
> correctly, why not simply post the logs themselves. You'll need to
> provide the following:
>
> 1. An httpd log file showing the incoming request(s) from the client/browser
>
> 2. A mod_jk log file showing the communication between httpd and Tomcat
>
> 3. A tcpdump log file, if you really wish to include it
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkxhfnMACgkQ9CaO5/Lv0PAXKACfZMSU3dhcRaJYD66BSXsodw3Q
> jGEAoI/M+o22p2m76vk+jZb+B4VMeTvE
> =AHZ2
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 2 POST requests to underlying Server
Posted by André Warnier <aw...@ice-sa.com>.
Ðavîd Låndïs wrote:
> 3) As I have already said We have put a Java script filter to disable
> multiple Clicks for dual request from the Browser ( IE 7+ / FF 3+ )
>
> I had a similar issue once due to jQuery. If you attach the same click
> listener twice to the same button, it'll submit 2 POST's or GET's for
> one mouse click (in the latest version of jQuery). There may be other
> ways to accomplish that as well with other libraries, etc -- the point
> is your JavaScript "filter to disable multiple Clicks" may not be as
> fool proof as you think.
>
...
which is basically what everyone is trying to tell Karthik, but he does not seem to want
to hear.
So, Karthik :
a) you have NOT proven yet that the 2 POST requests do not come from the browser
b) in 100,000+ installations out there on the Internet, Apache + mod_jk dor NOT generate
duplicate POST requests. (If they did, you can be sure that we would have heard about it
by now).
c) Only YOU think that your Apache + mod_jk generate duplicate POST requests
So, prove that to us, by providing real data showing it, and then we will try to help you
solve the problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 2 POST requests to underlying Server
Posted by Ðavîd Låndïs <dl...@gmail.com>.
3) As I have already said We have put a Java script filter to disable
multiple Clicks for dual request from the Browser ( IE 7+ / FF 3+ )
I had a similar issue once due to jQuery. If you attach the same click
listener twice to the same button, it'll submit 2 POST's or GET's for
one mouse click (in the latest version of jQuery). There may be other
ways to accomplish that as well with other libraries, etc -- the point
is your JavaScript "filter to disable multiple Clicks" may not be as
fool proof as you think.
On Tue, Aug 10, 2010 at 12:29 PM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Karthik,
>
> On 8/10/2010 9:08 AM, Karthik Nanjangude wrote:
>> Problem exists ,Proof given
>
> No: Problem is observed, very little in the way of proof has been given.
>
> You've made assertions about the circumstances and observed results.
>
> You have actually provided no data at all. Instead, you've merely stated
> that you've read the logs and they prove something is wrong.
>
> Since apparently nobody believes that you are interpreting the logs
> correctly, why not simply post the logs themselves. You'll need to
> provide the following:
>
> 1. An httpd log file showing the incoming request(s) from the client/browser
>
> 2. A mod_jk log file showing the communication between httpd and Tomcat
>
> 3. A tcpdump log file, if you really wish to include it
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkxhfnMACgkQ9CaO5/Lv0PAXKACfZMSU3dhcRaJYD66BSXsodw3Q
> jGEAoI/M+o22p2m76vk+jZb+B4VMeTvE
> =AHZ2
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 2 POST requests to underlying Server
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Karthik,
On 8/10/2010 9:08 AM, Karthik Nanjangude wrote:
> Problem exists ,Proof given
No: Problem is observed, very little in the way of proof has been given.
You've made assertions about the circumstances and observed results.
You have actually provided no data at all. Instead, you've merely stated
that you've read the logs and they prove something is wrong.
Since apparently nobody believes that you are interpreting the logs
correctly, why not simply post the logs themselves. You'll need to
provide the following:
1. An httpd log file showing the incoming request(s) from the client/browser
2. A mod_jk log file showing the communication between httpd and Tomcat
3. A tcpdump log file, if you really wish to include it
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxhfnMACgkQ9CaO5/Lv0PAXKACfZMSU3dhcRaJYD66BSXsodw3Q
jGEAoI/M+o22p2m76vk+jZb+B4VMeTvE
=AHZ2
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 2 POST requests to underlying Server
Posted by Hassan Schroeder <ha...@gmail.com>.
On Tue, Aug 10, 2010 at 6:08 AM, Karthik Nanjangude
<ka...@xius-bcgi.com> wrote:
> Problem exists ,Proof given
Sorry, if you're not monitoring all parts of the request path, you've
"proved" nothing.
>>> If that were true, you wouldn't have *any* requests.
>
> For simple test case we used 1 simple transaction Page
Why not use something with demonstrably fewer moving parts, like
`wget`?
--
Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
twitter: @hassan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: 2 POST requests to underlying Server
Posted by Karthik Nanjangude <ka...@xius-bcgi.com>.
Hi
>> dialing the nearest exorcist...
HAHA Very Funny
Problem exists ,Proof given
>> If that were true, you wouldn't have *any* requests.
For simple test case we used 1 simple transaction Page to do the
activity For insertion, but the since 2 request to web server ,we see
2 rows inserted in DB
Please see this part for the simulation caused
With regards
karthik
-----Original Message-----
From: Hassan Schroeder [mailto:hassan.schroeder@gmail.com]
Sent: Tuesday, August 10, 2010 6:17 PM
To: Tomcat Users List
Subject: Re: 2 POST requests to underlying Server
On Tue, Aug 10, 2010 at 5:16 AM, Karthik Nanjangude
<ka...@xius-bcgi.com> wrote:
>>> Have you really traced the browser -> server side to see if the duplicate POST request
>
> As I have already said by using the TCP Thread dump using command
> "tcpdump -i bond0 -s 1500 -w / tmp / test.pcap "
>
> We are clearly able to see the IP Address of Apache written 2 times POST for the JBOSS ( Tomcat built in) being called with in 12 seconds apart.
So you're looking at the traffic between the httpd and Tomcat -- what about the
traffic on the "outside" of the httpd?
> We also made sure there is no traffic /users using the web application during the tcp dump taken.
If that were true, you wouldn't have *any* requests. Unless you think
your httpd is simply generating them on its own, in which case I'd be
headed for the door, or dialing the nearest exorcist...
--
Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
twitter: @hassan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 2 POST requests to underlying Server
Posted by Hassan Schroeder <ha...@gmail.com>.
On Tue, Aug 10, 2010 at 5:16 AM, Karthik Nanjangude
<ka...@xius-bcgi.com> wrote:
>>> Have you really traced the browser -> server side to see if the duplicate POST request
>
> As I have already said by using the TCP Thread dump using command
> "tcpdump -i bond0 -s 1500 -w / tmp / test.pcap "
>
> We are clearly able to see the IP Address of Apache written 2 times POST for the JBOSS ( Tomcat built in) being called with in 12 seconds apart.
So you're looking at the traffic between the httpd and Tomcat -- what about the
traffic on the "outside" of the httpd?
> We also made sure there is no traffic /users using the web application during the tcp dump taken.
If that were true, you wouldn't have *any* requests. Unless you think
your httpd is simply generating them on its own, in which case I'd be
headed for the door, or dialing the nearest exorcist...
--
Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
twitter: @hassan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: 2 POST requests to underlying Server
Posted by Karthik Nanjangude <ka...@xius-bcgi.com>.
Hi
>> Have you really traced the browser -> server side to see if the duplicate POST request
As I have already said by using the TCP Thread dump using command
"tcpdump -i bond0 -s 1500 -w / tmp / test.pcap "
We are clearly able to see the IP Address of Apache written 2 times POST for the JBOSS ( Tomcat built in) being called with in 12 seconds apart.
We also made sure there is no traffic /users using the web application during the tcp dump taken.
>> Are they really the same, from the same client, with the same content
For simple test case we used 1 simple transaction Page to do the activity
For insertion, but the since 2 request to web server ,we see 2 rows inserted in DB
This has happened in spite of blocking multiple button clicks on jsp page using jscript filter.
>> claim that Apache or mod_jk or Tomcat duplicates a POST
My Observation as per TCP dump command, we clearly see multiple request being sent from Apache to web server.
With regards
KArthik
-----Original Message-----
From: André Warnier [mailto:aw@ice-sa.com]
Sent: Tuesday, August 10, 2010 4:48 PM
To: Tomcat Users List
Subject: Re: 2 POST requests to underlying Server
Karthik Nanjangude wrote:
> Hi
>
>>> (*) do you have any particular reason to use this setting, instead of the default ? Or is
> it just something you copied from some blog page ?
>
>
> 1) I have not copied the same from any Blog , it is as defined
> configuration as is from the N/w team
>
> 2) Where can I fine the default settings for the same ?
In the on-line documentation, at
http://tomcat.apache.org/connectors-doc/reference/workers.html
>
>
> 3) As I have already said We have put a Java script filter to disable
> multiple Clicks for dual request from the Browser ( IE 7+ / FF 3+ )
>
Well, maybe it is not working. Have you really traced the browser -> server side to see
if the duplicate POST request originates there ?
Plus, in your original message, you do not define very clearly what these 2 POST requests
are. Are they really the same, from the same client, with the same content ? how close to
one another do they arrive ?
If it was mod_jk resending the same request after the socket_timeout of 10 s, then the 2
POST requests should be separated by at least 10 s. Are they ?
As someone once said : Extraordinary claims require extraordinary proof.
In other words : you seem to claim that Apache or mod_jk or Tomcat duplicates a POST
request. This is not the behaviour experienced by the vast majority of Apache + mod_jk +
Tomcat installations. So you need data a bit more solid than what you have supplied so
far, before someone will believe that there is another reason than the user clicking twice.
>
>
>
>
> With regards
> karthik
>
>
>
> -----Original Message-----
> From: André Warnier [mailto:aw@ice-sa.com]
> Sent: Tuesday, August 10, 2010 4:10 PM
> To: Tomcat Users List
> Subject: Re: 2 POST requests to underlying Server
>
> Karthik Nanjangude wrote:
>> Hi
>>
>> Spec
>> Java 1.5
>> O/s : Linux
>> APP Server : JBOSS4.2.1 (Tomcat built with)
>> HTTP Server : apache_2.2.11 [ With out SSL ]
>> Mod library : mod_jk-1.2.28-httpd-2.2.X.so
>> LB 1 Apache : 1 JBOSS:Port of application
>>
>>
>> Question : Some times We have observed that on WEB Application ( click on button in jsp )
>> Apache is sending 2 POST requests to underlying JBOSS ( Tomcat server ).
>>
>> Note: We even put a Java script filter to disable multiple Clicks for the page,
>>
>>
>> How we Observed : Via TCP Thread dump using command "tcpdump -i bond0 -s 1500 -w / tmp / test.pcap "
>>
>>
>> Can this configuration "worker.node1.socket_timeout=10" got any thing to do with this multiple request activity?
>>
> Unlikely, but :
>
> 1) simple test : remove this setting, and see if the issue still appears (*)
> (By removing the setting, you make the timeout infinite)
>
> 2) use the mod_jk logging level TRACE, to see exactly what mod_jk is sending to Tomcat
>
> 3) It is unlikely that any Apache or mod_jk or Tomcat component would repeat a POST
> request, because that kind of violates the HTTP RFC. So chances are, that the double POST
> request is /still/ coming from the browser.
>
>
> (*) do you have any particular reason to use this setting, instead of the default ? Or is
> it just something you copied from some blog page ?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 2 POST requests to underlying Server
Posted by André Warnier <aw...@ice-sa.com>.
Karthik Nanjangude wrote:
> Hi
>
>>> (*) do you have any particular reason to use this setting, instead of the default ? Or is
> it just something you copied from some blog page ?
>
>
> 1) I have not copied the same from any Blog , it is as defined
> configuration as is from the N/w team
>
> 2) Where can I fine the default settings for the same ?
In the on-line documentation, at
http://tomcat.apache.org/connectors-doc/reference/workers.html
>
>
> 3) As I have already said We have put a Java script filter to disable
> multiple Clicks for dual request from the Browser ( IE 7+ / FF 3+ )
>
Well, maybe it is not working. Have you really traced the browser -> server side to see
if the duplicate POST request originates there ?
Plus, in your original message, you do not define very clearly what these 2 POST requests
are. Are they really the same, from the same client, with the same content ? how close to
one another do they arrive ?
If it was mod_jk resending the same request after the socket_timeout of 10 s, then the 2
POST requests should be separated by at least 10 s. Are they ?
As someone once said : Extraordinary claims require extraordinary proof.
In other words : you seem to claim that Apache or mod_jk or Tomcat duplicates a POST
request. This is not the behaviour experienced by the vast majority of Apache + mod_jk +
Tomcat installations. So you need data a bit more solid than what you have supplied so
far, before someone will believe that there is another reason than the user clicking twice.
>
>
>
>
> With regards
> karthik
>
>
>
> -----Original Message-----
> From: André Warnier [mailto:aw@ice-sa.com]
> Sent: Tuesday, August 10, 2010 4:10 PM
> To: Tomcat Users List
> Subject: Re: 2 POST requests to underlying Server
>
> Karthik Nanjangude wrote:
>> Hi
>>
>> Spec
>> Java 1.5
>> O/s : Linux
>> APP Server : JBOSS4.2.1 (Tomcat built with)
>> HTTP Server : apache_2.2.11 [ With out SSL ]
>> Mod library : mod_jk-1.2.28-httpd-2.2.X.so
>> LB 1 Apache : 1 JBOSS:Port of application
>>
>>
>> Question : Some times We have observed that on WEB Application ( click on button in jsp )
>> Apache is sending 2 POST requests to underlying JBOSS ( Tomcat server ).
>>
>> Note: We even put a Java script filter to disable multiple Clicks for the page,
>>
>>
>> How we Observed : Via TCP Thread dump using command "tcpdump -i bond0 -s 1500 -w / tmp / test.pcap "
>>
>>
>> Can this configuration "worker.node1.socket_timeout=10" got any thing to do with this multiple request activity?
>>
> Unlikely, but :
>
> 1) simple test : remove this setting, and see if the issue still appears (*)
> (By removing the setting, you make the timeout infinite)
>
> 2) use the mod_jk logging level TRACE, to see exactly what mod_jk is sending to Tomcat
>
> 3) It is unlikely that any Apache or mod_jk or Tomcat component would repeat a POST
> request, because that kind of violates the HTTP RFC. So chances are, that the double POST
> request is /still/ coming from the browser.
>
>
> (*) do you have any particular reason to use this setting, instead of the default ? Or is
> it just something you copied from some blog page ?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: 2 POST requests to underlying Server
Posted by Karthik Nanjangude <ka...@xius-bcgi.com>.
Hi
>>(*) do you have any particular reason to use this setting, instead of the default ? Or is
it just something you copied from some blog page ?
1) I have not copied the same from any Blog , it is as defined
configuration as is from the N/w team
2) Where can I fine the default settings for the same ?
3) As I have already said We have put a Java script filter to disable
multiple Clicks for dual request from the Browser ( IE 7+ / FF 3+ )
With regards
karthik
-----Original Message-----
From: André Warnier [mailto:aw@ice-sa.com]
Sent: Tuesday, August 10, 2010 4:10 PM
To: Tomcat Users List
Subject: Re: 2 POST requests to underlying Server
Karthik Nanjangude wrote:
> Hi
>
> Spec
> Java 1.5
> O/s : Linux
> APP Server : JBOSS4.2.1 (Tomcat built with)
> HTTP Server : apache_2.2.11 [ With out SSL ]
> Mod library : mod_jk-1.2.28-httpd-2.2.X.so
> LB 1 Apache : 1 JBOSS:Port of application
>
>
> Question : Some times We have observed that on WEB Application ( click on button in jsp )
> Apache is sending 2 POST requests to underlying JBOSS ( Tomcat server ).
>
> Note: We even put a Java script filter to disable multiple Clicks for the page,
>
>
> How we Observed : Via TCP Thread dump using command "tcpdump -i bond0 -s 1500 -w / tmp / test.pcap "
>
>
> Can this configuration "worker.node1.socket_timeout=10" got any thing to do with this multiple request activity?
>
Unlikely, but :
1) simple test : remove this setting, and see if the issue still appears (*)
(By removing the setting, you make the timeout infinite)
2) use the mod_jk logging level TRACE, to see exactly what mod_jk is sending to Tomcat
3) It is unlikely that any Apache or mod_jk or Tomcat component would repeat a POST
request, because that kind of violates the HTTP RFC. So chances are, that the double POST
request is /still/ coming from the browser.
(*) do you have any particular reason to use this setting, instead of the default ? Or is
it just something you copied from some blog page ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 2 POST requests to underlying Server
Posted by André Warnier <aw...@ice-sa.com>.
Karthik Nanjangude wrote:
> Hi
>
> Spec
> Java 1.5
> O/s : Linux
> APP Server : JBOSS4.2.1 (Tomcat built with)
> HTTP Server : apache_2.2.11 [ With out SSL ]
> Mod library : mod_jk-1.2.28-httpd-2.2.X.so
> LB 1 Apache : 1 JBOSS:Port of application
>
>
> Question : Some times We have observed that on WEB Application ( click on button in jsp )
> Apache is sending 2 POST requests to underlying JBOSS ( Tomcat server ).
>
> Note: We even put a Java script filter to disable multiple Clicks for the page,
>
>
> How we Observed : Via TCP Thread dump using command "tcpdump -i bond0 -s 1500 -w / tmp / test.pcap "
>
>
> Can this configuration "worker.node1.socket_timeout=10" got any thing to do with this multiple request activity?
>
Unlikely, but :
1) simple test : remove this setting, and see if the issue still appears (*)
(By removing the setting, you make the timeout infinite)
2) use the mod_jk logging level TRACE, to see exactly what mod_jk is sending to Tomcat
3) It is unlikely that any Apache or mod_jk or Tomcat component would repeat a POST
request, because that kind of violates the HTTP RFC. So chances are, that the double POST
request is /still/ coming from the browser.
(*) do you have any particular reason to use this setting, instead of the default ? Or is
it just something you copied from some blog page ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 2 POST requests to underlying Server
Posted by Rainer Jung <ra...@kippdata.de>.
On 10.08.2010 09:38, Karthik Nanjangude wrote:
> Hi
>
> Spec
> Java 1.5
> O/s : Linux
> APP Server : JBOSS4.2.1 (Tomcat built with)
> HTTP Server : apache_2.2.11 [ With out SSL ]
> Mod library : mod_jk-1.2.28-httpd-2.2.X.so
> LB 1 Apache : 1 JBOSS:Port of application
>
>
> Question : Some times We have observed that on WEB Application ( click on button in jsp )
> Apache is sending 2 POST requests to underlying JBOSS ( Tomcat server ).
>
> Note: We even put a Java script filter to disable multiple Clicks for the page,
>
>
> How we Observed : Via TCP Thread dump using command "tcpdump -i bond0 -s 1500 -w / tmp / test.pcap "
>
>
> Can this configuration "worker.node1.socket_timeout=10" got any thing to do with this multiple request activity?
I'm a bit afraid that everyone who was arguing against the above claim
will jump at me but still ...
It could be the missing "recovery_options" setting. See
http://tomcat.apache.org/connectors-doc/reference/workers.html
and do also read a bit about timeouts at
http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html
If you want to disallow resending any requests in case of communication
errors, you need to set recovery_options to "7", if you want to allow
resending for HEAD and GET, you can use "31".
As others have mentioned we could easily see from your jk log files with
increased log level, whether resending because of errors happens here.
Since you have a 10 second socket_timeout and the two requests are 12
seconds apart, this is likely to happen (10 seconds timeout plus 2
seconds connection draining).
You might want to have a close look at the example config contained in
the mod_jk 1.2.30 source download, which looks better for production
than you config above and is well commented. Note that although that
config uses many timeouts, it does *not* use the general "socket_timeout".
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org