| Anonymous | Login | Signup for a new account | 04-20-2024 00:50 PDT |
| Main | My View | View Issues | Change Log | Docs |
| Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||||
| ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||||
| 0002279 | [Resin] | minor | always | 12-28-07 10:58 | 01-02-08 10:44 | ||||
| Reporter | sam | View Status | public | ||||||
| Assigned To | ferg | ||||||||
| Priority | urgent | Resolution | fixed | ||||||
| Status | closed | Product Version | 3.1.4 | ||||||
| Summary | 0002279: load-balance-recover-time | ||||||||
| Description |
(rep by A Balandran) This is in regards to the load-balance-recover-time setting. We have ours set to 0s. This would make the server available at all times, even after an error. We are seeing cases we a new request comes in after an unexpected end of file error that are being sent to the backup backend server. Here is a snippet of the logs that shows this case: -- Request that fails [14:35:10.937] {http-web-443-555} load balance [web-tier->app-crusader:18849] URL /cwsreq [14:35:10.937] {http-web-443-555} load balance [web-tier->app-crusader:18849] Host: ssl.4aabbcc.com [14:35:10.937] {http-web-443-555} load balance [web-tier->app-crusader:18849] Accept: */* [14:35:10.937] {http-web-443-555} load balance [web-tier->app-crusader:18849] Cookie: JSESSIONID=bda0mO0Vzhl3t4HuPVDCr [14:35:10.937] {http-web-443-555} load balance [web-tier->app-crusader:18849] Content-type: text/xml [14:35:10.937] {http-web-443-555} load balance [web-tier->app-crusader:18849] Content-Length: 8937 [14:35:10.937] {http-web-443-555} load balance [web-tier->app-crusader:18849] unexpected end of file [14:35:10.937] {http-web-443-555} close ClusterStream[[web-tier->app-crusader:18849]] ---- New Request [14:35:11.556] {http-web-443-555} load-balance for session bda0mO0Vzhl3t4HuPVDCr primary web-tier->app-crusader connection failed. [14:35:11.556] {http-web-443-555} connect ClusterStream[[web-tier->app-undercity:18994]] [14:35:11.556] {http-web-443-555} load balance [web-tier->app-undercity:18994] URL /cwsreq [14:35:11.556] {http-web-443-555} load balance [web-tier->app-undercity:18994] Host: ssl.4aabbcc.com [14:35:11.556] {http-web-443-555} load balance [web-tier->app-undercity:18994] Accept: */* [14:35:11.556] {http-web-443-555} load balance [web-tier->app-undercity:18994] Cookie: JSESSIONID=bda0mO0Vzhl3t4HuPVDCr [14:35:11.556] {http-web-443-555} load balance [web-tier->app-undercity:18994] Content-type: text/xml [14:35:11.556] {http-web-443-555} load balance [web-tier->app-undercity:18994] Content-Length: 139 [14:35:11.567] {http-web-443-555} load balance [web-tier->app-undercity:18994] 200 OK [14:35:11.567] {http-web-443-555} load balance [web-tier->app-undercity:18994] M cpu-load:0 [14:35:11.567] {http-web-443-555} load balance [web-tier->app-undercity:18994] D: 119 [14:35:11.567] {http-web-443-555} load balance [web-tier->app-undercity:18994] Q (keepalive) Why does the second request fail to connect to the backend that just received the error? I don't see any type of error, so I assumed this is the load balancer marking the failed server as bad. But this should be ignored with 0s load-balance-recover-time, correct? |
||||||||
| Additional Information | |||||||||
| Attached Files | |||||||||
|
|
|||||||||
 Relationships |
|
|
Notes |
|
|
(0002610) ferg 01-02-08 10:44 |
server/269w |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 12-28-07 10:58 | sam | New Issue | |
| 01-02-08 10:44 | ferg | Note Added: 0002610 | |
| 01-02-08 10:44 | ferg | Assigned To | => ferg |
| 01-02-08 10:44 | ferg | Status | new => closed |
| 01-02-08 10:44 | ferg | Resolution | open => fixed |
| 01-02-08 10:44 | ferg | Fixed in Version | => 3.1.5 |
| Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
29 total queries executed. 26 unique queries executed. |  |
