×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
I could comment more easily Nathan if I new what you meant by "Our web
portal submits a Job, then redirects browsers to communicate with that
Job."
When users click on a menu item, that sends a request to our portal's URL.
Our web portal is an IBM i Job that submits another IBM i Job by using the
SBMJOB command, generates a unique "session ID", which is assigned to that
Job, generates another URL that includes that unique session ID, and
redirects the browser to that URL.
How does it communicate? data queue? The browser can't arbitrarily connect
to a job as it requires a port connection and there's a limited number of
those so your 10s of thousands of users would be problematic.
In regard to your communication question, an HTTP server thread extracts
the "session ID" from the requested URL and sets up a communication channel
with the appropriate Job, using IBM i shared memory APIs, which is the
fastest form in inter-process communication that I'm aware of.
I agree with your point about there being a limited number of ports. We
tend to configure an IBM i HTTP server instance to handle thousands of
connections on a single port, which causes it to instantiate thousands of
threads, internally.
Not asking for trade secrets - just the basic mechanics of what you do.
A complete answer would be somewhat more entailed. But hopefully you get
the gist. I should stress that this is NOT IBM's persistent CGI interface,
which is delineated at:
https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_73/rzaie/rzag3ch3ovrvwpercgi.htm
midrange.com
