appserver-io/appserver

A multithreaded application server for PHP, written in PHP.

jefkin

@jefkin

to extend that thought; service appserver restart is pretty monolithic :)

Tim Wagner

@wagnert

There are several options, but depending on your requirements this can be the better one. We call it appserver-runner and it only starts one application. I'll extend the documentation the next days, so you'll get an better understanding what i'm talking about :-)

jefkin

@jefkin

nice :) and thanks

jefkin

@jefkin

and regarding the issue we were having, we have unambiguously identified the problem the run() function we were calling from the servlet side, ... on the service side was defined with a signature of public function run(&$args = array ( ), &$dates = array ( )) ... the '&' references killed it, removed them and got dial tone again. So we'll have to do a bit of data stuffing to pass the updated info we needed in $args and $date, into our return result. Lesson learned is you can't use reference arguments across the two sides of the equation :D

jefkin

@jefkin

So now a completely different type of error, I have a stateless enterprise bean class, that my service needs access to. The stateless class is defined in the common location (./common/Vendor/Project/Utilities/ArgHandler.php) of my app, and I'm declaring it like

use Vendor\Project\Utilities\ArgHandler;

class PingService extends AbstractProcessor
{

... clipped out

 /**
  *  The Argument Handler for DB queries.
  *
  * @var Vendor\Project\Utilities\ArgHandler;
  * @EnterpriseBean(name="ArgHandler")
  */
 protected   $argHandler;

... clipped out

protected function run($args   =   array ( ),  $dates  =   array ( ))
{

... clipped out

    $this->argHandler->default_handle($dates);

... clipped out

}

This is throwing an error with a backtrace to this point that reports:
[2019-05-17 19:30:40] - host.com (error): PHP Exception: exception 'Exception' with message 'Requested value php:global/combined-appserver/project/ArgHandler has not been bound to naming directory php:' in /opt/appserver/src/AppserverIo/Appserver/Naming/NamingDirectory.php:213
Stack trace:

#0 /opt/appserver/src/AppserverIo/Appserver/Application/Application.php(804): AppserverIo\Appserver\Naming\NamingDirectory->search('php:global/comb...', Array)

#1 /opt/appserver/src/AppserverIo/Appserver/PersistenceContainer/BeanManager.php(497): AppserverIo\Appserver\Application\Application->search('ArgHandler', Array)

#2 /opt/appserver/vendor/appserver-io/rmi/src/AppserverIo/RemoteMethodInvocation/LocalContextConnection.php(123): AppserverIo\Appserver\PersistenceContainer\BeanManager->invoke(Object(AppserverIo\RemoteMethodInvocation\RemoteMethodCall), Object(AppserverIo\Collections\ArrayList))

#3 /opt/appserver/vendor/appserver-io/rmi/src/AppserverIo/RemoteMethodInvocation/ContextSession.php(189): AppserverIo\RemoteMethodInvocation\LocalContextConnection->send(Object(AppserverIo\RemoteMethodInvocation\RemoteMethodCall))

#4 /opt/appserver/vendor/appserver-io/rmi/src/AppserverIo/RemoteMethodInvocation/RemoteProxy.php(134): AppserverIo\RemoteMethodInvocation\ContextSession->send(Object(AppserverIo\RemoteMethodInvocation\RemoteMethodCall))

#5 /opt/appserver/vendor/appserver-io/rmi/src/AppserverIo/RemoteMethodInvocation/RemoteProxy.php(121): AppserverIo\RemoteMethodInvocation\RemoteProxy->invoke(Object(AppserverIo\RemoteMethodInvocation\RemoteMethodCall), Object(AppserverIo\RemoteMethodInvocation\ContextSession))

#6 /opt/appserver/var/tmp/localhost/project/cache/Vendor_Project_Services_PingService.php(990): AppserverIo\RemoteMethodInvocation\RemoteProxy->call('default_handle', Array)

#7 /opt/appserver/var/tmp/localhost/project/cache/Vendor_Project_Services_PingService.php(990): AppserverIo\RemoteMethodInvocation\RemoteProxy->default_handle(Array)

#8 /opt/appserver/var/tmp/localhost/project/cache/Vendor_Project_Services_PingService.php(2065): Vendor\Project\Services\PingService->runDOPPELGAENGEROriginal(Array, Array)

...
I have a few ideas about this, but the first thing I'm going to try is moving it out of the common directory and into META-INF

jefkin

@jefkin

that seemed to solve the hassle, I imagine I have to do something to tell appserver.io to look in the common subdirectory instead of META-INF.

Tim Wagner

@wagnert

Hi, i‘ll have a look at it tomorrow 🙂

jefkin

@jefkin

If I have an application 'project' then it's easy to make all servlets respond to queries at 127.0.0.1:9080/project/something/other/stuff; I can easily change the port if needed, but what if I want servlets in project to respond to 127.0.0.1:9080/something/other/stuff; e.g. without the 'project' string appearing in the route, is that doable?

jefkin

@jefkin

my point is I want another parallel servlet in project to respond to 127.0.0.1:9080/that-thing/other/stuff, and a third, etc up to 17 of these guys, built for another platform that respond to disparate urls on the old platform, that lack a unique 'project' element in the url. I mean I guess we could have 17 projects on the appserver.io, but that seems inefficient.

jefkin

@jefkin

I suppose we could do some url rewriting to make that work?

jefkin

@jefkin

also, while I'm on it, if I have 127.0.0.1:9080/project/something/other/stuff as a query, to make it work in appserver.io right now I'm adding '.do' on the end manually, so my Servlet has a route annotation like: @Route(name="StuffService", urlPattern={"/something/other/stuff.do"}) -- If I change it to @Route(name="StuffService", urlPattern={"/something/other/stuff"}) appserver.io fails to find the servlet, I read a doc that said something like "we use '.do' to signal a servlet" ... can we just pop an arbitrary pattern into the works some how and have it land on the servlet? I'm leary to try and mess with the redirects directly, without a firmer understanding of what I'm meddling with.

jefkin

@jefkin

I did try adding a WEB-INF/web.xml with :

<servlet-mapping>
    <servlet-name>helloWorld</servlet-name>
    <url-pattern>/happyday</url-pattern>
</servlet-mapping>

but that didn't work. I think the rewrite might be my only option, but I can't seem to find a good example to go by.

Tim Wagner

@wagnert

@jefkin Sorry for my late answer, but i was really busy on weekend :-( Yes, Enterprise Beans have to be located in the META-INF directory in general, but this can be overwritten in configuration (META-INF/context.xml) if needed. Regard the URL rewriting have a look at our documentation. By default, we use the .do suffix to let the webserver identify if the request has to be handled by the webserver or the servlet engine. This can be configured in the <APPSERVER-ROOR>/etc/appserver/appserver.xml file. It should be no problem to add an additional suffix if needed. Beside this, you can define wildcards in the pattern, to do this use the * character. I'm not completely understand what you want to achieve, but the URL rewriting feature in combination with the wildcard pattern and the file suffix i think nearly everything should be possible.

jefkin

@jefkin

I think despite all my text here that I was confusing the matter, I sent an email with the actual problem and what I think might be a solution.

Tim Wagner

@wagnert

Rewriting is the special topic of @wick-ed, so i'll discuss that tomorrow morning with him, hope that is o. k.?

jefkin

@jefkin

sure thing, thanks

Bernhard Wick

@wick-ed

Hi there @jefkin

I had a look at your rewrites

looks good to me

jefkin

@jefkin

Oh, good news, I will try it out later today and let you know if something seems amiss :)

Bernhard Wick

@wick-ed

I only see an issue with the order of the conditions?

Is it ok to discuss it here?

jefkin

@jefkin

sure

but we could take it to private to prevent clutter, unless you think it's better here

Bernhard Wick

@wick-ed

I assume the first condition will always match, and the second one will never apply

lets make it private

jefkin

@jefkin

I have a logger question, my app defined a few logger entries in META-INF/context.xml the first was a servlet logger, and my servlet has been able to use it with a dependency injected -> protected $application; and a simple access function like: return $this->application->getLogger('servlet');
This created my log file and I was able to happily log to it. So I wanted to do the same thing on the service side, specifically to seperate out soap logs from the rest of the logs so I added a soap logger to META-INF/context.xml. Now, I extend all my services from a copy of the Example App's AbstractProcessor class, and each service has an entry in META-INF/epd.xml for injecting the application interface .. I've used this application interface for system logging with $this->getInitialContext()->getSystemLogger()->info($text); and this worked fine, but to the system log. getInitialContext() is defined as: return $this->getApplication()->getInitialContext(); and getApplication() is defined as return $this->application; So I figured I could get to my configured 'soap' log with public function getSoapLogger() { return $this->getApplication()->getLogger('soap'); }
SO then my AbcService has $this->getSoapLogger()->info($soap_request);
However this generates the application error log entry
[2019-05-27 21:27:48] - host.com (error): PHP Fatal Error: Call to a member function info() on null in /opt/appserver/var/tmp/localhost/mno/cache/Provider_Project_Services_AbcService.php on line 231 []
Is there something I have to do to get the Service side Application to be aware of the Log files?

Tim Wagner

@wagnert

@jefkin Hm, did you register the soapLogger int the context.xml file? If yes, please post the XML with the registration here :-)

