calling an updateroutine in all running agents

Posted by agent_008_nl on 13-Sep-2012 01:46

Hi,

OE 11.0, statefree appserver. After updating some data in the database I would like to reload some temp-tables in a datacontainer class on all running agents as fast as possible. This container loads the temp-tables at first at startup of the agent. For agents in use I could use the disconnect procedure (add a check on some flag and if true call the reload), but what would be a neat way to update the free agents? I want to avoid reloading at connect of the agent because of the slowdown.

  Using asbman I should be able to get all ports of running agents. I could call them directly using the -directConnect parameter.  I would like to call asbman from the abl, something like input through value("C:\Progress\OpenEdge\Bin\asbman.bat -host 10.1.0.15 -port 20394 -u stefan -i ASDemo -q")

But now I do not see a parameter for the adminserver password? Is there one or is there another way to get the ports?

--
Kind regards,

Stefan Houtzager

Houtzager ICT consultancy & development

www.linkedin.com/in/stefanhoutzager

All Replies

Posted by Admin on 13-Sep-2012 01:57

>  I would like to call asbman from the abl, something like input through

value("C:\Progress\OpenEdge\Bin\asbman.bat -host 10.1.0.15 -port 20394 -u stefan -i ASDemo -q")

But now I do not see a parameter for the adminserver password? Is there one or is there another way to get the ports?

I'd solve this slightly different. As AppServers typically have DB connection, you can use a database sequence as a signal that the cache needs to be refreshed. AppServers can check at the beginning of each request if the sequence value has changed and update the data then.

I'm not sure, if -directConnect is really bypassing the AppServer broker and calling directly into an agent. My understanding is, that -directConnect bypasses the name server and goes directly to the broker. That wouldn't help you at all if you need to execute something on every agent.

Posted by agent_008_nl on 13-Sep-2012 02:14

Thanks for your reply Mike,

I could do that (and will have to if there is no better solution), but as I stated in the original question "I want to avoid reloading at connect of the agent because of the slowdown.".

Regards, Stefan.

Posted by agent_008_nl on 13-Sep-2012 03:28

> My understanding is, that -directConnect bypasses the name server and  goes directly to the broker. That wouldn't help you at all if you need  to execute something on every agent.

I've just read that somewhere else too. It would be nice if there was a -directAgentConnect parameter then.

Posted by rbf on 13-Sep-2012 16:50

After just having implemented Julian's STOMP classes with ActiveMQ I have realized that this is an ideal way to approach this problem.

The AppServer agents subcribe to a queue where you publish the event/message that instructs them to renew their cache.

Posted by Admin on 13-Sep-2012 23:12

The AppServer agents subcribe to a queue where you publish the event/message that instructs them to renew their cache.

Does the Stomp operation allow the agents to execute code (the cache refresh) in idle times?

Posted by rbf on 14-Sep-2012 02:54

mikefe wrote:

The AppServer agents subcribe to a queue where you publish the event/message that instructs them to renew their cache.

Does the Stomp operation allow the agents to execute code (the cache refresh) in idle times?

It is just an event that gets handled only when the agent is idle I suppose.

Posted by agent_008_nl on 14-Sep-2012 09:32

Thanks Peter,

Looks promising. As soon as I have time I'll test and post a message here. I think this is interesting for others too.

Groeten, Stefan.

Posted by agent_008_nl on 22-Sep-2012 04:50

Downloaded Julians adapter and played a bit with the tweet functionality. I would like to send a tweet to idle appserveragents to refresh their caches. A call to some different prowin32 sessions is no problem, but the appserveragents do not seem to hear anything. Listening they are, I can see that in the
activemq topics. I share  Marian's suspicion that the agents wait-for connect of their server sockets. So this seems not possible.

Posted by rbf on 24-Sep-2012 02:09

agent_008_nl wrote:

