Skip to main content
We’ve updated our Terms of Service. A new AI Addendum clarifies how Stack Overflow utilizes AI interactions.
Server Fault

Return to Answer

deleted 24 characters in body
Source Link
Mike Purcell
Mike Purcell
  • 1.8k
  • 7
  • 35
  • 56

If you try calling addServers more than once against the same instance you should see unexpected behavior, for me it was a bad gateway due to: " upstream prematurely closed connection while reading response header from upstream". So there was some internal mechanism causing PHP to fail out, although I don't know why specifically, as no errors showed up in the error log.

In my testing I had multiple cache nodes which were all running for test 1, then for subsequent tests, I switched some cache nodes off and on, then finally all off (to test degradation). The only noticeable difference was that after taking a node down, or adding a node back (via daemon restart), my logged in session would be logged out, which makes sense, as the cached data is no longer available on expected server. However subsequent requests after logging back in demonstrated behavior expected behavior while logged in, which was also expected, because the session data was written to cache nodes available at the time of the request.

If you try calling addServers more than once against the same instance you should see unexpected behavior, for me it was a bad gateway due to: " upstream prematurely closed connection while reading response header from upstream". So there was some internal mechanism causing PHP to fail out, although I don't know why specifically as no errors showed up in the error log.

In my testing I had multiple cache nodes which were all running for test 1, then for subsequent tests, I switched some cache nodes off and on, then finally all off (to test degradation). The only noticeable difference was that after taking a node down, or adding a node back (via daemon restart), my logged in session would be logged out, which makes sense, as the cached data is no longer available on expected server. However subsequent requests after logging back in demonstrated behavior expected while logged in, which was also expected, because the session data was written to cache nodes available at the time of the request.

If you try calling addServers more than once against the same instance you should see unexpected behavior, for me it was a bad gateway due to: " upstream prematurely closed connection while reading response header from upstream". So there was some internal mechanism causing PHP to fail out, although I don't know why specifically, as no errors showed up in the error log.

In my testing I had multiple cache nodes which were all running for test 1, then for subsequent tests, I switched some cache nodes off and on, then finally all off (to test degradation). The only noticeable difference was that after taking a node down, or adding a node back (via daemon restart), my logged in session would be logged out, which makes sense, as the cached data is no longer available on expected server. However subsequent requests after logging back in demonstrated expected behavior while logged in, because the session data was written to cache nodes available at the time of the request.

added 497 characters in body
Source Link
Mike Purcell
Mike Purcell
  • 1.8k
  • 7
  • 35
  • 56

Finally, I have a working solution in place, and sharing with others in case they encounter the same sitch. The basis for my solution came from this post, as soon as I saw the $testInstance and $realInstance it dawned on me, use the test instance to determine which servers are available, then add known good servers to the real instance. You might be asking yourself, why not just call addServers twice against the same instance, the answer? You can't.

If you try calling addServers more than once against the same instance you should see unexpected behavior, for me it was a bad gateway due to: " upstream prematurely closed connection while reading response header from upstream". So there was some internal mechanism causing PHP to fail out, although I don't know why specifically as no errors showed up in the error log.

Rather than make explicit connect calls as the author did, I opted to use the available getStats() call, and check for a pid.

Finally, I have a working solution in place, and sharing with others in case they encounter the same sitch. The basis for my solution came from this post, as soon as I saw the $testInstance and $realInstance it dawned on me, use the test instance to determine which servers are available, then add known good servers to the real instance. Rather than make explicit connect calls as the author did, I opted to use the available getStats() call, and check for a pid.

Finally, I have a working solution in place, and sharing with others in case they encounter the same sitch. The basis for my solution came from this post, as soon as I saw the $testInstance and $realInstance it dawned on me, use the test instance to determine which servers are available, then add known good servers to the real instance. You might be asking yourself, why not just call addServers twice against the same instance, the answer? You can't.

If you try calling addServers more than once against the same instance you should see unexpected behavior, for me it was a bad gateway due to: " upstream prematurely closed connection while reading response header from upstream". So there was some internal mechanism causing PHP to fail out, although I don't know why specifically as no errors showed up in the error log.

Rather than make explicit connect calls as the author did, I opted to use the available getStats() call, and check for a pid.

Source Link
Mike Purcell
Mike Purcell
  • 1.8k
  • 7
  • 35
  • 56

Finally, I have a working solution in place, and sharing with others in case they encounter the same sitch. The basis for my solution came from this post, as soon as I saw the $testInstance and $realInstance it dawned on me, use the test instance to determine which servers are available, then add known good servers to the real instance. Rather than make explicit connect calls as the author did, I opted to use the available getStats() call, and check for a pid.

Working snippet:

$cacheReal = new Memcached; $cacheTest = new Memcached; if (count($cacheTest->getServerList()) < 1) { $knownGoodServers = array(); $serversToAdd = array(); foreach ($servers as $server) { $serversToAdd[] = array($server, $port); } $cacheTest->addServers($serversToAdd); foreach ($cacheTest->getStats() as $server => $stats) { // Test if server is actually available if ((false === Hobis_Api_Array_Package::populatedKey('pid', $stats)) || ($stats['pid'] < 0)) { continue; } $knownGoodServers[] = $server; } // It is possible that entire cache pool took a dump if (true === Hobis_Api_Array_Package::populated($knownGoodServers)) { $serversToAdd = array(); foreach ($knownGoodServers as $server) { list($host, $port) = array_map('trim', explode(':', $server)); $serversToAdd[] = array($host, (int) $port); } if (true === Hobis_Api_Array_Package::populated($serversToAdd)) { $cacheReal->addServers($serversToAdd); } } }

In my testing I had multiple cache nodes which were all running for test 1, then for subsequent tests, I switched some cache nodes off and on, then finally all off (to test degradation). The only noticeable difference was that after taking a node down, or adding a node back (via daemon restart), my logged in session would be logged out, which makes sense, as the cached data is no longer available on expected server. However subsequent requests after logging back in demonstrated behavior expected while logged in, which was also expected, because the session data was written to cache nodes available at the time of the request.