TCL dp_rpc and dp_rdo

It looks like you want to make an async call from a client to a server. The likely hood is that your calling the proc you want executed
directly in the dp_RXX call, which is probably killing your system.

If I were you, I would create a threaded application as my server, with at least one thread accepting requests, placing it into a queue
and a second thread pulling requests and processing them.
e.g

package require Thread
tsv::set queue input {}

#create processing thread
thread::create  {
    while (1) {

        if { [ expr [tsv::llength queue input] > 0 ] } {
            #do something
            puts "[thread::id] [tsv::lpop queue input]"
        }
    }

}


proc addToList {command } {

    tsv::lappend queue input $command

}

dp_MakeRPCServer 1234

==========
now your client just calls dp_RPC addToList something
If you want, I would extend the above to also return an ID back to the client in the RPC call such as an ID you
can store in "queue output" and be able to retrieve status of work processed when you want.
The above will allow you to make async calls with TCL DP RPC and also allow you to adjust the speed at which you process your requests.

I dont have much control on the server program.
I only able to get the port number in the server program, then all others is use this port number for my dp_* procedure.

I am wondering why it can't complete all >1000 commands, but 100 or 200 commands will completed successfully.

My purpose is to execute all these command without waiting result from server, so i think is good to use dp_RDO.
Is that anyway to solve this problem?

If you are sending 1000 commands using dp_RDO/RPC, the type of programming your doing is called event driven programming-
As soon as an even (in this case dp client request) is received, it's executed.

This immediate execution requires resources, memory, cpu time, and with dp probably 3+ file handles. The most critical element is how fast
can your server process these events/request. This is called "spin time", if the spin time is long, you will get the problems your describing.

If your server receives requests faster than it can process them, then your system will hang, and probably crash.
The problem you most likely have is your software architecture doesn't have the capacity to meet your needs.

There are 2 solutions:

1) Rewrite the software to have greater capacity, move from even driven to threaded.
  (using the above code, or using a threaded server like AOLServer, www.aolserver.com)

Or

2) Increase the amount of hardware your server is running on. I think this is less of an option for you.

I should add, there really isn't much you can do from a client perspective, unless you want to implement some form of caching and reduce the amount
of commands sent to your server.

Thanks so much pjaol for your description for me.
I am thinking that no matter how i need to use dp_RPC to send the command then.

However, why server can handle >1000 commands when using dp_RPC, but it is NOT for dp_RDO?

Can you explain more on this????

Thanks!!!!!