Downloaded Julians adapter and played a bit with the tweet functionality. I would like to send a tweet to idle appserveragents to refresh their caches. A call to some different prowin32 sessions is no problem, but the appserveragents do not seem to hear anything. Listening they are, I can see that in the
activemq topics. I share  Marian's suspicion that the agents wait-for connect of their server sockets. So this seems not possible.

That is a disappointment! I had several use cases for this.

The explanation makes sense though.

P.S. Where dit Marian express this suspicion?

Posted by jmls on 24-Sep-2012 04:03

mmm. ok. it works in webspeed : this is a snippet of code from the startup procedure of a webspeed agent

[snip]

/* Wait for a web-request to come in */

WAIT-FOR-BLOCK:

repeat on error undo WAIT-FOR-BLOCK, leave WAIT-FOR-BLOCK

       on quit  undo WAIT-FOR-BLOCK, leave WAIT-FOR-BLOCK

       on stop  undo WAIT-FOR-BLOCK, next  WAIT-FOR-BLOCK:

  StompClient1  = new dotr.Stomp.StompClient().

  StompClient1:SubscribeToQueue("test").

  StompClient1:Subscribe(this-procedure).

wait-for "WEB-NOTIFY":U of default-window.

end. /* WAIT-FOR-BLOCK: REPEAT... */

apply "close":U to hWebStart.

procedure NewStompMessage:

  def input parameter p_StompMessage as dotr.Stomp.StompMessage no-undo.

  message "NEW STOMP MESSAGE ==>" + string(p_StompMessage:Body).

end procedure.

[snip]

and here is the agent log file

[12/09/24@09:56:11.529+0100] P-006224 T-007480 1 WS -- (Procedure: 'SocketBigReadHandler dotr/Stomp/stompSocketProc.p' Line:156) MESSAGE 

[12/09/24@09:56:11.529+0100] P-006224 T-007480 1 WS -- (Procedure: 'SocketBigReadHandler dotr/Stomp/stompSocketProc.p' Line:156) content-type:text/plain 

[12/09/24@09:56:11.529+0100] P-006224 T-007480 1 WS -- (Procedure: 'SocketBigReadHandler dotr/Stomp/stompSocketProc.p' Line:156) message-id:ID\cjmls-study-49158-1348366765868-2\c6\c-1\c1\c1 

[12/09/24@09:56:11.529+0100] P-006224 T-007480 1 WS -- (Procedure: 'SocketBigReadHandler dotr/Stomp/stompSocketProc.p' Line:156) destination:/queue/test 

[12/09/24@09:56:11.529+0100] P-006224 T-007480 1 WS -- (Procedure: 'SocketBigReadHandler dotr/Stomp/stompSocketProc.p' Line:156) timestamp:1348476971459 

[12/09/24@09:56:11.529+0100] P-006224 T-007480 1 WS -- (Procedure: 'SocketBigReadHandler dotr/Stomp/stompSocketProc.p' Line:156) expires:0 

[12/09/24@09:56:11.529+0100] P-006224 T-007480 1 WS -- (Procedure: 'SocketBigReadHandler dotr/Stomp/stompSocketProc.p' Line:156) subscription:c6a8f05a-9510-15a1-e211-25066f444f7d 

[12/09/24@09:56:11.529+0100] P-006224 T-007480 1 WS -- (Procedure: 'SocketBigReadHandler dotr/Stomp/stompSocketProc.p' Line:156) priority:4 

[12/09/24@09:56:11.529+0100] P-006224 T-007480 1 WS -- (Procedure: 'SocketBigReadHandler dotr/Stomp/stompSocketProc.p' Line:156)  

[12/09/24@09:56:11.529+0100] P-006224 T-007480 1 WS -- (Procedure: 'SocketBigReadHandler dotr/Stomp/stompSocketProc.p' Line:156)  

[12/09/24@09:56:11.529+0100] P-006224 T-007480 1 WS -- (Procedure: 'SocketBigReadHandler dotr/Stomp/stompSocketProc.p' Line:156) hello 

[12/09/24@09:56:11.530+0100] P-006224 T-007480 1 WS -- (Procedure: 'NewStompMessage debtnetdirect/asterisk.p' Line:629) NEW STOMP MESSAGE ==>hello 

