fix(llm): enable tasks concurrency configs in Gradio

[Kryst4lDem0ni4s]

fix #176

Cause of the Problem:
Blocking and Queuing Behavior: Gradio, by default, has a concurrency limit of 1. This causes blocking when multiple users or windows are accessing the application simultaneously.
No Asynchronous Execution: The current implementation does not specify concurrency_limit, leading to sequential execution.
Queue Configuration: If queue() is not configured properly, tasks are processed one at a time.

Changed:

log_path = "logs/llm-server.log"
    try:
        with open(log_path, "r", encoding='utf-8') as f:
            return ''.join(deque(f, maxlen=lines))
    except FileNotFoundError:
        log.critical("Log file not found: %s", log_path)
        return "LLM Server log file not found."

to

log_path = "logs/llm-server.log"
    try:
        with open(log_path, "r", encoding='utf-8') as f:
            data = f.read()
            return ''.join(deque(data, maxlen=lines))
    except FileNotFoundError:
        print(f"Log file not found: {log_path}")
        return "LLM Server log file not found."
    except UnicodeDecodeError as e:
        print(f"Decoding error occurred: {e}")
        # ignore the bad bytes and continue processing
        with open(log_path, "r", encoding='utf-8', errors='ignore') as f:
            data = f.read()
            return ''.join(deque(data, maxlen=lines))

in order to handle frequent unicode encoding errors during attempts to read logs.

Also added task ID generation for RAG functions, and enabled concurrency using Gradio Blocks in rag_block.py in rag_demo by creating a task ID generation decorator and used Gradio Blocks for concurrency control. Added logs for clear understanding. Issue: #176 #176

Closed previous PRs due to merge conflicts. please check this @imbajin

[imbajin]

we could merge after #187 done (And some tips for the individual PRs)

1. checkout a new branch from master/main each time when u want to submit a separate PR(rather than use the previous dev branch)
2. use fix #xxxx or close #xxx in github to link the issue & PR (u can refer the usage/synax in github's doc)

[Kryst4lDem0ni4s]

@imbajin thanks for the tips, I was having trouble getting used to that initially

[imbajin]

Also note check/fix the (CI) lint error to keep our code better

refer https://github.com/apache/incubator-hugegraph-ai#contributing

[imbajin]

maybe the two lines 211~212 modification is enough for now

[Kryst4lDem0ni4s]

Alright I'll modify it to incorporate the buttons for now.

[imbajin]

Is this decorator still useful now or in the future? Is the main purpose of logging newly created tasks?

[Kryst4lDem0ni4s]

Yes this one is useful, it's for generating concurrency ids, while the other is a more static general id useful for logging references (the one in the button) and can be modified or removed.

[imbajin]

Yes this one is useful, it's for generating concurrency ids, while the other is a more static general id useful for logging references (the one in the button) and can be modified or removed.

We can keep it, but I still don't understand the purpose of recording this taskID separately in the click function? It seems that there is no significant difference even if I don't use this decorator and record it?

BTW, our logs are already too numerous and need to be streamlined as much as possible 😄

[Kryst4lDem0ni4s]

Understood, I'll try to streamline the logs next.
And you're right, there isnt any significant usage of the click function's taskID, it is merely for identifying the ongoing process so that it is clearer to the dev, which process' ID was being generated, but we can reduce this too if it is unneccesary. As for the decorator, the task_id = str(uuid.uuid4()) is being used to identify any concurrent processes being run, so that we can differentiate ongoing processes per task_id for further debugging as per #176 . I hope this is useful for further development and scaling

[imbajin]

Understood, I'll try to streamline the logs next.
And you're right, there isnt any significant usage of the click function's taskID, it is merely for identifying the ongoing process so that it is clearer to the dev, which process' ID was being generated, but we can reduce this too if it is unneccesary. As for the decorator, the task_id = str(uuid.uuid4()) is being used to identify any concurrent processes being run, so that we can differentiate ongoing processes per task_id for further debugging as per #176 . I hope this is useful for further development and scaling

I haven't found out how it works in my local tests. Can you give me an example of how to use it?

[imbajin]

so as here

[imbajin]

I tested it locally and didn't see when this log will be output? There was no occurrence during concurrent use