print/echo in closure leads to NullPointerException about mod-lang-php HOT 8 CLOSED

Ok it seems, that it is set by quercus NativeMethodAccessor

from mod-lang-php.

It's not an Quercus bug.The WriteStream will be closed but still stored in the Handler. Thats why a Nullpointer is thrown, when a message has been retreived.

Here env has being set:
https://github.com/CansaSCityShuffle/vertx-php/blob/test-print-in-proc/src/main/java/com/blankstyle/vertx/php/Handler.java#L47

Than Quercus is closing the WriteStream, because the registerHandle Method returns...

Tomorrow I hopefully can fix this bug, by creating a new outbuffer, or new context or whatever....

from mod-lang-php.

Yeah, I hadn't moved the issue to the new queue. This needed to be re-posted, so thanks.

So, it looks like you made progress on this? It makes sense that this would be an issue with the handler implementation since it's an issue with closures (the PHP implementation of handlers) specifically.

Maybe I'll take a crack at this as well.

from mod-lang-php.

Okay, I understand what you're saying. I played around with it a little bit and couldn't come up with an immediate solution. The challenge is being able to maintain the WriteStream without having to rebuild too many objects each time a closure is encountered.

I'm on my honey moon for the next couple of weeks, but if you can come up with any solution for this I'll will definitely commit it, or send a PR and I will gladly accept it. In the mean time, I will be working out a few other module-related issues to try to get the module ready for an early release.

from mod-lang-php.

Ok i've starred at the Quercus source some time, trying to set the Buffer, the WriteStream, restoring the Environment but nothing of that is working or would be a good practice.

Because of that and #2 I think the best way would be extending the QuercusEngine by the PhpVerticleFactory (or at least make the PhpVerticleFactory implement the execute Method).

That would help us:

1. sharing the QuercusContext and global Environment with all the other Verticles deployed by the same ClassLoader
2. keep the WriteStream open as long as we need it
3. clean up the Context, Environment and WriteStream by ourself when we need it. (By adding finalize() Methods)
4. also it would hopefully fix the java.lang.OutOfMemoryError in https://github.com/CansaSCityShuffle/vertx_php_ping/tree/comment_print_to_prevent_write_stream_exception when running mvn integration-test

If that's fine for you, I would start a PR for that, experimenting with this approach

from mod-lang-php.

Yep, it seems we should be able to knock out a few of the most important issues by playing with how we can manage the Quercus engine/context within the PhpVerticleFactory implementation. #2 is definitely important in order to support the Vert.x module system, and it's obvious there needs to be a single Quercus engine/context for all verticles created within a single PhpVerticleFactory.

A PR for this would be amazing! :-)

from mod-lang-php.

@jordanhalterman done hopefully you are ok with my solutions

from mod-lang-php.

Merged and closed :-)

from mod-lang-php.