I have tried to originate a call from cli, My call file will hit two Java applications at a time so that they starts communicating to each other. Now My requirement is to originate multiple calls at once so that multiple threads run at same time. and Thus I can test the load etc. I have tried following for originating single call It works fine.
originate loopback/1234/default &bridge({ignore_early_media=true}sofia/internal/1789#XX.XX.XX.XX)
The above file can only be executed once, If I run it in a loop even then only one call is invoked. Please suggest me some way how to originate more number of calls in freeswitch
Your code is getting stuck waiting for the result -- 'api' commands are blocking
If you execute this as 'bgapi originate....' then it will be a background execution (bg) and be non-blocking -- it will return a job uuid, and let you execute more commands.
See:
http://wiki.freeswitch.org/wiki/Event_Socket_Library#bgapi
http://wiki.freeswitch.org/wiki/Event_Socket#bgapi
bgapi returns only Job-UUID, but not call uuid. what to do next?
Related
I have multiple batches that are using different 3rd party apis to get and store/update data. the connections are made via laravels http request. all batches have about 6k jobs. Because all jobs are important I need to log the failed ones and nofiy the user.
Sometimes the response returns an error for all jobs. sometimes just a connection error or an error because the server cant process those requests.
The batch automatically cancels on first failure. But is there a way to cancel the batch if there are multiple failues (on nth failure) not just first?
First turn off normal batch error handling, then implement your own:
Initialize a counter with zero.
Whenever an error occurs, increase that counter.
Whenever that counter reaches/exceeds 5, fail the batch.
The concise implementation depends on the batch system you are working with.
I am a beginner in SAP ABAP. I am debugging an asynchronous RFC (parallel processing). I have put a break-point in the calling portion of the RFC, an external break-point inside the RFC and an external break point in the form which is called at the end of task through perform. I am able to debug the RFC FM.
Another session opens up. But I am not able to debug the perform which is called after end of task. After the RFC is debugged, the control returns to the calling point of the FM. it doesn't go inside the form. When all the iterations are finished, then at the end it goes inside the perform. Why so? shouldn't the perform be executed in parallel?
Inside the perform I have written like RECEIVE RESULTS FROM FUNCTION XXX. But the debugger control is not going inside the perform after returning from the RFC.
You have given very little information on the overall program flow, but there's a part of the documentation that might be relevant to your case:
A prerequisite for the execution of a registered callback routine is
that the calling program still exists in its internal session when
the remote function is terminated. It is then executed here at the
next change of the work process in a roll-in. If the program was
terminated or is located on the stack as part of a call sequence, the
callback routine is not executed.
[...]
The time when the callback routines are executed can be programmed
explicitly or be reached implicitly:
The statement WAIT FOR ASYNCHRONOUS TASKS is used for explicit programming. As specified by a condition, this statement changes the
work process and hence executes the callback routines registered up to
this time. It waits for as many registered routines to end until the
condition is met (the maximum wait time can be restricted). Explicit
programming is recommended whenever the results of the remote function
are required in the current program.
If the results of the remote function are not required in the current program, the time at which the callback routines are executed
can also be determined by an implicit change of the work process (for
example, at the end of a dialog step). This can be a good idea, for
example, in GUI scenarios in which uses of WAIT are not wanted. In
this case, it must be ensured that the work process changes before the
program is ended. There is also a risk that, if the work process is
changed implicitly, not all callback routines are registered in time.
It is likely that the program issuing the call and registering the callback routine is either terminated or does not issue a WAIT FOR ASYNCHRONOUS TASKS so that the callback is only executed on the next roll-in.
Re-reading your question, you apparently assume that the callback routine will be executed in parallel to the program that has registered it. That is not the case, ABAP is not multi-threaded.
I've been messing around with Ruby and threading a little bit today. I have a list of proxies that I want to check. Assuming a timeout of 10 seconds going through a very large list of proxies will take many hours if I write something that goes like:
proxies.each do |proxy|
check_proxy(proxy)
end
My first problem with trying to figure out threads is how to START multiple at the same exact time. I found a neat little snippet of code online:
for page in pages
threads << Thread.new(page) { |myPage|
puts "Fetching: #{myPage}\n"
doc = Hpricot(open(myPage.to_s)).to_s
puts "Got #{myPage}: #{doc.size}"
}
end
Seems to work nicely as far as starting them all at the same time. So now I can... start checking all 7 thousand records at the same time?
How do I go to a file, take out a line for each thread, run a batch of like 20 and repeat the process?
Can I run a while loop that in turn starts 20 threads at the same (which remove lines from a file) and keeps going until the file is blank?
I'm a little weak on the logic of what I'm supposed to do.
Thanks guys!
PS.
Another thought: Will there be file access issues if 20 workers are constantly messing with it randomly? What would be a good way around that if this is so?
The keyword you are after is threadpool. You can either try to find one for Ruby (I am sure there's couple at least on Github), or roll your own.
Here's a simple implementation here on SO.
Re: the file access, IMO you shouldn't let workers alter the file directly, but do it in your main thread. You don't want to allow simultaneous edits there.
Try to use gem DelayJob:
https://github.com/tobi/delayed_job
You don't need to generate that many Threads in order to do this work. In fact generating a lot of Threads can decrease the overall performance of your application. If you handle checking each proxy asynchronously, without blocking, you can get by with far fewer threads.
You'd create a file manager thread to process the file. Each line gets added as a request to an array(request queue). On the other end of the request queue you can use eventmachine to send the requests without blocking. eventmachine would also be used to receive the responses and handle the timeout. The response can then be placed on another array(response queue) which your file manager thread polls. The file manager thread pulls the responses from the response queue and resolves if the proxy exists or not.
This gets you down to just creating two threads. One issue that you will have is limiting the number of requests that have been sent since this model will be able to send out all of the requests in less than a second and flood the nearest router. In my experience you should be able to have around 500 outstanding requests at any one time.
There is more than one way to solve this problem asynchronously but hopefully the above is enough to help get you started with non-blocking I/O.
executeBatch update does not continue executing the rest of the commands if theres a failure in one of the execution. Is there anyway or any alternative to executeBatch, wherein even if a command fails to execute, still the rest of the commands are successfully executed. Not using executeUpdate since it takes a lot of time and executes query one by one.
The documentation says this:
An exception thrown when an error occurs during a batch update operation. In addition to
the information provided by SQLException, a BatchUpdateException provides the update
counts for all commands that were executed successfully during the batch update, that is, all
commands that were executed before the error occurred. The order of elements in an array of
update counts corresponds to the order in which commands were added to the batch.
After a command in a batch update fails to execute properly and a BatchUpdateException is
thrown, the driver may or may not continue to process the remaining commands in the
batch. If the driver continues processing after a failure, the array returned by the method
BatchUpdateException.getUpdateCounts will have an element for every command in the
batch rather than only elements for the commands that executed successfully before the error.
In the case where the driver continues processing commands, the array element for any command
that failed is Statement.EXECUTE_FAILED.
So as I understand it depends on jdbc-driver you work with.
Probably a better solution would be to find a reason of the problem and fix it?
I have a doubt regarding multiple file transfer with qftp. There is no direct way to transfer multiple files with qftp class. Well, I tried it using arbitrary ftp command "mput" with "rawCommand" in QFTP. But it doesnt work for me.
Please let me know how I could do a multiple file transfer with qftp.
Thanks,
Use a for-loop, and start a new transfer for every iteration. Then collect all the commandFinished() signals at the end.
QFtp works asynchronously. If an operation cannot be executed immediately, the operation will automatically be scheduled for later execution. The results of scheduled operations are reported via signals.