James, Let me try a different approach to describing things.
First, some definitions.... A Thread is an independent path of execution capability. It is equivalent to a thread in a Java application in your question. With the AR System environment, each thread includes a DB connection and the ability to perform operations to the DB in response to API calls. The outside world (the API) cannot address threads directly but is directed to a thread by a controller. A Queue is a pool of one or more threads that provide the externally identified access points into the system. A given access identifies a queue to interact with and that queue is a controller to pass work onto the threads within its control. So, let's use a bank as an analogy. You are going to your local branch to see a teller. There are three tellers working -- so there are 3 THREADS of execution. As most banks are set up, you get access to the threads (the tellers) by getting in the line for a teller -- so there is 1 QUEUE where you go -- and you are in line with other customers to be assigned to a teller -- thread -- when it is your turn for processing. Now, let's take it further. Instead of a teller to perform a transaction, you actually want to access your safe deposit box. Well, there is a DIFFERENT QUEUE you get in to get access and there may be 2 safe deposit box review rooms. So, you are in a different queue with two threads for performing safe deposit box operations. One step further, you instead want to perform an Administrative operation like setting up an account or closing an account. You don't go to the teller queue or to the safe deposit box queue, but to another queue for these types of operations. Say in your bank you had 1 person who helped with these operations so you have a queue with 1 thread. Now, depending on what operation you want to perform, you access the appropriate queue and then get directed to a thread to perform the work. Note that you could be in the Administrative queue waiting and there could be no one in the teller queue and there could be tellers just standing there (available threads) but there are no threads available in your queue so you are still waiting for your threads to become available. Queues allow bucketing of operations and threads perform the work. Now, if you had the bottleneck, you may want to increase the threads on the Administrative queue above to handle higher load but you do not want to block the teller threads with long Administrative operations as you may be getting a flood of customers for standard transactions coming in just a minute. You get to control the flow and the load and how much resource you dedicate to different operations. This is what threads and queues are all about. Kind of a simple example and it obviously can get more complex with multiple branches and you pick a branch and then a queue within that branch and many more types of queues and then server groups and load balancers and several other layers show up. But, hopefully, this gives you a way to understand the idea of threads and queues and what they are and how they interact. Doug Mueller -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky Sent: Tuesday, June 17, 2014 12:32 PM To: arslist@ARSLIST.ORG Subject: Re: Threads and queues Hi, The threads we are talking about are threads in a single process that performs in parallel the way you are describing it. The threads themselves perform more or less identical tasks. I a minimal system with a single thread (the Admin thread) the system will perform all the tasks within that single thread. The queues are queues only in a bogged down system where the AR Server/Database threads are all in use at the same time where user calls will be queued until a thread is free to service them. This is why they are called queues. The Admin/Fast/List/Escalation/Private queues are just a way to designate threads to certain types of operations. Each thread can service API-calls, which typically triggers a database search or a bunch of filter operations followerd by a write to the database. Each thread keeps an active database connection open to the database at all times. Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. > In Java a thread means a part of the program that executes independent > of other parts. Is that same in remedy? Can you give me example of > execution in remedy? > > A queue means lining up of jobs/threads like a pages in a printer. > > Feel free to correct me. > > Hi, There is a legacy here which might make it a little obscure. But nowadays the AR Server uses threads (similar to Java) to compute things parallel, and make parallel connections/calls to the database. Each active queue has one ore more threads, and listen to different RPC numbers, but except for Private queues you will only use RPC# 390601 (if I remember right) and the transactions will be routed to the right queue. In a normal system you have these queues (and each can have multiple threads): - Fast (handles most single record operations like Submit and Modify of a ticket) - List (handles most multiple record operations like a Search or getting the list of fields for a form) - Admin (the core thread that also handles all admin operations from DevStudio) - Escalation (performs the escalation searches and any resulting filter operations on updated records) - Private (private threads can be configured if you for example have an API integration that should be separated from the normal queues. Either to give priority access or to prevent it from bogging down the other queues servicing normal users) Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