jefkin

@jefkin

ok here:

<?xml version="1.0"?>

<context xmlns="http://www.appserver.io/appserver" name="wssap" type="AppserverIo\Appserver\Application\Application">
<loggers>
<logger channelName="soap" name="Soap" type="\AppserverIo\Logger\Logger">
<handlers>
<handler type="\AppserverIo\Logger\Handlers\CustomFileHandler">
<formatter type="\AppserverIo\Logger\Formatters\StandardFormatter"/>
<params>
<param name="logFile" type="string">var/log/${webapp.name}-soap.log</param>
<param name="logLevel" type="string">info</param>
</params>
</handler>
</handlers>
</logger>
<logger channelName="servlet" name="servlet" type="\AppserverIo\Logger\Logger">
<handlers>
<handler type="\AppserverIo\Logger\Handlers\CustomFileHandler">
<formatter type="\AppserverIo\Logger\Formatters\StandardFormatter"/>
<params>
<param name="logFile" type="string">var/log/${webapp.name}-servlet.log</param>
<param name="logLevel" type="string">info</param>
</params>
</handler>
</handlers>
</logger>
</loggers>
</context>

note that I just coppied the lines for servlet that work to soap, if there was something more I was supposed to add, it eluded me.

Oh I do see a difference, the name tag in soap is name="Soap", so should i be trying to get the loger by the channelName? or the name?

