This forum has been archived. Please start a new discussion on GitHub.

cached connections with php


i'm having some trouble with PHP 3.2.1/3.3.1 keeping cached connections to a java service (3.3.1). my understanding is that while a proxy is associated with a connection, connections are actually maintained by the communicator, which cannot be created or destroyed in PHP (exists for the life of the apache process?).

enabling network tracing on the network side shows that established connections are closed as soon as the php script finishes.

for example a simple script like the following:

// Create a proxy for the object.
$proxy = $ICE->stringToProxy("UserService:tcp -p 10100");

// Narrow the proxy to the proper type.
$hello = $proxy->ice_checkedCast("UserService");

// Use the factory to obtain a proxy for a new invoice object.

when accessed through apache, will open a connection when execution starts and immediately close the connection once the script exits. i would expect the communicator is not destroyed when the script finishes and hence the connection would be cached for future requests. the net result at the moment is a new connection is established for every invocation, clearly not ideal for performance.

i have tried enabling/disabling ACM which had no effect (expectantly).

any ideas?



  • mes
    mes California
    Hi Peter,

    Here's a quote from this section of the manual:
    PHP scripts are not allowed to create or destroy communicators. Rather, a communicator is created prior to each PHP request, and is destroyed after the request completes.

    This explains the behavior you're seeing.

    I agree that this is less than optimal, but there are some other factors to consider. First of all, a web server can (theoretically) be running any number of PHP applications simultaneously. There are potential security issues if two unrelated applications were able to use the same communicator, so we originally elected to avoid such issues by limiting the lifetime of a communicator.

    Second, web servers such as Apache often use multiple child processes. Even if a PHP script was able to create a communicator in one of those processes, the next PHP request of the same script might not use the same child process. For a session-based PHP script to use this strategy effectively, you would have to ensure that a session is always serviced by the same process.

    Note that Ice 3.4 will bring some changes in this area. Scripts will be able to create and destroy communicators at will, and even "register" them for reuse by subsequent requests. For example, a PHP session could create a communicator and then start a Glacier2 session. It will be the developer's responsibility to ensure that those requests are processed by the same web server process.

  • hi mark

    thank you for the reply, i missed the salient bit there in the documentation :)

    looking forward to the 3.4 release, is there a timeline for the 3.4 release?

  • mes
    mes California
    nefilim wrote: »
    looking forward to the 3.4 release, is there a timeline for the 3.4 release?
    We don't announce release schedules, but we are hoping to release a beta later this month.