Zend_Soap calls returning NULL

[Andrew Ballard]

I set up a very basic client and server using autodiscover to try out
SOAP in ZF. For some reason, all of the functions are returning NULL.
The problem seems to be that the <operation> node in each of the
<portType> nodes is missing an <output> on successive requests. They
are in the WSDL the first time I run the autodiscover after changing
the model. It also seems that the <documentation> node contains the
name of the method instead of the description in the header block.

To test, I added a new method to the model and then saved the WSDL
generated by autodiscover on the next request. I then changed the WSDL
in both the client and server to point to this static XML file -- all
the methods returned exactly what was expected.

Does anyone have any idea why Zend_Soap_AutoDiscover is doing this?

Andrew

[Andrew Ballard]

On Fri, Apr 9, 2010 at 1:00 PM, Andrew Ballard <[hidden email]> wrote:

> I set up a very basic client and server using autodiscover to try out
> SOAP in ZF. For some reason, all of the functions are returning NULL.
> The problem seems to be that the <operation> node in each of the
> <portType> nodes is missing an <output> on successive requests. They
> are in the WSDL the first time I run the autodiscover after changing
> the model. It also seems that the <documentation> node contains the
> name of the method instead of the description in the header block.
>
> To test, I added a new method to the model and then saved the WSDL
> generated by autodiscover on the next request. I then changed the WSDL
> in both the client and server to point to this static XML file -- all
> the methods returned exactly what was expected.
>
> Does anyone have any idea why Zend_Soap_AutoDiscover is doing this?
>
> Andrew
>

I think I may have figured this out during lunch. I think the issue is
the opcode caching on the server. Whenever the page is updated, PHP
grabs the new version from source code -- including comments.
Subsequent requests would come from the cache, and since it is just
opcode it doesn't have any comments to direct Zend_Soap_AutoDiscover.

Andrew

[Benjamin Eberlei-2]

Hello Andrew,



what kind of op-code cache are you using? I have heard from people that

this what you are describing is happening with e-accelerator, personally

I never had a problem with APC.



However I should really update the documentation, the WSDL is not

something

to be generated dynamically upon each request, static serving is much

better (of course if you keep it in sync with your real server

implementation).



greetings,

Benjamin



On Fri, 9 Apr 2010 14:28:23 -0400, Andrew Ballard <[hidden email]>

wrote:

> On Fri, Apr 9, 2010 at 1:00 PM, Andrew Ballard <[hidden email]>

wrote:

>> I set up a very basic client and server using autodiscover to try out

>> SOAP in ZF. For some reason, all of the functions are returning NULL.

>> The problem seems to be that the <operation> node in each of the

>> <portType> nodes is missing an <output> on successive requests. They

>> are in the WSDL the first time I run the autodiscover after changing

>> the model. It also seems that the <documentation> node contains the

>> name of the method instead of the description in the header block.

>>

>> To test, I added a new method to the model and then saved the WSDL

>> generated by autodiscover on the next request. I then changed the WSDL

>> in both the client and server to point to this static XML file -- all

>> the methods returned exactly what was expected.

>>

>> Does anyone have any idea why Zend_Soap_AutoDiscover is doing this?

>>

>> Andrew

>>

>

> I think I may have figured this out during lunch. I think the issue is

> the opcode caching on the server. Whenever the page is updated, PHP

> grabs the new version from source code -- including comments.

> Subsequent requests would come from the cache, and since it is just

> opcode it doesn't have any comments to direct Zend_Soap_AutoDiscover.

>

> Andrew

[Andrew Ballard]

On Sat, Apr 10, 2010 at 3:49 AM, Benjamin Eberlei <[hidden email]> wrote:
>
> Hello Andrew,
>
> what kind of op-code cache are you using? I have heard from people that
> this what you are describing is happening with e-accelerator, personally
> I never had a problem with APC.

