Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.lang.php > #3671 > unrolled thread

Klassendefinition, wo?

Back to article view | Back to de.comp.lang.php

Contents

  Klassendefinition, wo? Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-02-03 21:01 +0000
    Re: Klassendefinition, wo? k@rl.pflaesterer.de (Karl Pflästerer) - 2016-02-04 07:00 +0100
      Re: Klassendefinition, wo? Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-02-07 12:44 +0000
        Re: Klassendefinition, wo? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-09 00:13 +0100
          Re: Klassendefinition, wo? Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-02-09 09:37 +0000
            Re: Klassendefinition, wo? "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-02-09 14:05 +0100
              Re: Klassendefinition, wo? Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-02-09 14:39 +0000
                Re: Klassendefinition, wo? "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-02-09 17:03 +0100
                  Re: Klassendefinition, wo? Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-02-09 19:35 +0000
                    Re: Klassendefinition, wo? Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-02-11 18:32 +0000
                      Re: Klassendefinition, wo? "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2016-02-13 13:36 +0100
                        OpCache (was: Klassendefinition, wo?) Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-02-15 11:00 +0000
            Re: Klassendefinition, wo? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-09 20:02 +0100
              Re: Klassendefinition, wo? Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-02-09 19:33 +0000
                Zitierstil (was: Klassendefinition, wo?) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-09 22:25 +0100
                  Re: Zitierstil (was: Klassendefinition, wo?) eulenspiegel.till@firemail.de - 2016-02-11 06:56 -0800

#3671 — Klassendefinition, wo?

Mein System beglückte mich heute etwas unerwartet mit der Meldung:

| Cannot declare class Page_Webshop_Search, because the name is already in use

Das ganze passiert bei einem:

| require_once 'search.php';

...welches aus verschiedenen Gründen den sonst in Verwendung befindlichen
Autoloader umgeht. Zunächst fand ich die Meldung seltsam, weil ich
konsequent require_once verwende, und da doch eigentlich nichts doppelt
geladen werden sollte - das wäre dann aber "Cannot REdeclare class", und
tatsächlich, wenn ich vor der Klassendefinition in search.php ein "die;"
setze, ändert sich gar nichts, das File wird also gar nicht geladen.

Nun habe ich ein grep über den gesamten Quelltext gemacht, aber nichts
anderes gefunden, was "page_webshop_search" heisst. Wie um alles in der
Welt bekomme ich jetzt heraus, *woher* der Name "already in use" ist und
als was er "in use" ist?

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Die Kraft, Frieden zu spenden - Stefan: tatschen, welch kaputtes Verlangen!
(Sloganizer)

[toc] | [next] | [standalone]

#3672

Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) writes:

> Mein System beglückte mich heute etwas unerwartet mit der Meldung:
>
> | Cannot declare class Page_Webshop_Search, because the name is already in use
>
> Das ganze passiert bei einem:
>
> | require_once 'search.php';
>
> ...welches aus verschiedenen Gründen den sonst in Verwendung befindlichen
> Autoloader umgeht. Zunächst fand ich die Meldung seltsam, weil ich
> konsequent require_once verwende, und da doch eigentlich nichts doppelt
> geladen werden sollte - das wäre dann aber "Cannot REdeclare class", und
> tatsächlich, wenn ich vor der Klassendefinition in search.php ein "die;"
> setze, ändert sich gar nichts, das File wird also gar nicht geladen.
>
> Nun habe ich ein grep über den gesamten Quelltext gemacht, aber nichts
> anderes gefunden, was "page_webshop_search" heisst. Wie um alles in der
> Welt bekomme ich jetzt heraus, *woher* der Name "already in use" ist und
> als was er "in use" ist?

Bist du sicher, dass dein Autoloader nicht doch gelaufen war? Hast du
Opcache?

Diese Fehlermeldung bekommt man mit Namespaces hin.

php -a
Interactive shell

php > namespace n1 { class k1 {}}
php > class k1 {}
php > use n1\k1;
PHP Fatal error:  Cannot use n1\k1 as k1 because the name is already in use in php shell code on line 1

Fatal error: Cannot use n1\k1 as k1 because the name is already in use in php shell code on line 1
php > 

[toc] | [prev] | [next] | [standalone]

#3673

On Thu, 04 Feb 2016 07:00:53 Karl Pflästerer wrote:
> Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) writes:
> > Mein System beglückte mich heute etwas unerwartet mit der Meldung:

> > | Cannot declare class Page_Webshop_Search, because the name is already in use

> > Das ganze passiert bei einem:

> > | require_once 'search.php';

> Bist du sicher, dass dein Autoloader nicht doch gelaufen war? Hast du
> Opcache?

Der Autoloader ist definitiv nicht gelaufen, nein.

Opcache wird (mit PHP7) verwendet, ja.
 
> Diese Fehlermeldung bekommt man mit Namespaces hin. [...]
> PHP Fatal error:  Cannot use n1\k1 as k1 because the name is already in
> use in php shell code on line 1

Das ist allerdings nicht die gleiche Fehlermeldung ("Cannot use" vs.
"Cannot declare").

Vermutlich war Opcache daran schuld - das ist nur am Produktivsystem
reproduzierbar aufgetreten, daher konnte ich erst jetzt am Wochenende
wieder damit herumspielen. In der Zwischenzeit gab es einen Apache-Neustart
wegen Security Fixes, und jetzt lässt sich das Verhalten nicht mehr
nachvollziehen.

Wobei ich mich durchaus immer noch frage, was genau die Probleme verursacht
hat. Ich möchte ja keinesfalls, dass sie (mehr oder minder aus heiterem
Himmel) neuerlich auftreten.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan. Für pampische Matratzen in pazifistischen Galaxien!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#3674

Stefan Froehlich wrote:

> On Thu, 04 Feb 2016 07:00:53 Karl Pflästerer wrote:
>> Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) writes:
>> > Mein System beglückte mich heute etwas unerwartet mit der Meldung:
>> > | Cannot declare class Page_Webshop_Search, because the name is already
>> > | in use
>> >
>> > Das ganze passiert bei einem:
>> >
>> > | require_once 'search.php';
>> 
>> Bist du sicher, dass dein Autoloader nicht doch gelaufen war? Hast du
>> Opcache?
> 
> Der Autoloader ist definitiv nicht gelaufen, nein.

Gemäss Google-Suchergebnissen für die Fehlermeldung unwahrscheinlich.

>> Diese Fehlermeldung bekommt man mit Namespaces hin. [...]
>> PHP Fatal error:  Cannot use n1\k1 as k1 because the name is already in
>> use in php shell code on line 1
> 
> Das ist allerdings nicht die gleiche Fehlermeldung ("Cannot use" vs.
> "Cannot declare").
  ^^^^^^^^^^^^^^^^
> […] In der Zwischenzeit gab es einen Apache-Neustart wegen Security Fixes,
> und jetzt lässt sich das Verhalten nicht mehr nachvollziehen.
> 
> Wobei ich mich durchaus immer noch frage, was genau die Probleme
> verursacht hat. Ich möchte ja keinesfalls, dass sie (mehr oder minder aus
> heiterem Himmel) neuerlich auftreten.

UTSL.

-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#3675

On Tue, 09 Feb 2016 00:13:35 Thomas 'PointedEars' Lahn wrote:
> >> > | Cannot declare class Page_Webshop_Search, because the name is already
> >> > | in use

> >> > Das ganze passiert bei einem:

> >> > | require_once 'search.php';

> >> Bist du sicher, dass dein Autoloader nicht doch gelaufen war?
> >> Hast du Opcache?

> > Der Autoloader ist definitiv nicht gelaufen, nein.
 
> Gemäss Google-Suchergebnissen für die Fehlermeldung
> unwahrscheinlich.

Naja, ich hatte testhalber ein "die;" mit dem entsprechenden
Dateinamen in den (einzigen relevanten) Autoloader gesetzt. Beim
oben zitierten Ladeversuch ist er dann auch brav verendet, aber auch
eben erst dort.

Das war für mich Indiz genug, um derartiges zu behaupten.

> > Wobei ich mich durchaus immer noch frage, was genau die Probleme
> > verursacht hat. Ich möchte ja keinesfalls, dass sie (mehr oder
> > minder aus heiterem Himmel) neuerlich auftreten.
 
> UTSL.

Scherzkeks. Wenn *mein* Source die Probleme nicht reproduzierbar
auftreten lässt (sie kamen unmotiviert und verschwanden nach einem
Apache-Reload), dann bleibt nur der PHP-Source. Und das ist, ohne
konkreten, reproduzierbaren Anlassfall wohl eher aussichtslos (und
selbst mit Anlassfall vermutlich beyond my scope).

