Forum Replies Created
-
AuthorReplies
-
We use verizon carrier and texts to @vtext are working just fine (for now). You can also try @vzwpix.com to see whether this works.
Thanks.
Yes, once you initiate a resume, you should see a file under /lws//out folder. This file then picked up by the client.
Let me know if you need any more info.
Thanks.
Arslan Khan
We are using PROTOCOL:tcpip with length encoding but still see the duplicates. We’ll try to use base64 encoding and see whether this fixes the issue.
Thanks.
As these are encryted messages, we are not doing any filtering. These are straight raw thru.
We did enable the standard ACK/NAK procs but still encountered the same duplicate issue.
Also, we did extensive trouble shooting earlier to eliminate the option of client sending the duplicates.
We did enable basic ACK/NACK but were still getting duplicates. Based on the info we have so far, We think that duplication may be happening at the protocol level.
As these are encrypted messages, we do not enable SMAT on these outbound threads. We do have SMAT on the receiving side which shows the duplicates.
We do not have any ack/nack enabled on the outbound thread, thus no await replies option activated.
Default entry of “-1” under Retries and Interval of “10” is being used under “Outbound Data” section of “Outbound” tab.
Hi Tom,
Were you able to find the solution to your encryption issue?
We are in the same shoes now requiring exactly the same thing.
Let me know.
Thanks.
In this case, you are basically not not sending any ACK/NACK back to CSC client.
I’ll ask the RH implementation specialist to contact you and provide you relevant details.
Thanks.
In this case, you are basically not not sending any ACK/NACK back to CSC client.
I’ll ask the RH implementation specialist to contact you and provide you relevant details.
Thanks.
In this case, you are basically not not sending any ACK/NACK back to CSC client.
I’ll ask the RH implementation specialist to contact you and provide you relevant details.
Thanks.
Hi Cynthia,
CSC does sends ACK back to the sending system, in this case to your CL interface engine.
Have you enabled ack/nack proc on your sending thread?
Once you enable ac/nack proc, you can use “await replies” with a time out value of, say, 120 seconds.
Let me know if you need any more info.
Thanks.
I was thinking that it was some tclproc which was causing this issue. Actually, what I am noticing now is that it is the use of
Thanks for the feed back Russ.
We were able to pin point the cause of these memory leaks. We are working on a fix now and hoping that this will eliminate this high memory/cpu utilization problem.
-
AuthorReplies