Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BUGFIX: Make cache application identifier configurable #1457

Merged
merged 5 commits into from Nov 23, 2018

Conversation

Projects
4 participants
@kitsunet
Copy link
Member

kitsunet commented Nov 21, 2018

In multiple permutations, we tried to fix problems with cache identifier
uniqueness in cache backends that are shared like apcu or memcache.
In earlier days it included the PHP_SAPI and then in more recent times
the context and root path. With the refactoring of caches, these two
became the hardcoded applicationIdentifier which can be used by
any backend to add more specificity to cache identifiers.

It turns out that the root path doesn't work well for some environments
and can result in bugs when used with eg. the PdoBackend and a
deployment that changes the root path (typical Surf or Deployer).

The only backward compatible way to fix this was to make the
applicationIdentifier configurable with a default that matches the
previously hardcoded values. That way nothing changes in existing
installations but if the bug appears it can be easily fixed.

BUGFIX: Make cache application identifier configurable
In multiple permutations we tried to fix problems with cache identifier
uniqueness in cache backends that are shared like apcu or memcache.
In earlier days it included the PHP_SAPI and then in more recent times
the context and root path. With the refactoring of caches these two
became the hardcoded `applicationIdentifier` which can be used by
any backend to add more specifity to cache identifiers.
It turns out that he root path doesn't work well for some enviroments
and can result in bugs when used with eg. the PdoBackend and a
deployment that chnages the root path (typical Surf or Deployer).
The only backwards compatible way to fix this was to make the
applicationIdentifier configurable with a default that matches the
previously hardcoded values. That way nothing changes in existing
installations but if the bug appears it can be easily fixed.

@jonnitto jonnitto added this to To do in Neos 4.2 & Flow 5.2 Release Board via automation Nov 21, 2018

@jonnitto jonnitto moved this from To do to Needs review in Neos 4.2 & Flow 5.2 Release Board Nov 21, 2018

@jonnitto

This comment has been minimized.

Copy link
Member

jonnitto commented Nov 21, 2018

@kitsunet The tests are still failing…

@kitsunet

This comment has been minimized.

Copy link
Member Author

kitsunet commented Nov 21, 2018

Yep, yep, I see. during rebasing I coudln't run the tests so I hoped it would work, but I kind of expected that functional tests might also have a problem...

kitsunet added some commits Nov 21, 2018

@kdambekalns

This comment has been minimized.

Copy link
Member

kdambekalns commented Nov 22, 2018

Amended documentation. The failure comes from the compile step and is caused by the arguments in the object configuration being empty. The reason seems to be that the factory configuration is used, according to the configurationSourceHint seen below.:

/…/Packages/Framework/Neos.Flow/Classes/ObjectManagement/Configuration/ConfigurationBuilder.php:402:
class Neos\Flow\ObjectManagement\Configuration\Configuration#1482 (12) {
  protected $objectName =>
  string(32) "Neos\Cache\CacheFactoryInterface"
  protected $className =>
  string(28) "Neos\Flow\Cache\CacheFactory"
  protected $packageKey =>
  string(9) "Neos.Flow"
  protected $factoryObjectName =>
  string(0) ""
  protected $factoryMethodName =>
  string(6) "create"
  protected $scope =>
  int(2)
  protected $arguments =>
  array(0) {
  }
  protected $properties =>
  array(0) {
  }
  protected $autowiring =>
  int(1)
  protected $lifecycleInitializationMethodName =>
  string(16) "initializeObject"
  protected $lifecycleShutdownMethodName =>
  string(14) "shutdownObject"
  protected $configurationSourceHint =>
  string(92) "configuration of package Neos.Flow, definition for object "Neos\Cache\CacheFactoryInterface""
}
Could not autowire required constructor argument $applicationIdentifier for singleton class Neos\Flow\Cache\CacheFactory.
Check the type hint of that argument and your Objects.yaml configuration.

  Type: Neos\Flow\ObjectManagement\Exception\UnresolvedDependenciesException
  Code: 1298629392
  File: Packages/Framework/Neos.Flow/Classes/ObjectManagement/Configuration/Configu
        rationBuilder.php
  Line: 403