as you can see, there are several entries to show that a message was received and processed

and this was from the stomp web page

NameNumber Of Pending MessagesNumber Of ConsumersMessages EnqueuedMessages DequeuedViewsOperations
test0611Browse Active Consumers
Send To Purge Delete

6 consumers = 5 webspeed agents, 1 chat client from the chatwindow.w demo

I'll see what happens with appserver agents

Posted by Admin on 24-Sep-2012 04:13

wait-for "WEB-NOTIFY":U of default-window.

WebSpeed uses a regular 4GL WAIT-FOR statement for waiting for requests.

On the AppServer this is part of the "hidden" implementation. As the AppServer is executing the activate and deactivate procedures without any traceable calling procedure as part of every request I'd say that the request handling for the AppServer is built into the AppServer core.

In that case, there is probably little you can do to influence this.

When you're using the AppServer to handle Sonic MQ requests, you are using an ABL startup procedure on the AppServer that contains the Sonic WaitForMessages WAIT-FOR. But in that case the AppServer can only handle Sonic requests and no longer standard AppServer requests.

Posted by Admin on 24-Sep-2012 04:36

mikefe wrote:

WebSpeed uses a regular 4GL WAIT-FOR statement for waiting for requests.

On the AppServer this is part of the "hidden" implementation. As the AppServer is executing the activate and deactivate procedures without any traceable calling procedure as part of every request I'd say that the request handling for the AppServer is built into the AppServer core.

In that case, there is probably little you can do to influence this.

When you're using the AppServer to handle Sonic MQ requests, you are using an ABL startup procedure on the AppServer that contains the Sonic WaitForMessages WAIT-FOR. But in that case the AppServer can only handle Sonic requests and no longer standard AppServer requests.

Even in AppServer the actual agent is a 4GL session that has to wait-for on something, my fear is that it just wait for connect on it's server-socket... if that wait-for uses a pause option there might be a process-events in the wait loop but as it's only designed to handle requests there is a small chance there is ever a pause in there

Posted by jmls on 24-Sep-2012 04:36

yeah, looks like that is the problem. It seems that the data is pushed to the socket of the appserver agent connection , so it's dequeued from the stomp server, but it is never read by the appserver program

it's a bit cack-handed but could you not set up a webspeed agent to listen for the message, and then call a reload_data procedure on the appserver agent ?

Posted by Admin on 24-Sep-2012 04:48

then call a reload_data procedure on the appserver agent ?

He wants to guarantee that this calls on every AppServer agend in idle time.

Posted by jmls on 24-Sep-2012 04:53

if he runs it x times (x = number of agents) then wouldn't there be a

good chance he'll get all the idle agents ?

On 24 September 2012 10:48, Mike Fechner

Posted by Admin on 24-Sep-2012 04:58

if he runs it x times (x = number of agents) then wouldn't there be a good chance he'll get all the idle agents ?

 

5 agent. 4 busy with a .2 second job each

Then you call that .p 5 times. It will be executed 5 times on the one idle agent - does not help at all.

Posted by jmls on 24-Sep-2012 05:08

He mentioned that the "busy" agents will be automatically reloaded as

soon as they are finished the current job, so we don't need to worry

about those

so, we only need to get the "idle" agents - and this would do that

On 24 September 2012 10:58, Mike Fechner

Posted by agent_008_nl on 25-Sep-2012 05:27

Thanks for your investigation and answer Julian,

I have no idea about webspeed & webspeedagents, but I'll see what I can find out about your suggestion.

--
Kind regards,

Stefan Houtzager

Houtzager ICT consultancy & development

www.linkedin.com/in/stefanhoutzager

Posted by Michael Jacobs on 25-Sep-2012 05:48

Perhaps this information will help:

a) An AppServer agent is not running the ABL language engine when idle, it is waiting solely on (socket) communications from the AppServer broker

