Yes, you can do this, but not from the same Client that is receiving the messages. Instead, you should create another Client object to send commands to AMPS. You should also keep in mind that, while the receive thread is in your message handler, no other messages are being processed for the client that called the message handler.
The reason for this is that the thread that is calling the message handler is the only thread that is receiving messages for that client object. Attempting to send any message that waits for a response (including an acknowledgement that the command was received) on the same client object will time out, or block forever if no timeout value is specified. The call from the message handler is blocking the thread that processes incoming messages.
There are also very careful locking semantics happening inside the client object, and if your application is using that same client object in other threads there could be unforeseen deadlock situations.
Notice that this article applies to message handlers called during asynchronous message processing. If you are using a MessageStream, the thread that populates the MessageStream continues to run in the background: you can use the Client to send other commands while working with messages from the MessageStream.
See the AMPS Developer Guide for your client language of choice for a discussion of multithreading in the AMPS clients (including the information above).
Keywords: multithreading, client, message handler, asynchronous message processing
Is this applicable for ack() the queue messages in the async handler? If I understand correctly ack() is internally a sow_delete command. Is it ok to issue ACK from the async handler and it will not lead to any deadlock.
Yes, it's safe to call the ack() function on a message from within a message handler.