Tim Wagner

@wagnert

Did you test to set the name from uppercase Soap to soap as you use soap to load the logger :-D

I think it's the name :-)

jefkin

@jefkin

trying that now ;)

Tim Wagner

@wagnert

Yea, keep us updated :-)

jefkin

@jefkin

shweeet! that was the ticket.

so we load by name="" so 'Soap' in this case

Tim Wagner

@wagnert

Perfect, like to hear that :-)

jefkin

@jefkin

nice

jefkin

@jefkin

I see that app.io 1.1.4 is still PHP 5, is there a pathway to upgrading to PHP 7? My team found this link: appserver-io/webserver#202 which hints it's possible, but it would be a very big boon if we had a known path to follow for this.

Tim Wagner

@wagnert

Yes, it's still PHP 5.6 and we actually have no concrete plan for upgrading to PHP 7 as Joe Watkins is actually working on a new extension called parallel and he recommends to use it in a recent blog post when thinking about multithreading and PHP. We'll evaluating it during the next weeks regarding appserver.io requirements and how we can use it for our purposes ... so it'll take a while for sure to upgrade it to PHP 7

Troy Rudolph

@troy-rudolph

Hello. At Alchemy Systems, we are looking for a message queuing/handling solution for our LAMPR-based applications. Appserver seems to fit our needs. Before we can introduce it into our stack, we need some additional information.

1) It sounds like Appserver does not run on PHP 7. I do see some references to PHP 7 in the code, but the threads here indicate that Appserver still required PHP 5.6. Is that correct?
2) We would like to find, if possible, some people to ask about the use of AppServer in high-volume production environments. Do any of you know of someone we can speak with?
3) Roughly how many users (companies) are using Appserver?
4) Is there a working example of using STOMP in an external application to post messages to the Appserver queues?
5) Is there a product roadmap?
6) When will the next release be?

I know this is a long list, but we do need to "sell" this idea to our architecture team before proceeding.

Thank you in advance for your help.

Tim Wagner

@wagnert

Hi @troy-rudolph,

I'm happy to see that you're interested in appserver.io. I'll answer your questions as follows:

Yes, appserver.io only supports 5.6 actually (only the webserver itself should also run with PHP 7.2, last tested a year ago - https://hub.docker.com/r/appserver/webserver)
We've some customers that run appserver.io in production like https://www.proffile.de/app/ or https://lab.report/app/#/account/login and both have some traffic but it's for sure not a high-volume production environment. Besides that, we're not really aware who is using appserver.io
Not too much I think, although we've 10.000+ downloads on Github which doesn't mean anything
No, we don't have a STOMP implementation, appserver.io comes with its own client implementation
It's an Open Source project and we don't have a concrete roadmap. Actually, we're working on an internal project that is based on appserver.io and we plan to update it during the next year, but we don't have a concrete plan for that
We release patch releases (actually only in form of Docker containers https://cloud.docker.com/u/appserver/repository/docker/appserver/dist) when we need an update for our own project, but within the next month there should also be updates on our Debian repositories as well as a Mac version (hopefully on Homebrew)

I think this is not what you want to hear, but I hope it gives you a brief impression of what you're dealing with ;)

Troy Rudolph

@troy-rudolph

Do you guys have a list of things that must be done to make the server run on PHP 7? If so, I might be able to do some of it for you in my spare time. Thanks.

Tim Wagner

@wagnert

The problem is, that we‘llneed a replacement for pthreads 🙁 We‘re thinking of pht or something like this. We need to evaluate functionality before we can start refactoring for sure. So your help will be appreciated very much 🙂

Thomas

@alpham8

Hi guys 👋

@wagnert Why do you need an replacement for pthreds? It also works in PHP 7 and as usual, you have to compile it on your own. Maybe pecl support is given, but I'm not sure about this

Tim Wagner

@wagnert

Hi @alpham8 Joe Watkins had stopped working on pthreads. As far as we know, it's not working on PHP 7.3+, so it doesn't make sense to count on a library that is definitely dead :( If you have any alternatives or know guys that keep working on pthreads, it'll be possible to stay with it :-)

Thomas

@alpham8

@wagnert Indeed it works with PHP 7.4. But not for future versions of PHP because of the design as he said in his closing note issue: https://github.com/krakjoe/pthreads/issues/929#issue-410636734

However, he is the project owner of "parallel" and he said that this is the future replacement of pthreads. But personally for me it doesn't feel like a replacement, because many functions and features of the C pthreads API are missing here

Where communities thrive

People

Repo info

Activity

... clipped out

... clipped out

... clipped out

... clipped out

... clipped out