b) Running a remote AppServer procedure n-number of times in an attempt to cycle through all the 'idle' agents will almost certainly not produce consistent results

My thought: your best choice is to detect a context change and update inside of an Activate procedure, before the remote procedure begins running.

Mike Jacobs

Posted by Admin on 25-Sep-2012 05:49

Stefan... just because you can doesn't mean you should, remember? that's a new one more appropriate for your case, http://www.rustyarcade.com/uploads/articles/commonsense.jpg

I doubt the cached temp-tables are so large that to give you real performance issues if you just reload on connect if needed.

Posted by Admin on 25-Sep-2012 05:54

mjacobs wrote:

a) An AppServer agent is not running the ABL language engine when idle, it is waiting solely on (socket) communications from the AppServer broker

By that you mean simply that the wait-for used is 'connect' on the agent's socket server (which would indeed block till a new connection is made)... it should be more or less a plain AVM runtime, what other engine the runtime supports apart ABL?

Inquiring minds like to know

Posted by agent_008_nl on 25-Sep-2012 06:03

Maybe I did not understand Julian's answer, not knowing about webspeed. You seem to have an idea about the size of my cache, master Marian? ;-) Well, I'll see about the performance impact if I update on connect. Possible problem for the future is that these updates could increase in size. Would have been nice to eliminate this possibility beforehand.

Regards, Stefan.

Posted by Admin on 25-Sep-2012 06:03

I doubt the cached temp-tables are so large that to give you real performance issues if you just reload on connect if needed.

And if they are, it's a brilliant use case for the multi-tenant AppServer feature (temp-tables shared across AppServer agents) that Progress was thinking about around the development of 11.0.

Posted by jmls on 25-Sep-2012 06:03

is there a way of making the "idlest" agent take the next call ?

I suppose I was wondering what the calling strategy was. random ?

round-robin ? Oldest first ?

Don't forget that the op said that the agents would be updated at the

end of the current call, so he only wanted to get hold of the ones

that weren't running.

On 25 September 2012 11:49, Michael Jacobs

Posted by jmls on 25-Sep-2012 06:03

surely a "wait-for connect" would still operate exactly like any other

wait-for ?

What seems to be suggested is that the avm is not in the wait loop

Posted by Admin on 25-Sep-2012 06:03

a) An AppServer agent is not running the ABL language engine when idle, it is waiting solely on (socket) communications from the AppServer broker

Sometimes I have to hate it, when my observations are just right.

Posted by jmls on 25-Sep-2012 06:03

Hey! that's my line !

Posted by Admin on 25-Sep-2012 06:06

jmls wrote:

Hey! that's my line !

Damn, sorry Sir... always forget to put the citation mark, or is the trademark that have to be used?

Posted by agent_008_nl on 25-Sep-2012 06:07

I must have that future ehh feature as soon as we go multi-tenant!

Posted by Admin on 25-Sep-2012 06:10

agent_008_nl wrote:

You seem to have an idea about the size of my cache, master Marian? ;-) Well, I'll see about the performance impact if I update on connect. Possible problem for the future is that these updates could increase in size.

me knows not, but I try to compensate guessing

maybe you'll venture to look into memcached.org if in the mood for crazy things...

Posted by jmls on 25-Sep-2012 06:13

it's my patent !

I'm an admirer of the way Apple do business so I thought that I would

follow their lead.

Posted by Michael Jacobs on 25-Sep-2012 06:25

Hi Marian,

Good question.   With regards to 'idle', an AppServer agent works very differently from an ABL client or WebSpeed agent.  An AppServer agent is not actively running any ABL procedure when in an idle state; it is actually sitting in an 'C' code idle loop outside of the ABL language interpreter.  So no, the agent is not idling in a 'wait-for' where it can be interrupted, timeout, or handle asynchronous [i/o] operations.  The agent re-enters the language engine when a client's remote procedure request arrives, exists the language interpreter when the remote procedure has completed, and then waits in its idle loop until the next remote procedure or broker operation is received.

I hope that was clearer, 