We are using eAccelerator on that (development) system. The answer hit
me during lunch as I was mulling around how it was possible that two
identical calls to the exact same functions could produce different
results. Thinking about what could possibly be different from one
request to another, it occurred to me that it had to be the caching.

The production servers are using the Wincache extension, so I don't
know how it might impact them.

> However I should really update the documentation, the WSDL is not
> something
> to be generated dynamically upon each request, static serving is much
> better (of course if you keep it in sync with your real server
> implementation).

I figure when this hits production I'll probably switch to a static
document, but this was my first look at SOAP and I just wanted to see
how it would fit into a project I'm developing right now. Auto
discovery was ideal because it allowed me to experiment easily with
creating different functions with different parameters and return
types.

Andrew

[robert mena]

Hi,

I ma facing the same problem (all my calls return null) and I am using e-accelerator.   While changing to APC is possibile I can't do it right now.

Is there any workaround? I've disabled the cache of wsdl in ini and removed the /tmp/wsdl-* cache file.

On Mon, Apr 12, 2010 at 9:08 AM, Andrew Ballard <[hidden email]> wrote:

On Sat, Apr 10, 2010 at 3:49 AM, Benjamin Eberlei <[hidden email]> wrote:
>
> Hello Andrew,
>
> what kind of op-code cache are you using? I have heard from people that
> this what you are describing is happening with e-accelerator, personally
> I never had a problem with APC.

We are using eAccelerator on that (development) system. The answer hit
me during lunch as I was mulling around how it was possible that two
identical calls to the exact same functions could produce different
results. Thinking about what could possibly be different from one
request to another, it occurred to me that it had to be the caching.

The production servers are using the Wincache extension, so I don't
know how it might impact them.

> However I should really update the documentation, the WSDL is not
> something
> to be generated dynamically upon each request, static serving is much
> better (of course if you keep it in sync with your real server
> implementation).

I figure when this hits production I'll probably switch to a static
document, but this was my first look at SOAP and I just wanted to see
how it would fit into a project I'm developing right now. Auto
discovery was ideal because it allowed me to experiment easily with
creating different functions with different parameters and return
types.

Andrew

[Benjamin Eberlei-2]

eAccelator optimizes doc block comments away, making usage of Autodiscover

infeasible

if you don't generate the WSDL files statically before deployment.



On Fri, 25 Jun 2010 09:51:25 -0400, robert mena <[hidden email]>

wrote:

> Hi,

>

> I ma facing the same problem (all my calls return null) and I am using

> e-accelerator.   While changing to APC is possibile I can't do it right

> now.

>

> Is there any workaround? I've disabled the cache of wsdl in ini and

removed

> the /tmp/wsdl-* cache file.

>

> On Mon, Apr 12, 2010 at 9:08 AM, Andrew Ballard <[hidden email]>

wrote:

>

>> On Sat, Apr 10, 2010 at 3:49 AM, Benjamin Eberlei <[hidden email]>

>> wrote:

>> >

>> > Hello Andrew,

>> >

>> > what kind of op-code cache are you using? I have heard from people

that

>> > this what you are describing is happening with e-accelerator,

>> > personally

>> > I never had a problem with APC.

>>

>> We are using eAccelerator on that (development) system. The answer hit

>> me during lunch as I was mulling around how it was possible that two

>> identical calls to the exact same functions could produce different

>> results. Thinking about what could possibly be different from one

>> request to another, it occurred to me that it had to be the caching.

>>

>> The production servers are using the Wincache extension, so I don't

>> know how it might impact them.

>>

>> > However I should really update the documentation, the WSDL is not

>> > something

>> > to be generated dynamically upon each request, static serving is much

>> > better (of course if you keep it in sync with your real server

>> > implementation).

>>

>> I figure when this hits production I'll probably switch to a static

>> document, but this was my first look at SOAP and I just wanted to see

>> how it would fit into a project I'm developing right now. Auto

>> discovery was ideal because it allowed me to experiment easily with

