So, no... it does not use intercall. I guess the benefits would be:
-No Windows Server (if you consider this a benefit) -Simple -No UniObjects (if you consider this a benefit) -Cross Platform -You could still use Windows server if you wanted (Apache runs on Windows Server too) (Maybe that might be a requirement for your .NET stuff) The cons might be: -Half a millisecond slower -No pooling (Unless you could do some cool stuff with apache) -"Not the official way to do it" -Not supported by Rocket I guess On Thu, Dec 1, 2011 at 3:26 PM, John Thompson <[email protected]>wrote: > Kevin's idea of using Apache as the connector and php as the scripting > language... > > Works like so... > And Kevin can chime in if I get something wrong, because I certainly did > not architect this. > > Imagine this scenario. > > -A Linux Web Server running Apache > -A U2 server (with some form of nix) also running Apache > -A php script on the Linux Web Server sends a http request with some data > and a U2 subroutine name to the U2 server. > -A php script on the U2 server receives this request and fires a U2 > session, which then calls a subroutine, takes the data, writes out a > result, and then logs off. > -The Linux Web Server then gets the request back and presents it to the > user. > > So really all you are doing, is sending http requests to the U2 server and > getting a response back. Pretend that two web servers are communicating > (i.e. curl, etc.). However, they are on the local network sitting next to > each other in this case. > > In the login Paragraph of the account you want to use, you have to write > some code to detect some nix environment variables that are set telling U2 > that it will be an Apache session (you create your own) so that any menus > or whatever don't get called. > > So in essence, instead of using UniObjects, you are using Apache, and > shelling U2 processes as you need them. > > However, you eluded to the fact that your requests take 300 ms or so. > These requests usually take around 800 ms to 1 sec (at least on my 5 year > old AIX box using firebug). > > I have never worked with UniObjects for java. It sounds like the previous > poster has had some good success with it. > > I think Kevin's goals in this scenario above, were to keep it simple, and > make it cross platform, while still getting good performance. I just > happened, to stumble into him at a conference and have been borrowing the > idea. So I'll leave Kevin to comment on any further details that I did not > cover, or may have covered poorly. > > > On Thu, Dec 1, 2011 at 2:57 PM, Symeon Breen <[email protected]> wrote: > >> So how does the php script connect into unidata ? Is it using intercall ? >> if so it is exactly the same mechanism as uniobjects (via unirpcd) so what >> would the benefit be ? >> >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of John Thompson >> Sent: 01 December 2011 17:48 >> To: U2 Users List >> Subject: Re: [U2] Unidata 7.1 Unresponsive UO Connection >> >> I thought I would chime in here a little... as I've been using Kevin's >> idea >> to create some web applications (none of which are live, except for a few >> management reports- not because I've had problems, but, mainly because >> priorities keep changing - if you know how that goes) >> >> At any rate. I have a management report that pops up on an >> Ipad/Iphone/Droid or whatever. >> The UV process that gets fired goes in and grabs Sales data for 30 store >> locations and spits it back. >> >> Using firebug, I can see how long the php script that calls the UV process >> takes. >> It does its reads, etc., and then bottles up the data and sends back a >> string (1.2 KB in size) in JSON or XML or whatever in around 800 ms to 1 >> second consistently. >> >> So I guess thats consistent with what you were saying. Just thought I >> would >> add to the info. >> >> However, I did notice that UV on AIX is limited to 256MB of RAM per >> session. >> So I wonder if Linux would behave differently? >> >> Ironically, I'm in the process of setting up a UV Linux machine for our >> production system, because AIX 5 support is ending soon. So I guess I'll >> find out soon enough. >> >> On Thu, Dec 1, 2011 at 11:36 AM, Symeon Breen <[email protected]> wrote: >> >> > Similarly here - I have two web services that my apps connect to - one >> > is pooled, the other not. Typical time for a transaction using the >> > pooled one is between 300 and 600 ms, whereas the non pooled for the >> > same transaction is between 1 and 2. >> > >> > I have 2 because my apps connect to the pooled web service with a 2 >> > second timeout, then fail over to the non pooled. I have to do this >> > cos the pooled connections hang several times a day (hence why I have >> > to restart unirpcd and kill off the pooled udt processes) The problem >> > is not in the DB code as it happens randomly and with our logging it >> > is definitely coming out of the DB code and then refuses to accept any >> > more data on the socket, and the .net code is very simple, so it must >> > be in the uniobjects layer or unirpcd. I have tried several dll's to >> > no avail, so we will have to get a new linux box >> > with the very latest udt and see how that goes. Long sigh ..... >> > >> > >> > >> > >> > >> > >> > >> > >> > -----Original Message----- >> > From: [email protected] >> > [mailto:[email protected]] On Behalf Of Holt, Jake >> > Sent: 01 December 2011 15:12 >> > To: U2 Users List >> > Subject: Re: [U2] Unidata 7.1 Unresponsive UO Connection >> > >> > Did you do any actual testing on that to confirm it? I created a WCF >> > web service that manages a set of shared connections for all of my >> > .net apps that access UniVerse. I found that starting the session >> > took much longer then processing most of my requests if the session was >> already open. >> > >> > -----Original Message----- >> > From: [email protected] >> > [mailto:[email protected]] On Behalf Of Kevin King >> > Sent: Wednesday, November 30, 2011 8:00 PM >> > To: U2 Users List >> > Subject: Re: [U2] Unidata 7.1 Unresponsive UO Connection >> > >> > Not focusing on connection pooling at this point but that may be a >> > consideration for the future. I've found that the overhead of the two >> > Apache method is so small that most of the gains offered by connection >> > pooling are minimized. >> > _______________________________________________ >> > U2-Users mailing list >> > [email protected] >> > http://listserver.u2ug.org/mailman/listinfo/u2-users >> > _______________________________________________ >> > U2-Users mailing list >> > [email protected] >> > http://listserver.u2ug.org/mailman/listinfo/u2-users >> > ----- >> > No virus found in this message. >> > Checked by AVG - www.avg.com >> > Version: 10.0.1411 / Virus Database: 2102/4049 - Release Date: >> > 11/30/11 >> > >> > _______________________________________________ >> > U2-Users mailing list >> > [email protected] >> > http://listserver.u2ug.org/mailman/listinfo/u2-users >> > >> >> >> >> -- >> John Thompson >> _______________________________________________ >> U2-Users mailing list >> [email protected] >> http://listserver.u2ug.org/mailman/listinfo/u2-users >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 10.0.1411 / Virus Database: 2102/4050 - Release Date: 12/01/11 >> >> _______________________________________________ >> U2-Users mailing list >> [email protected] >> http://listserver.u2ug.org/mailman/listinfo/u2-users >> > > > > -- > John Thompson > -- John Thompson _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