Servus,
   Stefan 

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - Für die Kennerin von Welt: Werben solange es gerbt!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#3676

Stefan Froehlich schrieb:

> On Tue, 09 Feb 2016 00:13:35 Thomas 'PointedEars' Lahn wrote:
>  
>> UTSL.
> 
> Scherzkeks. Wenn *mein* Source die Probleme nicht reproduzierbar
> auftreten lässt (sie kamen unmotiviert und verschwanden nach einem
> Apache-Reload), dann bleibt nur der PHP-Source. Und das ist, ohne
> konkreten, reproduzierbaren Anlassfall wohl eher aussichtslos (und
> selbst mit Anlassfall vermutlich beyond my scope).

Eine Github-Suche nach der Fehlermeldung bringt nur zwei wirkliche
Treffer im aktuellen Master. Eine davon wird von class_alias() geworfen,
die andere von OPcache. Du könntest ja mal über die Quellen der von Dir
verwendeten PHP-Version greppen – vielleicht lässt sich das Problem ja
so eingrenzen. (Und ja, ich könnte mir vorstellen, dass es sich um einen
Bug in OPcache handelt.)

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#3677

On Tue, 09 Feb 2016 14:05:46 Christoph M. Becker wrote:
> Eine Github-Suche nach der Fehlermeldung bringt nur zwei wirkliche
> Treffer im aktuellen Master. Eine davon wird von class_alias() geworfen,
> die andere von OPcache. Du könntest ja mal über die Quellen der von Dir
> verwendeten PHP-Version greppen – vielleicht lässt sich das Problem ja
> so eingrenzen. (Und ja, ich könnte mir vorstellen, dass es sich um einen
> Bug in OPcache handelt.)

Muss dann wohl, weil class_alias() habe ich in meinem Leben bisher
noch nicht verwendet.

Jetzt müsste ich noch herausfinden, wie ich ihn triggern kann -
Umstellung auf PHP7 war zu Weihnachten, seither ist das genau 1x
aufgetreten. Schwierig.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan. Antiquiert und superb!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#3678

Stefan Froehlich schrieb:

> On Tue, 09 Feb 2016 14:05:46 Christoph M. Becker wrote:
>
>> Eine Github-Suche nach der Fehlermeldung bringt nur zwei wirkliche
>> Treffer im aktuellen Master. Eine davon wird von class_alias() geworfen,
>> die andere von OPcache. Du könntest ja mal über die Quellen der von Dir
>> verwendeten PHP-Version greppen – vielleicht lässt sich das Problem ja
>> so eingrenzen. (Und ja, ich könnte mir vorstellen, dass es sich um einen
>> Bug in OPcache handelt.)
> 
> Muss dann wohl, weil class_alias() habe ich in meinem Leben bisher
> noch nicht verwendet.
> 
> Jetzt müsste ich noch herausfinden, wie ich ihn triggern kann -
> Umstellung auf PHP7 war zu Weihnachten, seither ist das genau 1x
> aufgetreten. Schwierig.

Wenn Du bereits PHP7 verwendest, dann dürfte der Treffer in Master
relevant sein:
<https://github.com/php/php-src/blob/71c19800258ee3a9548af9a5e64ab0a62d1b1d8e/ext/opcache/zend_accelerator_util_funcs.c#L653>.

Vielleicht hilft das ein bisschen weiter.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#3681

On Tue, 09 Feb 2016 17:03:35 Christoph M. Becker wrote:
> > Jetzt müsste ich noch herausfinden, wie ich ihn triggern kann -
> > Umstellung auf PHP7 war zu Weihnachten, seither ist das genau 1x
> > aufgetreten. Schwierig.

> Wenn Du bereits PHP7 verwendest, dann dürfte der Treffer in Master
> relevant sein:
> <https://github.com/php/php-src/blob/71c19800258ee3a9548af9a5e64ab0a62d1b1d8e/ext/opcache/zend_accelerator_util_funcs.c#L653>.
 
> Vielleicht hilft das ein bisschen weiter.

Ad hoc erzeugt das einfach ein "ok, so genau wollte ich es nicht
wissen"-Gefühl. 

