I currently manage an integration into Opayo Direct (v4.00). We send requests to Opayo, which most of the time work fine, but occasionally they time out (Our timeout limit is currently set to 20s, which is ages for a consumer to wait).
Does anyone know of a way to either:
Retry the payment request without double charging the consumer? or,
Send a follow up request to get the status of the submitted payment?
For 2. it looks like you need valid transaction identifier from Opayo, which of course we won't have as the request has timed out.
I can't see any mention of idempotency or guidance for what to do in this situation, even in their most recent API specification (PI integration).
Has anyone come up with a workable solution for this problem, other than change provider?
I want to perform load test on a Tibco JMS endpoint using JMeter. The endpoint is a JMS Queue Receiver that will reply to the JMS Message to end the sessions. I have done a lot of googling regarding what parameters to fill in each field of the JMS Point-to-Point sampler with no success. Attached is a screen shot of the Jmeter window. I am not sure whether this is the right sampler to use or if I should use Publisher. Either way, I do not know what to fill in each of these fields. I am currently stuck at the JNDI name Request queue field. When I put my queue name for the JMS on Tibco, I get an error that that name is not found. Leaving the field blank is also problematic. What should I fill in this field to make the request work?
We don't know your topic/queue names so we cannot help, you can ask around, see the application you're trying to simulate configuration or use Graphical Administration Tool for TIBCO® EMS to explore the endpoint and identify the proper queues for messages sending/receiving. For sending the messages you might need to set JMS_TIBCO_SENDER JNDI property
You might also be interested in Building a JMS Testing Plan - Apache JMeter article
I'm doing concurrent users load test for SignalR Protocol with WebSocket transport, I'm able run the script successfully for single users with more than 1 iteration. If I run it for concurrent users I'm not getting the expected behavior- which is I'm getting Second users response in first user request.
Please guide me here.
Most probably your parameterization or correlation fails somewhere somehow, i.e. you're sending the same session argument for both users.
Use Debug Sampler and View Results Tree listener combination in order to inspect request and response details and associated JMeter Variables values.
I need to test an application that processes SIP requests. For now, I want to test the performance of the application, so I need a way to generate a big number of SIP requests.
I know there are tools for this (like SipP), but I don't know what is the maximum number of requests that a single computer can really send in a particular time interval.
I never done this type of test, i need help.
Thanks
Well sipp can generate requests pretty quickly and if you're testing call set up and tear down, i.e. INVITE requests an d associated transaction processing, it's almost certainly the tool for the job.
If you're not concerned about SIP transaction processing and instead just want to bombard your server with SIP requests you could just whip up a console application with a UDP socket and send dummy requests by using a template request and modifying the following:
The branchid parameter on the Via header,
The tag parameter on the From header,
The Call-ID header.
Since your app will only be doing a few string search and replaces and a UDP send it will be able to generate requests probably a 100 to 1000 times faster than a server on the same hardware, that needs to parse and understand the requests, will be able to process them.
I'm working on a web application that submits tasks to a master/worker system that farms out the tasks to any of a series of worker instances. The work queue master runs as a separate process (on a separate machine altogether) and tasks are submitted to the master via HTTP/REST requests. Once tasks are submitted to the work queue, client applications can submit another HTTP request to get status information about tasks.
For my web application, I'd like it to provide some sort of progress bar view that gives the user some indication of how far along task processing has come. The obvious way to implement this would be an AJAX progress meter widget that periodically polls the work queue for status on the tasks that have been submitted. My question is, is there a better way to accomplish this without the frequent polling?
I've considered having the client web application open up a server socket on which it could listen for notifications from the work master. Another similar thought I've had is to use XMPP or a similar protocol for the status notifications. (Of course, the master/worker system would need to be updated to provide notifications either way but I own the code for that so can make any necessary updates myself.)
Any thoughts on the best way to set up a notification system like this? Is the extra effort involved worth it, or is the simple polling solution the way to go?
Polling
The client keeps polling the server to get the status of the response.
Pros
Being really RESTful means cacheable and scaleable.
Cons
Not the best responsiveness if you do not want to poll your server too much.
Persistent connection
The server does not close its HTTP connection with the client until the response is complete. The server can send intermediate status through this connection using HTTP multiparts.
Comet is the most famous framework to implement this behaviour.
Pros
Best responsiveness, almost real-time notifications from the server.
Cons
Connection limit is limited on a web server, keeping a connection open for too long might, at best load your server, at worst open the server to Denial of Service attacks.
Client as a server
Make the server post status updates and the response to the client as if it were another RESTful application.
Pros
Best of every worlds, no resources are wasted waiting for the response, either on the server or on the client side.
Cons
You need a full HTTP server and web application stack on the client
Firewalls and routers with their default "no incoming connections at all" will get in the way.
Feel free to edit to add your thoughts or a new method!
I guess it depends on a few factors
How accurate the feedback can be (1 percent, 5 percent, 50 percent) Accurate feedback makes it worth pursuing some kind of progress bar and comet style push. If you can only say "Busy... hold on... almost there... done" then a simple ajax "are we there yet" poll is certainly easier to code.
How timely the Done message has to be seen by the client
How long each task takes (1 second, 10 seconds, 10 minutes)
1 second makes it a bit moot. 10 seconds makes it worth it. 10 minutes means you're better off suggesting the user goes for a coffee break :-)
How many concurrent requests there will be
Unless you've got a "special" server, live push style systems tend to eat connections and you'll be maxed out pretty quickly. Having to throw more webservers in for a fancy progress bar might hurt the budget.
I've got some sample code on 871184 that shows a hand rolled "forever frame" which seems to work out well. The project I developed that for isn't hammered all that hard though, the operations take a few seconds and we can give pretty accurate percent. The code uses asp.net and jquery, but the general techniques will work with any server and javascript framework.
edit As John points out, status reporting probably isn't the job of the RESTful service. But there's nothing that says you can't open an iframe on the client that hooks to a page on the server that polls the service. Theory says the server and the service will at least be closer to one another :-)
Look into Comet. You make a single request to the server and the server blocks and holds the connection open until an update in status occurs. Once that happens the response is sent and committed. The browser receives this response, handles it and immediately re-requests the same URL. The effect is that of events being pushed to the browser. There are pros and cons and it might not be appropriate for all use cases but would provide the most timely status updates.
My opinion is to stick with the polling solution, but you might be interested in this Wikipedia article on HTTP Push technologies.
REST depends on HTTP, which is a request/response protocol. I don't think you're going to get a pure HTTP server calling the client back with status.
Besides, status reporting isn't the job of the service. It's up to the client to decide when, or if, it wants status reported.
One approach I have used is:
When the job is posted to the server, the server responds back a pubnub-channel id (one could alternatively use Google's PUB-SUB kind of service).
The client on browser subscribes to that channel and starts listening for messages.
The worker/task server publishes status on that pubnub channel to update the progress.
On receiving messages on the subscribed pubnub-channel, the client updates the web UI.
You could also use self-refreshing iframe, but AJAX call is much better. I don't think there is any other way.
PS: If you would open a socket from client, that wouldn't change much - PHP browser would show the page as still "loading", which is not very user-friendly. (assuming you would push or flush buffer to have other things displayed before)