Openbravo Issue Tracking System - Retail Modules | |||||
View Issue Details | |||||
ID | Project | Category | View Status | Date Submitted | Last Update |
0040111 | Retail Modules | StoreServer | public | 2019-02-03 10:41 | 2019-02-06 14:35 |
Reporter | mtaal | ||||
Assigned To | mtaal | ||||
Priority | normal | Severity | critical | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Platform | OS | 5 | OS Version | ||
Product Version | |||||
Target Version | Fixed in Version | ||||
Merge Request Status | |||||
Review Assigned To | |||||
OBNetwork customer | No | ||||
Support ticket | |||||
Regression level | |||||
Regression date | |||||
Regression introduced in release | |||||
Regression introduced by commit | |||||
Triggers an Emergency Pack | No | ||||
Summary | 0040111: SS should store/use all central cookies to ensure correct working in combination with load balancer | ||||
Description | Problem description - the store server in online mode is like a proxy, it forwards (almost) all requests to the central server and returns the response. - when calling central the store server will try to use always the same session on central for a user, so webpos user A will have its own http session on the store server and it's own on the central server. - the store server does this by keeping the session id cookie from the central server in memory (in its http session for the user A), so when user A does a next request from the WebPOS it will take that cookie and include it in the request. - this works fine in our environments without loadbalancer - BUT has a load balancer with sticky sessions - the loadbalancer implements sticky session by sending back a special cookie, so when it receives a new request with this cookie it assigns the request to the same node as before, which has the correct http session ready to be used - the store server however does not keep this special cookie, therefore requests through the store server can be and are assigned to different nodes by the loadbalancer, recreating sessions there. This issue was also there last year in november we/I think. The fix will be to store all the cookies (not only JSESSIONID). I have worked on a fix which works on my dev laptop, but will test it some more tomorrow morning. | ||||
Steps To Reproduce | See Description | ||||
Proposed Solution | Store all cookies | ||||
Additional Information | |||||
Tags | No tags attached. | ||||
Relationships | |||||
Attached Files | |||||
Issue History | |||||
Date Modified | Username | Field | Change | ||
2019-02-03 10:41 | mtaal | New Issue | |||
2019-02-03 10:41 | mtaal | Assigned To | => mtaal | ||
2019-02-03 10:41 | mtaal | OBNetwork customer | => No | ||
2019-02-03 10:41 | mtaal | Triggers an Emergency Pack | => No | ||
2019-02-03 10:42 | hgbot | Checkin | |||
2019-02-03 10:42 | hgbot | Note Added: 0109460 | |||
2019-02-03 10:42 | hgbot | Status | new => resolved | ||
2019-02-03 10:42 | hgbot | Resolution | open => fixed | ||
2019-02-03 10:42 | hgbot | Fixed in SCM revision | => http://code.openbravo.com/erp/pmods/org.openbravo.mobile.core/rev/d671a6a95bb9d0565890e52ccfa4dac3aa4cb2a0 [^] | ||
2019-02-06 14:35 | AugustoMauch | Note Added: 0109633 | |||
2019-02-06 14:35 | AugustoMauch | Status | resolved => closed |
Notes | |||||
|
|||||
|
|
||||
|
|||||
|
|