Aber immerhin hat das Problem schon eine hilfreiche Wirkung gehabt: als ich
gerade eben ein paar Statements in ein ganz anderes Stück Code eingefügt
habe und die genau *gar* keine Wirkung hatten, bin ich wegen dieser
Diskussion auf die Idee gekommen, den Apache zu reloaden - und siehe da,
plötzlich waren die Änderungen wirksam.

Es muss da irgendetwas im OPCache geben, das (wenigstens bei mir) nicht
so funktioniert, wie vorgesehen.

Servus,
   Stefaen

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - mit dem irritierten Glühen bescheuerter Umfaller.
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#3684

On Tue, 09 Feb 2016 20:35:50 Stefan Froehlich wrote:
> Aber immerhin hat das Problem schon eine hilfreiche Wirkung
> gehabt: als ich gerade eben ein paar Statements in ein ganz
> anderes Stück Code eingefügt habe und die genau *gar* keine
> Wirkung hatten, bin ich wegen dieser Diskussion auf die Idee
> gekommen, den Apache zu reloaden - und siehe da, plötzlich waren
> die Änderungen wirksam.
 
> Es muss da irgendetwas im OPCache geben, das (wenigstens bei mir)
> nicht so funktioniert, wie vorgesehen.

Gerade eben konnte ich das nachstellen; im Grund genommen hatte
ich in einem viel größeren Kontext folgendes gemacht:

[Vorbereitend] 

$ mkdir a
$ echo "<?php echo 'A'; ?>" > test.php
$ mkdir b 
$ echo "<?php echo 'B'; ?>" > test.php
$ ln -s a x

[1. Aufruf von x/test.php]
[Ausgabe: "A"]

$ rm x && ln -s b x

[2. Aufruf von x/test.php]
[Ausgabe: "A"]

[Apache-Reload]
[Ausgabe: "B"]

Das Beispiel ist zu stark vereinfacht, als dass es das Problem
triggern würde, aber es sieht also so aus, als wäre ich über
<http://codinghobo.com/opcache-and-symlink-based-deployments/>
gestolpert. Unschön und offenbar ohne wirklich elegante Lösung.

Ich nehme einmal an, dass die scheinbar doppelte Klassendefinition
auch auf die eine oder andere Art damit zusammenhängt.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan, mit dem dämlichen Streif der Lebensfreude.
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#3685

On 2016-02-11 18:32, Stefan Froehlich <Stefan+Usenet@Froehlich.Priv.at> wrote:
> Gerade eben konnte ich das nachstellen; im Grund genommen hatte
> ich in einem viel größeren Kontext folgendes gemacht:
>
> [Vorbereitend] 
>
> $ mkdir a
> $ echo "<?php echo 'A'; ?>" > test.php
> $ mkdir b 
> $ echo "<?php echo 'B'; ?>" > test.php
> $ ln -s a x
>
> [1. Aufruf von x/test.php]
> [Ausgabe: "A"]
>
> $ rm x && ln -s b x
>
> [2. Aufruf von x/test.php]
> [Ausgabe: "A"]
>
> [Apache-Reload]
> [Ausgabe: "B"]
>
> Das Beispiel ist zu stark vereinfacht, als dass es das Problem
> triggern würde,

Schade. Für das Beispiel oben würde mir nämlich eine einfache Erklärung
einfallen, warum sich das so verhält (und auch eine Lösung für das
Problem).

> aber es sieht also so aus, als wäre ich über
><http://codinghobo.com/opcache-and-symlink-based-deployments/>
> gestolpert. Unschön und offenbar ohne wirklich elegante Lösung.

Hmm, die Erklärung scheint mir verkehrt herum oder zumindest irreführend
zu sein:

| The reason this breaks when switching from APC to OpCache is the way the
| two systems cache files. APC uses filesystem inodes to cache files. This
| works as inodes refer to the symlink, rather than the actual file. So in
| the following example, APC remembers /current/index.php rather than
| /releases/1/index.php:
| 
| current -> /releases/1
| releases/
|     1/
|         index.php
|     2/
|         index.php
| 
| OpCache however is not inode-based. OpCache will evaluate the symlinks
| to find the real file path before caching, so OpCache will remember
| /releases/1/index.php instead.

Ich schreibe jetzt mal (frei erfundene) Inode-Nummern dazu:

101 current -> /releases/1
201 releases/
301    1/
302        index.php
401    2/
402        index.php

