kostenloser Webspace werbefrei: lima-city


Merkwürdiger Session Bug

lima-cityForumProgrammiersprachenPHP, MySQL & .htaccess

  1. Autor dieses Themas

    midwar

    midwar hat kostenlosen Webspace.

    Hallo,

    ich benutze über eine extern API einen selbstgeschriebenen SOAP PHP Client. Der funktioniert soweit wunderbar, lediglich treten einige sehr merkwürdige Session Fehler auf, bei denen ich nicht weiter weis.

    Zusammenfassung: Die API folgt dem Schema, erst autzentifizieren, dann kann ich in einem zweiten Schritt Suchanfragen starten und im dritten Schritt muss ich die Verbindung wieder trennen. Also die Session beenden. Starte ich das ganze Skript nun, klappt eigentlich alles und die Suchergebnisse werden mir angezeigt. Klicke ich nun auf Aktualisieren und er lädt die Seite neu, KANN es sein, dass lediglich ein 'session not found: SID=I2b45baEdoaOLpOE4J8 NodeID=I2' kriege. Aktualisiere ich nochmals, funktioniert meistens (nicht immer!) alles wieder und mir werden wieder die gleichen Suchergebnisse angezeigt von vor zwei Seitenaufrufen. Woran liegt das ganze nun? Ich habe dann beim Anbieter in der - reichlich spärlichen - Anleitung zur Benutzung seines Suchdienstes nachgeguckt und erfahren, dass genau diese Fehlermeldung bedeutet, dass die zu löschende Session nicht mehr existiert. Aber wie kann das sein? Wie gesagt folgt mein Skript stumpf dem Ablauf 1. Authentifizieren, 2. Suchen, 3. Session abmelden. Trotzdem spuckt er mir gelegentlich schon beim Suchen diese Meldung aus, also das die Session nicht mehr vorhanden sei.

    Woran liegt sowas? Ich habe in einem Englischen Forum die Frage mal gestellt und darauf als Antwort erhalten, dass "Session data is usually stored after your script terminated without the need to call session_write_close(), but as session data is locked to prevent concurrent writes only one script may operate on a session at any time. When using framesets together with sessions you will experience the frames loading one by one due to this locking. You can reduce the time needed to load all the frames by ending the session as soon as all changes to session variables are done."

    Ich habe zwar verstanden was da steht und was das alles im Bezug auf Framesets heißt, allerdings verstehe ich nicht was das nun mit meinem Beispiel zutun hat?! Bei mir handelt es sich nicht um Framesets, sondern um EIN Skript, dass lediglich aus einem SOAP Client besteht, der authentifiziert, sucht, ausloggt. Hier werden keine weiteren Inhalte eingebunden oder ähnliches. Und in sofern kann es nicht sein, dass PHP hier die Session Data für irgendetwas anderes sperren müsste.

    Woran kann es also bitte liegen? Ich habe da gerade absolut keine Ahnung.

    Vielen Dank.
  2. Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!

    lima-city: Gratis werbefreier Webspace für deine eigene Homepage

  3. wenn das eine einzige datei ist, brauchst du dich nicht zu schämen, sie hier zu zeigen. nach deiner schilderung gilt was du ohnehin behauptest:
    midwar schrieb:
    ... Ich habe da gerade absolut keine Ahnung...
    also code her ... bitte.
  4. Hallo,

    Ist die Session an eine TCP/IP Session gebunden (HTTP 1.1)?

    Reine Spekulation(!):

    Es könnte sein, dass ein Load-Balancer beim erneuten TCP/IP Verbindungsaufbau an einen Server vermittelt, der die Session nicht kennt. Wenn man den Verbindungsaufbau ein paar mal wiederholt, landet man schließlich wieder bei dem Server, der die Session-ID kennt (der Text: NodeID=l2 könnte ein Indiz sein - dieser Server kennt sie nicht).

    Das wäre eine mögliche Erklärung für das beobachtete Phänomen.

    Man kann Load-Balancer so konfigurieren, dass sie die Session-ID für einen gewissen Zeitraum merken und dann "sticky" immer an den selben Server (node) weiterreichen, aber darauf hat der Client-Programmierer i.d.R. keinen Einfluss.

    Evtl. musst Du die TCP/IP Session bestehen lassen und mehrere Abfragen darüber tätigen (z.B. Daemon- oder FCGI-Process)?

    HTH

  5. Autor dieses Themas

    midwar

    midwar hat kostenlosen Webspace.

    Hallo,

    dann reiche ich mal den zugehörigen Code nach:

    class WOSFetch {
         // ****************************************************
         // Fetcher Class for WOS. Finds all Data to a given Therm and fetches it to local.
         // ****************************************************
         
    	private $AuthURL  = "http://search.isiknowledge.com/esti/wokmws/ws/WOKMWSAuthenticate?wsdl";
         private $SearchURL = "http://search.isiknowledge.com/esti/wokmws/ws/WokSearchLite?wsdl";
         
    	public $AuthClient;
    	public $SearchClient;
    	
    	private $ProxyOptions = array(
    		'proxy_host' => 'proxyserver,
    		'proxy_port' => 0000,
    		'proxy_login' => 'username',
    		'proxy_password' => 'password'
    	);
    	private $SearchOptions = array(
    		'queryParameters' => array(
    			'databaseID' => 'WOS',
        			'editions' => array(
          			array('collection' => 'WOS', 'edition' => 'SSCI'),
          			array('collection' => 'WOS', 'edition' => 'SCI')
        			),
        			'queryLanguage' => 'en'
      		),
      		'retrieveParameters' => array(
        			'count' => '5',
        			'firstRecord' => '1',
        			'RecordIDs' => 'On'
      		)
    	);
    	private $FetchOptions = array(
    	     // Options for the fetching process. Article-IDs have to be passed like 'uids' => array("012345678","123456789")
    		'databaseId' => 'WOS',
    		'uids' => array("000175726300031","000075022300003"),
        		'queryLanguage' => 'en',
      		'retrieveParameters' => array(
        			'count' => '20',
        			'fields' => array(
          			array('name' => 'Date', 'sort' => 'D')
        			),
        			'firstRecord' => '1'
      		)
    	);
    	
    	public function __construct() {
    	     // ****************************************************
         	// Start authentication process and the SearchClient
         	// ****************************************************
         	
    		$this->AuthClient = @new SoapClient($this->AuthURL,$this->ProxyOptions);
    		$AuthResponse = $this->AuthClient->authenticate();
    		$this->SearchClient = @new SoapClient($this->SearchURL,$this->ProxyOptions);
    		$this->SearchClient->__setCookie('SID',$AuthResponse->return);
    	}
    	public function __destruct() {
    	     // ****************************************************
         	// When fetcher is closed, close Session from the WOS Web Services
         	// ****************************************************
         	
    		$this->AuthClient->closeSession();
    	}
    	public function Main($Query) {
    	     // ****************************************************
         	// Main function of the Fetcher. Searches via given Therm for all IDs matching and then starts the fetch-process.
         	// ****************************************************
         	
     		if(!empty($Query)) {
     			// If User gave a Query to search for, execute it
     			if($SearchResponse = $this->Search($Query)) {
    				// We got an Search Response, so we found something corresponding to that Query
    				$Converter = new WOSConvert();
    				$Converted = $Converter->Convert($SearchResponse);
    				$Converter->Filter("UT",$Converted);
    				
    				// Fetch the Parsed IDs as data
    				return $this->Fetch($Converter->FilteredData);
    			}
    			else {
    				$this->ErrorOut("Error: The Search went wrong!");
    			}
    		}
    		else {
    			// No specific Query to search for was given
    			$this->ErrorOut("Error: You gave no specific SearchQuery!");
    			return false;
    		}
    	}
    
    	public function Search($Query) {
    	     // ****************************************************
         	// Executes a search to a given Query and returns the WOS IDs found
         	// ****************************************************
    
    	     $this->SearchOptions["queryParameters"]["userQuery"] = $Query;
    	     try {
          		$SearchResponse = $this->SearchClient->search($this->SearchOptions);
          		return $SearchResponse;
    		} catch (Exception $e) {
    			echo $e->getMessage();
    			return false;
    		}
    	}
    	public function Fetch($IDs) {
    	     // ****************************************************
         	//  Fetches the found IDs as meta data
         	// ****************************************************
    
    		$this->FetchOptions['uids'] = $IDs;
    	     try {
          		$FetchResponse = $this->SearchClient->retrievebyid($this->FetchOptions);
          		return $FetchResponse;
    		} catch (Exception $e) {
    			echo $e->getMessage();
    			return false;
    		}
    		
    		// Destruct the class after each fetch attempt in order to logout from wos service
    		$this->__destruct();
    	}
    	private function ErrorOut($ErrorMsg) {
    	     // ****************************************************
          	// Outputs Error-Messages, can add statistical features later
          	// ****************************************************
    
    		echo $ErrorMsg . "<br>";
    	}
    }


    Mir ist gerade eingefallen, dass ich eine main.php habe, die wos.php mit include() einbindet und dann die oben im Code aufgeführten Klassen (wos.php) instanziert und ausführt. Könnte es das sein? Reicht ein simples include() aus, um Sessions zu locken, und den beschriebenen Fehler bei mir zu provozieren?

    Ob das ganze Ding an eine TCP/IP Session gebunden ist - keine Ahnung. Wo ist da der Unterschied? Besteht einer?
  6. Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!

    lima-city: Gratis werbefreier Webspace für deine eigene Homepage

Dir gefällt dieses Thema?

Über lima-city

Login zum Webhosting ohne Werbung!