Mike Jacobs

Posted by jmls on 25-Sep-2012 06:33

It's much clearer, but the question begged to be asked is

"why?"

Why does appserver behave differently to the others ?

On 25 September 2012 12:26, Michael Jacobs

Posted by Admin on 25-Sep-2012 06:34

mjacobs wrote:

I hope that was clearer, 

Mike Jacobs

Thanks Mike, crystal clear... just wondering why the blocking wait-for connect in abl was not used? How hard would be to add a hook abl procedure that can be call by idle agents while waiting for a connection? (mind you this will make the agent 'unresponsible' for external connections, including internal communication with the broker, for the time the hook is being executed)

Posted by agent_008_nl on 25-Sep-2012 06:55

Sounds like a Hannibal quote (the A-team must be your favorite) . You just lit a cigar too and look around like the world is yours, right?

Posted by Admin on 25-Sep-2012 06:58

Sounds like a Hannibal quote (the A-team must be your favorite) .

I have slightly different memories of his quotes.

Posted by Michael Jacobs on 25-Sep-2012 07:21

That is a fair question.   The simple answer: the original archtectural decisions were made before my time at Progress and I do not know the exact answer.   I could cite technical reasons why 'wait-for' would not work well for an AppServer, but that really wouldn't help.   Simply put: the current architecture does not lend itself to real time event processing like what you are looking for.   Mike's answer is a very good one, and Julian's solution I find facinating (I'm still mulling over the potential in that one).

Sorry for the lousy answer,

Mike Jacobs

Posted by jankeir on 27-Sep-2012 04:29

marianedu wrote:

maybe you'll venture to look into memcached.org if in the mood for crazy things...

Have you? (Tried something like that in ABL?)

I had a brief look at using redis once but was under the impression that any gains that could be made were lost due to the overhead of calling external procedure's in DLL's from ABL, although I didn't spent much time trying to optimize it. If anyone has real experience with something like this in abl I'd love to hear about it.

Posted by Admin on 27-Sep-2012 10:47

jankeir wrote:

marianedu wrote:

maybe you'll venture to look into memcached.org if in the mood for crazy things...

Have you? (Tried something like that in ABL?)

I had a brief look at using redis once but was under the impression that any gains that could be made were lost due to the overhead of calling external procedure's in DLL's from ABL, although I didn't spent much time trying to optimize it. If anyone has real experience with something like this in abl I'd love to hear about it.

Nope, but won't be the first time I do crazy things

I know someone who attempted to link using socket access but personally I would go with shared libraries instead, declare the procedures as persistent (keep the DLL loaded) and maybe serialize objects instead of name/value pairs could help.

Posted by gus on 01-Oct-2012 12:13

the blocking wait for connect did not exist when the app server was originally designed. the 4gl socket interface came in 9.1A or thereabouts and the app server was in v8.2 (iirc).

Posted by gus on 01-Oct-2012 12:16

we have not forgotten about that particular problem. i'm hoping we come up with something better than shared temp tables (and we have a few random thoughts). you can already share tables by using temporary databases.

Posted by agent_008_nl on 02-Oct-2012 05:13

With the problem you mean the possible slowness of a reload on connect I suppose. It would find it great to have a good solution. Working with shared temptables would give a problem with active agents while updating the shared temptables. I would prefer active agents to finish their jobs with the old temptable contents.

--
Kind regards,

Stefan Houtzager

Houtzager ICT consultancy & development

www.linkedin.com/in/stefanhoutzager

Posted by jmls on 22-Oct-2012 15:06

Hi Stefan,

Did you eventually work out a solution to the problem ?

Posted by agent_008_nl on 24-Oct-2012 02:30

Hi Julian,

I do not see a neat solution. They are thinking about it at psc, see Gus his email.

--
Kind regards,
Stefan Houtzager
Houtzager ICT consultancy & development

www.linkedin.com/in/stefanhoutzager

Posted by Lieven De Foor on 19-Nov-2012 09:22

mikefe wrote:

And if they are, it's a brilliant use case for the multi-tenant AppServer feature (temp-tables shared across AppServer agents) that Progress was thinking about around the development of 11.0.

gus wrote:

we have not forgotten about that particular problem. i'm hoping we come up with something better than shared temp tables (and we have a few random thoughts). you can already share tables by using temporary databases.

The question of multi-tenant AppServer came up at the Q&A session last friday at the PUG Challenge too.

Having some sort of shared temp-table mechanism across AppServer agents would be great for AppServer side caching...

Any news if this will be in an upcoming release?

Posted by agent_008_nl on 02-Oct-2013 07:37

Bit of a slow reaction, but my workaround now is:

I have a DataContainer record with a clob-field (correction: blob) containing a jsonfile with the dataset, and an int64 with a sequence. On update the clob->json is read into the dataset, the temptables that have to be updated are emptied and filled again using the (partially) new dbcontents. The appserveragent keeps track of the DataContainer version. If the sequencenumber becomes larger the new clob/json is re-read into the dataset on activate (or connect) of the agent.


--
Kind regards,

Stefan Houtzager

Houtzager ICT consultancy & development

www.linkedin.com/in/stefanhoutzager

Posted by ske on 01-Jan-2016 16:42

> I would like to call asbman from the abl, something like input through value("asbman...")

> But now I do not see a parameter for the adminserver password?

Returning to the original question in this old thread, regarding how to supply the password to asbman even though there is no parameter for that: Have you tried submitting the password as data on the standard input to asbman? Use INPUT-OUTPUT THROUGH "asbman ...", and then PUT UNFORMATTED "mypassword". Or redirect a file containing the password within the command, "asbman ... < mypasswordfile". (If one of these do not work, the other might. This might perhaps also differ between Windows and Unix.)

(Or submit the command on the same server where the appserver is running, so there will be no password prompt.)

I realize this may not help you with the rest of the scenario that was described, since the -DirectConnect parameter is just supposed to bypass the nameserver and not the broker, as mentioned in previous replies. However, maybe it could allow some experimentation nonetheless, or help with other problems.

Maybe it might be interesting to test what happens if you try to use -DirectConnect to connect to individual agents even though that is not the intended use for that parameter. Considering that in some operating modes, the client actually does talk directly to the agent after having been connected to one by the broker, maybe they're not so different anyway. But I realize there could be all sorts of details that would cause problems with this anyway. (I don't have the required environment readily at hand to experiment myself.)

Another idea might be to just stop all agents and restart them, to force them to reload their temp-tables, if reloading them is such a big operation that it is worth it.

On the other hand, if reloading the temp-tables really is such an expensive operation, then it seems to me that having to perform that operation in each and every one of the agents would result in a lot of expensive duplicate work amongst them. The more agents you have (to increase client throughput), the more duplicate work (slowing down that throughput). The total amount of work for reloading temp-tables would seem to be less with your current work-around where you cache the new dataset somewhere in the database (or anywhere you like), and compute it only once.

Other than that, I would say a good improvement to AppServer, would indeed be to have some new way of broadcasting some calls to all running agents to inform them of global changes, and/or to have a way to specify an ABL procedure to run while waiting idly for the next client call, and/or of course some other good mechanism to share cache data between agents, which was also hoped for in some replies (did that never materialize?).

Posted by agent_008_nl on 02-Jan-2016 04:59

