Sravansiloju
Below are our responses to your questions,
1) We were getting exceptions saying missing access group/application which was deleted intentionally. This access group was mentioned in Async processor earlier. As this was fixed in 8.3 we removed it but some how it started throwing exception and we added it back and we are still getting exception. So what we did is, we deleted data flows and it worked. Q1: What should we do in case of Production?

OSP: The Data flow that we see for each queue processor is nothing but a work object of Pega-DM-DDF-Work
class. This work object has the access group in it which will be used to execute the data flow. Since you have removed the access group from your system, it was not able to find the access group and would have thrown exception.

Keep the access group as such when you promote the code to production.

2) I am not very clear on the 20 partitions and threads concept, so from what i understand 1 quque processor running on 5 stream nodes with 10 threads mentioned in the queue processor will create 1510=50 batch requestors. Right? and they are created as soon as we start the server no matter if they have enough messages to process. Right? Will these 50 requestors occupy space in the system or are they like sleeping?

OSP: These are child requestors created on demand. Hence it doesn't occupy much of heap memory.

3) Now after we have removed data flows and recreated and they started mapping to System Run time context, if we are queuing 100 items, it shows 100 as processed but only 50-60 are processed and rest are lost. but the processed count says 100. Every processed item should create a case which is not happening. By Any chance are we missing anything here after the upgrade. Please note we do have stream nodes.

OSP: Usually queue processor updates the successful count only after the completion of the queue processing activity. Can you please show us the logic that you use to create work objects? Is it synchronous or asynchronous?