our flow call http action which call asp.net published web site hosted on our server. this flow is called from power app portal when user click on button (this call created by js code). issue: when user click on the button ,flow run once but http action excuted more than one in same second. this is not seen in flow log ,but we seen http request on log of our server which host .net site and duplicate records created in another system which run under http request code. note:we try to set http action retry policy to none or once and same issue occured.
i tried to increase time out of flow and time out of calling erp service.also tried to make retry policy to none of http action.
Related
I have to record a load test for a successful login and further browsing in to the asp.net application.
After recording the script in jmeter, my samplers are 1) get request (login page) 2) post request (posting the credentials and click login) 3)and other samplers (after successful login).
My problem is it shows incorrect username password error(manually it is working) whenever i play the the script, i have parameterized the valid credentials, also did correlation(by seeing the post request i got to know the fields that were posted) with event state validation, viewstate genearator, viewstate and hdnkey from get response(sampler 1) to my post request(sampler 2) and tried again, but i am getting the same error everytime.
Please let me know, what should be done to login successfully. So i can perform the load test on this asp.net application.i have came accross lots of sites for this issue but nothing solved it. Please help!
You can try to debug your JMeter script. Look here and here. I would use Debug Sampler as the first step for seeing variables values.
You can use tool like Fiddler to record the requests that are made when you manually login into the site. Then you can compare them with your JMeter script.
Make sure to add HTTP Cookie Manager to your Test Plan
Make sure to correlate any dynamic parameters like View State, EventValidation, etc.
Run your test with 1 virtual user and 1 loop and inspect request and response details using View Results Tree listener. Compare requests you send with JMeter with what real browser sends (can be found in your browser Developer Tools "Network" tab") - requests should be the same (apart from dynamic parameters)
Check out ASP.NET Login Testing with JMeter article for example test plan building explained.
on my JSF page I have a primefaces poll (<p:poll>) which checks if a backend is still running every second. The problem now is that the HTTP POST method, which checks the backend, is writting a logging entry into the Tomcat log every second. This will likely produce a lot of logging data which may lead to some problems with the server.
My question is now how I can prevent this POST method from writting into the tomcat log file?
I have code in my project which changes the URL containing the text as querystring to number to get the data from the database. I am checking the querystring in page load and if it contains the name rather than the number I am mapping it to the numeric key. Now I have to execute the page life cycle again. I had two choice either use the
Response.Redirect
but I do not want the URL in the client browser to change so I went with the
Server.Transfer
The problem I started facing is that I have a custom httpmodule which is used to log the URLs in the database. I realized that
BeginRequest
in the http module is not firing after the
Server.Transfer
My application is working fine in the case of
Response.Redirect.
I am not sure how and why Server.Transfer is skipping my HttpModule and if it is how it works ?
Server.Transfer is a completely server side mechanism - it instantiates the new Page class based on the path to .aspx file and transfers the execution there (including all state information for the built-in objects). There is no new request and nothing goes again through the pipeline (so among other things HttpModules are not re-executed), as the hosting part is interested this is still the same request - the response has just been created from different page than it was originally planed.
Response.Redirect falls to standard HTTP mechanism. On server side it throws an exception to break the current execution pipeline and return an 3xx status code. The browser then issues new request for the resource under the new URL. Both requests go through full pipeline on the server side.
So the answer to your question boils down to the fact that HttpModules are being executed for every upcoming request but in case of Server.Transfer there is no new upcoming request.
Following is our environment setup:
IIS 7 receives Http (.jsp) request from client (browser).
It blindly redirects it to JBoss using ISAPI_Redirect.dll.
Now we are trying to modify this setup in such a way that before IIS7/ISAPI_redirect sends it to JBoss, we need to modify posted form data using Http module. This http module is normal .net http module.
We are able to intercept the request # BeginRequest event of http module and when we send it to JBoss, it gives us "Read client failed (400)" error.
Any idea how to achieve this task or fix the problem at hand?
We were not able to fix our problem in its original form. What we did is we removed ISAPI_REDIRECT/JBoss from our original pipeline.
We now take the request directly to our http module by setting up another virtual directory where ISAPI_Redirect is not configured, we do our modification (earlier we intended to do this after JBoss has received the request) and then send it to another virtual directory (URL) where ISAPI_REDIRECT is configured. Now ISAPI_Redirect captures the request, maps it to JBoss format and sends it to JBoss.
Basically we switched the place of our customer processing and things seem to falling in place.
I have an HTTP Module to handle authentication from Facebook, which works fine in classic pipeline mode.
In integrated pipeline mode, however, I'm seeing an additional request pass through for the default document, which is causing the module to fail. We look at the request (from Facebook) to retrieve and validate the user accessing our app. The initial request authenticates fine, but then I see a second request, which lacks the posted form variables, and thus causes authentication to fail.
In integrated pipeline mode, an http request for "/" yields 2 AuthenticateRequests in a row:
A request where AppRelativeCurrentExecutionFilePath = "~/"
A request where AppRelativeCurrentExecutionFilePath = "~/default.aspx"
That second request loses all of the form values, so it fails to authenticate. In classic mode, that second request is the only one that happens, and it preserves the form values.
Any ideas what's going on here?
UPDATE: Here is an image of the trace from module notifications in IIS. Note that my module, FBAuth, is seeing AUTHENTICATE_REQUEST multiple times (I'd expect 2 - one for authenticate and one for postauthenticate, but I get 4).
I'm starting to believe this has something to do with module/filter configuration because I've found a (Vista) box running the same code that doesn't fire these events repeatedly - it behaves as expected. I'm working through trying to figure out what the difference could be...
Thanks!
Tom
My solution was to add the following code at the end of Application_BeginRequest:
if (Request.RawUrl.TrimEnd('/') == HostingEnvironment.ApplicationVirtualPath.TrimEnd('/'))
Server.Transfer(Request.RawUrl+"Default.aspx", true);
DefaultHttpHandler is not supported,
so applications relying on sub-classes
of DefaultHttpHandler will not be able
to serve requests If your application
uses DefaultHttpHandler or handlers
that derive from DefaultHttpHandler,
it will not function correctly. In
Integrated mode, handlers derived from
DefaultHttpHandler will not be able to
pass the request back to IIS for
processing, and instead serve the
requested resource as a static file.
Integrated mode allows ASP.NET modules
to run for all requests without
requiring the use of
DefaultHttpHandler. Workaround
Change your application to use
modules to perform request processing
for all requests, instead of using
wildcard mapping to map ASP.NET to all
requests and then using
DefaultHttpHandler derived handlers to
pass the request back to IIS.
Hmmm, or this could be the issue.
ASP.NET modules in early request
processing stages will see requests
that previously may have been rejected
by IIS prior to entering ASP.NET,
which includes modules running in
BeginRequest seeing anonymous requests
for resources that require
authentication ASP.NET modules can run
in any pipeline stages that are
available to native IIS modules.
Because of this, requests that
previously may have been rejected in
the authentication stage (such as
anonymous requests for resources that
require authentication) or other
stages prior to entering ASP.NET may
run ASP.NET modules. This behavior is
by design in order to enable ASP.NET
modules to extend IIS in all request
processing stages. Workaround
Change application code to avoid
any application-specific problems that
arise from seeing requests that may be
rejected later on during request
processing. This may involve changing
modules to subscribe to pipeline
events that are raised later during
request processing.
http://learn.iis.net/page.aspx/381/aspnet-20-breaking-changes-on-iis-70/