>> creating different functions with different parameters and return

>> types.

>>

>> Andrew

>>

[Andrew Ballard]

On Fri, Jun 25, 2010 at 9:51 AM, robert mena <[hidden email]> wrote:
> Hi,
> I ma facing the same problem (all my calls return null) and I am using
> e-accelerator.   While changing to APC is possibile I can't do it right now.
> Is there any workaround? I've disabled the cache of wsdl in ini and removed
> the /tmp/wsdl-* cache file.
>

The issue is not related to any of the soap.wsdl_cache* config
settings. The problem is that the PHP files that are being analyzed by
Zend_Soap_AutoDiscover have been cached by e-Accelerator's op-code
cache. The first time a file is loaded into PHP, the auto discovery
works as expected because PHP is working with the actual source code
that includes the phpDoc-block comments that describe the API you are
publishing via SOAP. However, subsequent requests will grab those
files from the op-code cache, which does not contain the comments.

You have to make sure that eAccelerator is not caching the PHP file(s)
that define the API being discovered by Zend_Soap_AutoDiscover
(probably by using the eaccelerator.filter config). Of course by doing
this, you lose all the benefit of op-code caching on those specific
files. Depending on how wide you have to cast the net in your filter,
that could pretty well negate any benefit of having an op-code cache.

Ideally, your WSDL file should be a static document in your production
system anyway. You can use still use the auto discover method to build
the file without disabling anything in e-Accelerator as long as you
clear e-Accelerator's cache of the source file(s) and then immediately
grab the generated WSDL document and save it to an XML file. Once
you've saved it, publish that file somewhere in your web root and then
point all your SOAP clients to the URI for the static file.

Andrew

[weierophinney]

-- Andrew Ballard <[hidden email]> wrote
(on Friday, 25 June 2010, 10:28 AM -0400):

> On Fri, Jun 25, 2010 at 9:51 AM, robert mena <[hidden email]> wrote:
> > I ma facing the same problem (all my calls return null) and I am using
> > e-accelerator.   While changing to APC is possibile I can't do it right now.
> > Is there any workaround? I've disabled the cache of wsdl in ini and removed
> > the /tmp/wsdl-* cache file.
>
> The issue is not related to any of the soap.wsdl_cache* config
> settings. The problem is that the PHP files that are being analyzed by
> Zend_Soap_AutoDiscover have been cached by e-Accelerator's op-code
> cache. The first time a file is loaded into PHP, the auto discovery
> works as expected because PHP is working with the actual source code
> that includes the phpDoc-block comments that describe the API you are
> publishing via SOAP. However, subsequent requests will grab those
> files from the op-code cache, which does not contain the comments.
>
> You have to make sure that eAccelerator is not caching the PHP file(s)
> that define the API being discovered by Zend_Soap_AutoDiscover
> (probably by using the eaccelerator.filter config). Of course by doing
> this, you lose all the benefit of op-code caching on those specific
> files. Depending on how wide you have to cast the net in your filter,
> that could pretty well negate any benefit of having an op-code cache.

One option you might consider is using an opcode cache that doesn't
strip out th docblock comments. Neither APC nor Zend Server do so --
they keep all information related to a class, including the docblocks.
Alternately, put in a feature request to eaccelarator to stop stripping
docblocks on code stored in the opcode cache (or provide an option to
disable this "feature"). The argument they make is that it increases RAM
usage if they aren't stripped; however, the amount of RAM they consume
is actually fairly negligible, and RAM is cheap.

> Ideally, your WSDL file should be a static document in your production
> system anyway. You can use still use the auto discover method to build
> the file without disabling anything in e-Accelerator as long as you
> clear e-Accelerator's cache of the source file(s) and then immediately
> grab the generated WSDL document and save it to an XML file. Once
> you've saved it, publish that file somewhere in your web root and then
> point all your SOAP clients to the URI for the static file.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc