Symboltabelle Maintenance (gelöst) (mod_perl und Apache)

[thread]19473[/thread]

Symboltabelle Maintenance [gelöst]

Leser: 15

Articles: hide open all | hide show old branches

+12 replies
rosti

2015-01-22 07:09

User since
2011-03-19
3194 Artikel
BenutzerIn

Fall: Entwickler hat Mist gebaut, alle Seiten, die ein bestimmtes Modul nutzen, funktionieren nicht mehr, weil das Modul, nennen wir es z.B. MVC::TemplateFile nicht evaluiert. Alle anderen Seiten funktionieren und es gibt eine AdminSeite, wo ein delete $INC{'MVC/TemplateFile.pm'}; gemacht werden kann.

Das reload/recompile MVC::TemplateFile funktioniert danach einwandfrei, aber es gibt Warnungen, dass alle zu MVC::TemplateFile gehörigen Methoden 'redefined' sind.

Ich möchte mir dieses Hintertürchen offenhalten, damit im Fehlerfall ein Neustart des Apache nicht notwendig ist. Wie kann ich den gesamten Scope des betreffenden Moduls löschen, ohne das es Warnungen gibt? Das 'delete' reicht nicht und die Warnungen möchte ich ungern ausschalten.

MfG
- +2 replies
- GwenDragon
  
  2015-01-22 07:17
  
  User since
  2005-01-17
  14533 Artikel
  Admin1
  
  no warnings 'redefine'; in einem Block willst du nicht?
  die Drachin, Gwendolyn
  
  Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
  - rosti
    
    2015-01-22 07:38
    User since
    2011-03-19
    3194 Artikel
    BenutzerIn
    
    2015-01-22T06:17:18 GwenDragon
    no warnings 'redefine'; in einem Block willst du nicht?
    
    Nicht wirklich ;)
    
    Ich bin so pragmatisch, dass ich normalerweise ein $SIG{__WARN__} = sub{ confess @_ }; setze, damit ich alles mitbekomme ;)
    
    Nun, auf vielen Seiten Dokumentationen zu mod_perl wird ein
    
    Code (perl): (dl )
    
    use warnings FATAL => 'all';
    
    empfohlen. Ein 'redefine' ist offensichlich nicht FATAL, wenn ein Modul redoaded wird, es wird lediglich das error-log beschrieben.
    
    Vielleicht aber auch ist ein $SIG{__WARN__} = sub{ confess @_ }; etwas 'altmodisch' und nicht unbedingt empfehlenswert?
- GwenDragon
  
  2015-01-22 08:00
  
  User since
  2005-01-17
  14533 Artikel
  Admin1
  
  Ungeteste Idee (ohne Kaffee intus!): In einem BEGIN-Block einen Glob auf die Symboltablelle von MVC::TemplateFile und dort die Symbole vorher löschen.
  die Drachin, Gwendolyn
  
  Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
- +6 replies
- pq
  
  2015-01-22 08:03
  
  User since
  2003-08-04
  12208 Artikel
  Admin1
  
  Module::Reload
  weiss aber nicht, ob es die warnungen ausschaltet
  Last edited: 2015-01-22 08:04:57 +0100 (CET)
  Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
  lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
  - +5 replies
  - rosti
    
    2015-01-22 08:40
    User since
    2011-03-19
    3194 Artikel
    BenutzerIn
    
    2015-01-22T07:03:44 pq
    Module::Reload
    weiss aber nicht, ob es die warnungen ausschaltet
    
    Habs getestet in meiner mod_perl Umgebung tuts einfach nicht. Die Erweiterung ::Selective gibt Fehlermeldung, wäre aber auch nicht praktikabel, weil ich eine Liste meiner eigenen Module pflegen müsste (da leidet die Dynamic *g).
    
    Indes, mit
    
    Code (perl): (dl )
    
    1 2
    
    use warnings FATAL => qw(all); # im PerlResponseHandler, BaseClass # und delete $INC{'Foo/Bar'} per Klick im Admin-Backend
    
    kann ich ganz gut leben, denn das funktioniert wie gewünscht. Vielleicht gibts noch Meinungen zum Thema, ich setze trotzdem mal den Haken.
    
    Bis dann ;)
    
    PS: Configs neu einlesen, Module reloaden... und das während der Fahrt, vielleicht kriege ich ja meinen Provider dazu, mod_perl zu installieren mit dem Hinweis, dass Server-Neustarts nur in sehr seltenen Fällen notwendig sind, die er sogar auch selbst bestimmen kann (Wartungsfenster).
    Last edited: 2015-01-22 09:14:59 +0100 (CET)
    - +2 replies
    - renee
      
      2015-01-22 09:15
      
      User since
      2003-08-04
      14371 Artikel
      ModeratorIn
      
      Apache::Reload
      
      Edit: ... gibt aber - AFAIK - auch die Warnungen aus. Was ist an den Warnungen so schlimm?
      Last edited: 2015-01-22 09:16:19 +0100 (CET)
      OTRS-Erweiterungen (http://feature-addons.de/)
      Frankfurt Perlmongers (http://frankfurt.pm/)
      --
      
      Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
      Perl-Entwicklung: http://perl-services.de/
      - rosti
        
        2015-01-22 09:38
        
        User since
        2011-03-19
        3194 Artikel
        BenutzerIn
        
        2015-01-22T08:15:02 renee
        Apache::Reload
        
        Edit: ... gibt aber - AFAIK - auch die Warnungen aus. Was ist an den Warnungen so schlimm?
        
        Gute Idee, danke Dir!
        Warnungen sind nicht schlimm, sie sind hilfreich beim Entwickeln, deswegen will ich sie im Browser sehen. Ein vollgemülltes Error_Log ist unbrauchbar. Testgetrieben entwickeln JA, aber nicht testgetrieben Loggen. Ein Blick ins Log sollte NUR dann notwendig sein, wenn es keine andere Möglichkeit gibt, einem Fehler auf die Schliche zu kommen. Mein Ziel ist ein absolut fehlerfreies Error_Log im Regelbetrieb, was natürlich trotzdem heißt, da ab und zu mal reinzugucken.
        
        Apache::Reload krieg ich leider nicht installiert, ist aber nicht dramatisch. Der eigene Umgang mit %INC schafft hilfreiche Erfahrungen und meine erste Erkenntnis von heute ist, dass ein Hack
        
        Code (perl): (dl )
        
        1 2 3
        
        @UNIVERSAL::ISA = __PACKAGE__; # Vorwärtsdeklaration nach dem Motto "Du erbst von mir"
        
        Absolute Scheiße ist. Also besser nicht machen ;)
    - +2 replies
    - pq
      
      2015-01-22 11:50
      
      User since
      2003-08-04
      12208 Artikel
      Admin1
      
      2015-01-22T07:40:34 rosti
      vielleicht kriege ich ja meinen Provider dazu, mod_perl zu installieren
      
      ist das shared webhosting, also mehrere nutzer auf einem webserver? da kriegst du kein mod_perl, und das ist auch gut so. wenn sich mehrere einen webserver teilen und damit auch die prozesse, kann jeder jeden code manipulieren.
      da empfiehlt sich eher fastcgi.
      Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
      lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
      - rosti
        
        2015-01-22 15:22
        
        User since
        2011-03-19
        3194 Artikel
        BenutzerIn
        
        FastCGI habe ich mal um 2000 AD auf einem Pentium I PC als Server für unsere proxy.pac eingerichtet. Das war bezüglich der Hardware ein absolutes Provisorium, was allerdings sehr lange gehalten hat ;)
        
        Danach habe ich mit FastCGI nie wieder was gemacht, ich werde mich mal einlesen ;)
        
        PS: Kaum zu glauben, nach NUR einer Stunde habe ich eine für meinen Apache2.2.14 passende mod_fcgid.so gefunden womit der Apache sogar startet ;)
        
        PS: mod_fcgid.so läuft nicht unter Win32. Der Server startet zwar aber es kommen unverständliche Fehlermeldungen. Stunden später habe ich bei den Monks gelesen, dass das schon immer ein Bug war, der nie gefixt wurde. Was unter Win32 tut, ist mod_fastcgi.so, beachte den Unterschied der Namensgebung. Ebenfalls bei den Monks gefunden habe ich den Link zum Download mod_fastcgi.so, damit funktionierte alles auf Anhieb.
        
        Danke an die PerlMonks!
        
        Betreff %INC verhält sich mod_fastcgi ähnlich wie mod_perl: Einmal kompiliert => immer kompiliert. Bei FastCGI reichts jedoch, die main abzuschießen.
        Last edited: 2015-01-23 09:20:49 +0100 (CET)
- +2 replies
- Muffi
  
  2015-01-22 11:03
  
  User since
  2012-07-18
  1465 Artikel
  BenutzerIn
  
  Sowas in der Art?
  
  Class::Unload
  Allerdings gibts keine 100%-Lösung. Da so ein Modul beim Laden ja prinzipiell dein ganzes Programm umbaun kann, das kriegst du nie wieder 100% rückgängig.
  
  edit: Aber noch ein Nachtrag: Ich glaub du kommst mit den entladen irgendwann irgendwo in Teufels Küche und hast plötzlich undefiniertes Fehlverhalten, weil das Modul vorher irgendwas gemacht hat, was halt nicht rückgängig gemacht wurd oder nicht so richtig.
  Ich würds lassen.
  Ich habs schon länger nicht mehr benutzt und damals hats auch nicht so wirklich funktioniert (weiss aber nicht mehr warum). Aber evtl. ein graceful restart des Apache?
  Last edited: 2015-01-22 11:13:59 +0100 (CET)
  1 + 1 = 10
  - rosti
    
    2015-01-22 11:45
    
    User since
    2011-03-19
    3194 Artikel
    BenutzerIn
    
    Quote
    Ich würds lassen.
    
    Ja, da hast Du recht. Auf einem Produktivsystem (eCommerce) kann es da nur eine Antwort geben: Server neu starten.

View all threads created 2015-01-22 07:09.