"current/index.php" ist kein Inode, es ist ein Pfadname. Vor dem Switch
referenziert dieser Pfadname den Inode 302, nach dem Switch den Inode
402. Der Satz "inodes refer to the symlink, rather than the actual file"
ist schlicht falsch. Inodes *sind* das "actual file" (naja, zumindest
der Teil davon, über den man den Rest findet) und in diesem Beispiel
gibt es keinen Inode, der "current/index.php" referenzieren würde (der
Inode 101 ist hingegen der Symlink "current" (oder richtiger
ausgedrückt, der Filename "current" referenziert den Inode 101).

Was möglicherweise gemeint sein könnte, ist dass APC sich den Pfadnamen
/current/index.php merkt und vor jedem Zugriff überprüft, ob dieser noch
auf den gleichen Inode verweist (mittels stat(2)). Und dass OpCache das
nicht tut, sondern entweder gar nicht schaut, ob es eine Änderung gab
oder das File offenhält und mittels fstat(2) auf Änderungen prüft (in
diesem Fall hätte es den Inode 302 offen, der sich nicht ändert und
würde nicht bemerken, dass der Pfadname, der ursprünglich verwendet
wurde, um diesen öffnen, mittlerweile auf Inode 402 verweist).

Tatsächlich gibt es allerdings (inzwischen?) zumindest die Optionen
opcache.validate_timestamps und opcache.revalidate_freq. Es gibt also
offensichtlich eine Überprüfung, ob ein File noch aktuell ist, und es
erscheint mir unwahrscheinlich, dass PHP alle gelesenen File offen hält.

        hp (zu faul, den Source-Code zu lesen)

-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

[toc] | [prev] | [next] | [standalone]

#3686 — OpCache (was: Klassendefinition, wo?)

On Sat, 13 Feb 2016 13:36:00 Peter J. Holzer wrote:
> > [Vorbereitend] 
> >
> > $ mkdir a
> > $ echo "<?php echo 'A'; ?>" > test.php
> > $ mkdir b 
> > $ echo "<?php echo 'B'; ?>" > test.php
> > $ ln -s a x
> >
> > [1. Aufruf von x/test.php]
> > [Ausgabe: "A"]
> >
> > $ rm x && ln -s b x
> >
> > [2. Aufruf von x/test.php]
> > [Ausgabe: "A"]
> >
> > [Apache-Reload]
> > [Ausgabe: "B"]

> > Das Beispiel ist zu stark vereinfacht, als dass es das Problem
> > triggern würde,
 
> Schade. Für das Beispiel oben würde mir nämlich eine einfache Erklärung
> einfallen, warum sich das so verhält (und auch eine Lösung für das
> Problem).

In der Tat schade; das Problem mit Caches ist häufig, dass man Dinge
nicht zuverlässig reproduzieren kann. An sich mache ich im echten Leben
genau das, aber ich habe natürlich keine Ahnung, ob Art, Anzahl und
Häufigkeit der Zugriffe einen Einfluss auf den Cache hat.

Meine Software ist idR in mehreren Versionen vorrätig, dazu auch noch
der Head vom jeweiligen Branch. In den Document Roots verweise ich per
Symlink auf die gewünschte Version, die wiederum ein Symlink auf den
aktuellen Patchlevel ist.

Also:

[vhost]
| sw -> [software]/3.2

[software]
| 3.2 -> 3.2.3
| 3.2.2
| 3.2.3
| 3.2.head

Tritt nun in einem vhost ein Fehler auf, oder wird eine (sehr
kleine) Änderung gewünscht, dann hänge ich diesen vhost von seiner
Version auf den Head um, kann die Situation mit den Live-Daten
analysieren und das Problem beheben.

[vhost]
| sw -> [software]/3.2.head

[software]
| 3.2 -> 3.2.3
| 3.2.2
| 3.2.3
| 3.2.head


Danach wird aus dem korrigierten Head ein neuer Patchlevel erzeugt,
in ein Verzeichnis ausgecheckt und der Link für die aktuelle Version
umgebogen, womit alle vhosts unmittelbar vom Bugfix profitieren:

[vhost]
| sw -> [software]/3.2

[software]
| 3.2 -> 3.2.4
| 3.2.2
| 3.2.3
| 3.2.4
| 3.2.head

Das hat sich in langen Jahren als best practice für die allermeisten
Bugs erwiesen - nur bei wenigen, größeren Problemen muss mehr
Aufwand getrieben werden.

Seit PHP7 kommen allerdings manchmal direkt nach dem Umschalten von

| 3.2 -> 3.2.3

auf 

| 3.2 -> 3.2.4

haufenweise obskure Fehlermeldungen, die erst durch einen Reload des
Webservers verschwinden. Der Zusammenhang mit dem OpCache ist mir
erst durch diesen Thread bewusst geworden (ich verwende das neue
Setup seit Jahreswechsel, so viele Korrekturen gab es da noch nicht,
und das Problem tritt auch nicht jedes Mal auf), aber jetzt wo ich
darum weiss, bin ich natürlich auf der Suche nach einer Lösung.

> ><http://codinghobo.com/opcache-and-symlink-based-deployments/>

> Hmm, die Erklärung scheint mir verkehrt herum oder zumindest
> irreführend zu sein: [...]

Das kann gut sein, ja.

> Tatsächlich gibt es allerdings (inzwischen?) zumindest die
> Optionen opcache.validate_timestamps und opcache.revalidate_freq.
> Es gibt also offensichtlich eine Überprüfung, ob ein File noch
> aktuell ist, und es erscheint mir unwahrscheinlich, dass PHP alle
> gelesenen File offen hält.

Offen gehalten wird definitiv nichts (das lässt sich mit lsof
trivial nachprüfen), aber wie der OpCache nun tatsächlich mit
versymlinkten Files umgeht, habe ich noch nicht herausgefunden.

opcache.revalidate_freq habe ich nun von 2 auf 0 gesetzt; ob das
wirklich weiterhilft, bezweifle ich, weil die Option ja gar kein
symlink-spezifisches Verhalten hat, und die Fehlermeldungen auch
nicht bloss für 2 Sekunden aufgetreten sind (damit könnte ich noch
halbwegs leben).

Es hat evt. damit zu tun, ob Dateien unter ihrem aufgerufenen Namen
oder unter dem mit realpath() ermittelten Namen gecached werden.
<http://jpauli.github.io/2014/06/30/realpath-cache.html> scheint das
erst einmal zu bestätigen, erwähnt aber im unteren Teil, dass auch
APC sich auf den realpath_cache verlässt, das Problem bei mir also
auch schon früher hätte auftreten müssen.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Superb? Superber als Stefan!? Wer glaubt, der kauft!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#3679

Stefan Froehlich wrote:

[Zitat repariert]

> On Tue, 09 Feb 2016 00:13:35 Thomas 'PointedEars' Lahn wrote:
>> >> > | Cannot declare class Page_Webshop_Search, because the name is
>> >> > | already in use
>> >> >
>> >> > Das ganze passiert bei einem:
>> >> > 
>> >> > | require_once 'search.php';
>> >> Bist du sicher, dass dein Autoloader nicht doch gelaufen war?
>> >> Hast du Opcache?
>> > Der Autoloader ist definitiv nicht gelaufen, nein.
>> Gemäss Google-Suchergebnissen für die Fehlermeldung
>> unwahrscheinlich.
> 
> Naja, ich hatte testhalber ein "die;" mit dem entsprechenden
> Dateinamen in den (einzigen relevanten) Autoloader gesetzt. Beim
> oben zitierten Ladeversuch ist er dann auch brav verendet, aber auch
> eben erst dort.
> 
> Das war für mich Indiz genug, um derartiges zu behaupten.

<https://www.google.com/search?q=%22Cannot+declare%22+%22%2C+because+the+name+is+already+in+use%22&oq=%22Cannot+declare%22+%22%2C+because+the+name+is+already+in+use%22&aqs=chrome..69i57.25872j0j7&sourceid=chrome&es_sm=122&ie=UTF-8>

>> > Wobei ich mich durchaus immer noch frage, was genau die Probleme
>> > verursacht hat. Ich möchte ja keinesfalls, dass sie (mehr oder
>> > minder aus heiterem Himmel) neuerlich auftreten.
>> UTSL.
> 
> Scherzkeks.

Das war kein Scherz.

> Wenn *mein* Source die Probleme nicht reproduzierbar
> auftreten lässt (sie kamen unmotiviert und verschwanden nach einem
> Apache-Reload),

Das kann genau dann passieren, wenn vor der Ausführung Deines Codes und vor 
dem Apache-Reload jeweils ein PHP-Upgrade erfolgt ist; zunächst auf eine 
fehlerhafte PHP-Version, dann auf eine neuere PHP-Version, die diesen Bug 
nicht mehr hat.  Wenn PHP als Apache-Modul läuft, dann läuft bis zum Apache-
Reload/Restart noch die alte Version.  In der Regel wird der Apache-Reload 
deshalb bei der Installation von einem Upgrade-Script des Moduls ausgelöst.

> dann bleibt nur der PHP-Source. Und das ist, ohne konkreten,
> reproduzierbaren Anlassfall wohl eher aussichtslos (und
> selbst mit Anlassfall vermutlich beyond my scope).

Textsuche überfordert Dich?

BTW: Bring Deinem Newsreader mal bitte bei (oder korrigiere es manuell), 
dass bei zitierten Leerzeilen die Zitatzeichen stehenbleiben sollen.  Wenn 
das nämlich so wie jetzt weitergeht, werden Threads, in denen Du postest, 
mit jeder neuen Zitatebene unleserlicher.  Wie Du sicher schon bemerkt hast, 
zitiert (hier) *niemand* sonst so wie Du.  TIA.

-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#3680

On Tue, 09 Feb 2016 20:02:34 Thomas 'PointedEars' Lahn wrote:
> Stefan Froehlich wrote:
> > Wenn *mein* Source die Probleme nicht reproduzierbar auftreten
> > lässt (sie kamen unmotiviert und verschwanden nach einem
> > Apache-Reload),

> Das kann genau dann passieren, wenn vor der Ausführung Deines
> Codes und vor dem Apache-Reload jeweils ein PHP-Upgrade erfolgt
> ist; zunächst auf eine fehlerhafte PHP-Version, dann auf eine
> neuere PHP-Version, die diesen Bug nicht mehr hat.  Wenn PHP als
> Apache-Modul läuft, dann läuft bis zum Apache- Reload/Restart noch
> die alte Version.  In der Regel wird der Apache-Reload deshalb bei
> der Installation von einem Upgrade-Script des Moduls ausgelöst.

Ja, allerdings fand unmittelbar *vor* dem Auftreten des Bugs kein
Upgrade statt, und bei den Upgrades startet Debian den Apache neu
(aus eben diesem Grund - genau das ist ja *nach* dem Auftreten des
Bugs auch passiert).

Weshalb die Probleme wieder verschwunden sind, verstehe ich also;
viel interessanter ist jedoch, weshalb sie entstanden sind.
 
> > dann bleibt nur der PHP-Source. Und das ist, ohne konkreten,
> > reproduzierbaren Anlassfall wohl eher aussichtslos (und selbst
> > mit Anlassfall vermutlich beyond my scope).
 
> Textsuche überfordert Dich?

Nein, aber der Code dort. Leider.
 
> BTW: Bring Deinem Newsreader mal bitte bei (oder korrigiere es
> manuell), dass bei zitierten Leerzeilen die Zitatzeichen
> stehenbleiben sollen.

Du musst tapfer sein: Ich entferne die Zeichen sogar manuell, weil
ich das optisch besser finde. Auf die Erkennbarkeit der Zitatzeichen
hat es IMHO keinen Einfluss, und ob eine Leerzeile als Zitat
markiert werden soll, ist wohl eine reine Geschmacksfrage. YMMV.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan. Über den avantgardistischen Klee zu loben!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#3682 — Zitierstil (was: Klassendefinition, wo?)

Stefan Froehlich wrote:

> On Tue, 09 Feb 2016 20:02:34 Thomas 'PointedEars' Lahn wrote:
>> BTW: Bring Deinem Newsreader mal bitte bei (oder korrigiere es
>> manuell), dass bei zitierten Leerzeilen die Zitatzeichen
>> stehenbleiben sollen.
> 
> Du musst tapfer sein: Ich entferne die Zeichen sogar manuell,

Dann kann ich Dein Verhalten nur als unverschämt und rücksichtslos gegenüber 
Deinen Lesern bezeichnen, da wir diese Diskussion ja nun nicht zum ersten 
Mal haben.  Lass das bitte!

> weil ich das optisch besser finde. Auf die Erkennbarkeit der
> Zitatzeichen hat es IMHO keinen Einfluss, und ob eine Leerzeile
> als Zitat markiert werden soll, ist wohl eine reine Geschmacksfrage.
> YMMV.

Nein, das ist *keine* reine Geschmacksfrage!  Die Zitatzeichen sollen dazu 
dienen, dass der Leser erkennen kann, wo eine Zitatebene anfängt und wo sie 
aufhört, damit er die Argumente einer Diskussion ohne Mühe in Bezug 
zueinander setzen kann.  Dem Auge des Lesers wird somit eine Leitplanke 
gegeben, entlang derer er lesen kann.  Bei Deinem – nun nachweislich auch 
noch *künstlich* *falschen* – Zitierstil wird ihm das sehr erschwert.  

Das lässt sich leicht zeigen, indem man den Weg des Auges des Lesers 
markiert.  Hätte ich zum Beispiel Dein kaputtes Zitat nicht repariert,
sähe der hier gezeichnete vertikale Leseweg nicht so aus –

| > ------.
| >> >> > :
| >> >> > :
| >> >> > :
| >> >> > :
| >> >> > :
| >> >> > :
| >> >> ,-'
| >> >> :
| >> > ,'
| >> ,-'
| >> :
| > ,' 
| > :
| > :
| > :
| > :
| > :
| > v

– sondern so:

| > -------.
| > > >> > :
| > > >> > :
| > <------:
| > > >> > :
| > <------:
| > > >> > : 
| > <------:
| > > >> ,-'
| > > >> :
| > <----:
| > > > ,'
| > <-.-'
| > > :
| > > :
| > ,-'
| > :
| > :
| > :
| > :
| > :
| > v

Wie Du siehst, schickst Du das Auge des Lesers immer wieder in eine 
Sackgasse, aus der er sich dann befreien muss bzw. sorgst für die 
wiederholte Unterbrechung des Leseflusses.  Das erschwert das Lesen 
erheblich, macht es sehr mühsam.

Hinzu kommt – wie ich nun weiss, dass Du ebenfalls sehr wohl weisst [1] –, 
dass unterschiedliche Zitatebenen von einigen verbreiteten Newsreadern (und 
E-Mail-Clients) basierend auf denselben Usability-Überlegungen wie bei 
mehreren Zitatzeichen unterschiedlich formatiert werden; üblich ist zum 
Beispiel eine andere Färbung oder ein anderer Schriftstil.   Das 
funktioniert dann bei Deinen Postings natürlich auch nicht mehr so wie es 
gedacht ist.

<https://en.wikipedia.org/wiki/Newsreader_(Usenet)#/media/File:Gnus-reading-news.png>
<http://pan.rebelbase.com/screenshots/go.png>
<https://en.wikipedia.org/wiki/Slrn#/media/File:Slrn.png>
[1] <http://tin.org/gfx/tin1.png>
<https://addons.mozilla.org/en-us/thunderbird/addon/quote-colors/>
<https://en.wikipedia.org/wiki/X_Python_Newsreader#/media/File:XPN-main-large.png>

In der Erschwernis für den Leser kommt Deine Zitierweise deshalb der eines 
Kammzitats gleich.

Und deshalb werden auch *nirgendwo* ausser bei Dir Texte auf diese Weise 
zitiert.  Lass das bitte!

<http://einklich.net/usenet/zitier>
<http://www.afaik.de/usenet/faq/zitieren/>

X-Post & F'up2 <news:de.soc.usenet> (_nicht_ moderiert)

-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#3683 — Re: Zitierstil (was: Klassendefinition, wo?)

Am Dienstag, 9. Februar 2016 22:25:41 UTC+1 schrieb Thomas 'PointedEars' Lahn:
> Stefan Froehlich wrote:
> 
> > On Tue, 09 Feb 2016 20:02:34 Thomas 'PointedEars' Lahn wrote:
> >> BTW: Bring Deinem Newsreader mal bitte bei (oder korrigiere es
> >> manuell), dass bei zitierten Leerzeilen die Zitatzeichen
> >> stehenbleiben sollen.
> > 
> > Du musst tapfer sein: Ich entferne die Zeichen sogar manuell,
> 
> Dann kann ich Dein Verhalten nur als unverschämt und rücksichtslos gegenüber 
> Deinen Lesern bezeichnen, da wir diese Diskussion ja nun nicht zum ersten 
> Mal haben.  Lass das bitte!

Das ist ja wirklich ein Thema, das die Welt bewegt und btw du musst hier gar nichts lesen.

Immer zu Diensten,
Till Eulenspiegel

[toc] | [prev] | [standalone]

Back to top | Article view | de.comp.lang.php

csiph-web