TPAC added content connect is not non-blocking
Bug #1055648 reported by
Bill Erickson
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Evergreen |
Fix Released
|
Medium
|
Unassigned | ||
Bug Description
Evergreen 2.3+
If TPAC is unable to route added content requests to its own top-level apache hostname, then the IO::Socket connect call will block for many seconds (21 in testing) for each type of added content lookup. In such cases, a record detail page can take minutes to load (if the record has an isbn/upc).
This patch ensures that even if tpac is unable to route the requests, a record detail page will take a few seconds to load at the most.
working => user/berick/
* As a possible future enhancement, TPAC added content lookups could be configured to talk to the same brick the request is running on or some other configured hostname.
Revision history for this message
| Bill Erickson (berick) wrote | #1 |
Revision history for this message
| Michael Peters (mrpeters) wrote | #2 |
| Changed in evergreen: | |
| status: | New → Confirmed |
| importance: | Undecided → Medium |
Revision history for this message
| Lebbeous Fogle-Weekley (lebbeous) wrote | #3 |
| Changed in evergreen: | |
| status: | Confirmed → Fix Committed |
| Changed in evergreen: | |
| status: | Fix Committed → Fix Released |
To post a comment you must log in.
Pushed a follow-up commit that forces the AC lookups to run against the local server instead of requiring that each apache server be able to route out to the main top-level hostname.