Open Data/Logs/Exceptions/20181122082231a876f8.txt for a full stack trace.
properties:
logger:
object:
factoryObjectName: Neos\Flow\Log\PsrLoggerFactoryInterface

This comment has been minimized.

@kdambekalns

kdambekalns Nov 22, 2018

Member

No such thing as Neos\Flow\Log\PsrLoggerFactoryInterface in Flow 4.3

@kdambekalns

This comment has been minimized.

Copy link
Member

kdambekalns commented Nov 22, 2018

Ok, it get's shady here… when changing Objects.yaml and instead of 3 using 2 as argument index, the var_dump() suddenly emits the correct setup… as in:

/…/Packages/Framework/Neos.Flow/Classes/ObjectManagement/Configuration/ConfigurationBuilder.php:402:
class Neos\Flow\ObjectManagement\Configuration\Configuration#1408 (12) {
  protected $objectName =>
  string(28) "Neos\Flow\Cache\CacheFactory"
  protected $className =>
  string(28) "Neos\Flow\Cache\CacheFactory"
  protected $packageKey =>
  string(9) "Neos.Flow"
  protected $factoryObjectName =>
  string(0) ""
  protected $factoryMethodName =>
  string(6) "create"
  protected $scope =>
  int(2)
  protected $arguments =>
  array(2) {
    [1] =>
    class Neos\Flow\ObjectManagement\Configuration\ConfigurationArgument#1465 (4) {
      protected $index =>
      int(1)
      protected $value =>
      string(17) "Neos.Flow.context"
      protected $type =>
      int(2)
      protected $autowiring =>
      int(1)
    }
    [2] =>
    class Neos\Flow\ObjectManagement\Configuration\ConfigurationArgument#1466 (4) {
      protected $index =>
      int(2)
      protected $value =>
      string(37) "Neos.Flow.cache.applicationIdentifier"
      protected $type =>
      int(2)
      protected $autowiring =>
      int(1)
    }
  }
  protected $properties =>
  array(0) {
  }
  protected $autowiring =>
  int(1)
  protected $lifecycleInitializationMethodName =>
  string(16) "initializeObject"
  protected $lifecycleShutdownMethodName =>
  string(14) "shutdownObject"
  protected $configurationSourceHint =>
  string(88) "configuration of package Neos.Flow, definition for object "Neos\Flow\Cache\CacheFactory""
}
TASK: Adjust Objects.yaml even more to circumvent autowiring errors
For some reason the arguments need to be defined for "both objects".

The logger factory does not need to be configured.
@kdambekalns

This comment has been minimized.

Copy link
Member

kdambekalns commented Nov 22, 2018

That fixes it, @kitsunet – but I am not entirely sure why. Could it be that there are places where the cache factory is fetched by different names?

Changed it myself, needs re-review

@kitsunet kitsunet changed the base branch from 4.3 to 5.0 Nov 22, 2018

@kitsunet kitsunet changed the base branch from 5.0 to 4.3 Nov 22, 2018

@kitsunet
Copy link
Member Author

kitsunet left a comment

Alright, that works for me. I guess I should do the upmerges and fix the object configuration along the way. In 5.0 AFAIK the autowiring check was changed to not cause this kind of problem so the whole config can be removed again, as in my original change on master.

@daniellienert
Copy link
Member

daniellienert left a comment

Great! Thanks for adding the hint to the documentation.

@jonnitto jonnitto merged commit 909fe01 into neos:4.3 Nov 23, 2018

2 checks passed

continuous-integration/styleci/pr The analysis has passed
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

Neos 4.2 & Flow 5.2 Release Board automation moved this from Needs review to Done Nov 23, 2018

@albe albe deleted the kitsunet:task/fix-application-identifier-43 branch Nov 23, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.