I am not working for the customer where I thought about the exposed problem, so at the moment I have no need to dive into this. But in principle I would like to see a solution (a comparable problem could arise again + it's a step to making microservices possible) along the lines described during the thread. With a classic appserver the proposed solution proved impossible due to the nature of the appserver agent .exe. See below, I copied the relevant remarks made in this thread. I do not know how all is with the pas appserver that did not exist at the time I was working on the problem.

  In short, with some small extra's: I want a dataset to be available in memory, where f.e. validations reside (see previous threads where I explain some details about how an abl brms could work). This could be a separate abl session / service, name it a datacontainer. This dataset is updated when validations / validationmessages etc. are maintained in the database. When the dataset is updated a tweet (pub/sub) goes to all idle appserveragents (or persistent running validation services in separate abl/agent sessions), the dataset is copied to the validationservice and ready for use. Running appserver agents / validation services get a fresh copie after their current work is done and the datacontainer is updated.

 I rejected the shared temptable as proposed during the thread because running validations have to be completed before the dataset is refreshed.  

 All this to give the validationservice the possibilty to work as quick as possible, without having to do extra work right before a validation is executed. Of course it would be nice to be able to offer the dataset in a more language independent format (json?) to services written in another language.

---------------------------------------------------------------------------------------------------------------------------------------------------------

"a) An AppServer agent is not running the ABL language engine when idle, it is waiting solely on (socket) communications from the AppServer broker

b) Running a remote AppServer procedure n-number of times in an attempt to cycle through all the 'idle' agents will almost certainly not produce consistent results"

"With regards to 'idle', an AppServer agent works very differently from an ABL client or WebSpeed agent.  An AppServer agent is not actively running any ABL procedure when in an idle state; it is actually sitting in an 'C' code idle loop outside of the ABL language interpreter.  So no, the agent is not idling in a 'wait-for' where it can be interrupted, timeout, or handle asynchronous [i/o] operations.  The agent re-enters the language engine when a client's remote procedure request arrives, exists the language interpreter when the remote procedure has completed, and then waits in its idle loop until the next remote procedure or broker operation is received."

Posted by Thomas Mercer-Hursh on 02-Jan-2016 10:18

Did you mean to post this on a different thread?

Posted by agent_008_nl on 02-Jan-2016 11:16

This was a reply to ske. What's ske's full name btw?

Posted by Thomas Mercer-Hursh on 02-Jan-2016 11:32

It just seemed to fit with your architectural discussions.   Anyway, it reminded me of my work with Forte in the mid-90's.  Everything was written as a service and one deployed those services across a network of nodes via configuration, i.e., without new programming.  Multiple services could be on each node.  Unlike AppServer, a service was running for the duration and its location was published so that a client or other service who needed what it provided could look up the service and make a connection to it.  Any one service could thus have a large number of current connections, but the service itself was a multi-threaded process, so the service could listen on all the connections and spawn a thread to do work.  This enabled such things as a client requesting some data and registering an interest in that data.  If the data changed while the client was still interested, the service would send a data changed message to the client and the client could then decide whether it wanted to request a fresh copy.

Posted by Marian Edu on 03-Jan-2016 02:49

Although the whole dataset reload clearly imply 'state' which doesn't go too well with Stefan's new vision on functional programming this whole 'wait-for outside abl' might have changed in the new PAS? After all while it's understandable it was done like that prior to 9.1 when sockets were introduced but we're not on 8.3C anymore, time for an upgrade? :)

Posted by agent_008_nl on 03-Jan-2016 05:38

> Although the whole dataset reload clearly imply 'state' which doesn't go too well with Stefan's new vision on functional > programming

Witty witty. I'm not free of fall-backs. I've programmed almost only in abl far too long. You see what comes of it.  The whole container-object can be dismissed to the recycle-bin and replaced by a new one. Or have a version-number in it's name if history needs to persist. Quick thought to get you off my back. :-)

Posted by Marian Edu on 03-Jan-2016 05:47

[quote user="agent_008_nl"]

Quick thought to get you off my back. :-)

[/quote]

Hardly trying to get on your back here, just pointing out that might be a non-issue for one looking into embracing the functional programming approach... and here I do have to agree with you, 'state' is usually bad but unfortunately not easy to be avoided all the time :(

Posted by agent_008_nl on 03-Jan-2016 06:25

Just joking. Ah, ***, just sent a Pat and Mat solution, I have been discovered real-time struggling in the mud! Of course the datacontainer can hold different records with a version number to keep history, like the datomic database? Never mind, what am I damaging my brain for writing unpaid emails. :-)

This thread is closed