We use report portal to report automatic tests from WDIO.
I have noticed, that after long waits in the tests (waiting for a field to be updated in the database, before continuing with the test for example) report portal stops reporting and the test get the status of interrupted.
could found anything about this on internet.
The problem was that some Wdio call (like $(element).isExist(), may throw an error, and NodeJS will throw an exception that if its unhandled, then test status in Report Portal will be interrupted
Related
I have an application which stores photo data in database. An SSRS report is used to generate reports of photos related to a specific entity. The information required to generate this report is stored in a separate database and very simply links a ReportId with a number of photos. The Reporting Services Execution Web service is used to render a report in Word format and output a byte array which is then used by the application.
The issue is, there is a very clear and repeatable size limit beyond which the report is not received by the application. In each case the report is rendered successfully but the response is never sent as per the RS logs:
rshost!rshost!1bfc!03/14/2018-21:46:48:: e ERROR: HttpPipelineCallback::SendResponse(): failed writing response.
rshost!rshost!1bfc!03/14/2018-21:46:48:: e ERROR: Failed with win32 error 0x0057, pipeline=0x0000027542592740.
httpruntime!ReportServer_0-1!1bfc!03/14/2018-21:46:48:: e ERROR: Failed in
BaseWorkerRequest::SendHttpResponse(bool), exception=System.ArgumentException: Value does not fall within the expected range.
at Microsoft.ReportingServices.HostingInterfaces.IRsHttpPipeline.SendResponse(Void* response, Boolean finalWrite, Boolean closeConn)
at ReportingServicesHttpRuntime.BaseWorkerRequest.SendHttpResponse(Boolean finalFlush)
library!ReportServer_0-1!1bfc!03/14/2018-21:46:48:: e ERROR: Throwing Microsoft.ReportingServices.Diagnostics.Utilities.ReportServerHttpRuntimeInternalException: RsWorkerRequest::FlushResponse., Microsoft.ReportingServices.Diagnostics.Utilities.ReportServerHttpRuntimeInternalException: An internal or system error occurred in the HTTP Runtime object for application domain ReportServer_SSRS_0-1-131655000672564770. ---> System.ArgumentException: Value does not fall within the expected range.
at ReportingServicesHttpRuntime.BaseWorkerRequest.SendHttpResponse(Boolean finalFlush)
at ReportingServicesHttpRuntime.RsWorkerRequest.FlushResponse(Boolean finalFlush)
--- End of inner exception stack trace ---;
rshost!rshost!1bfc!03/14/2018-21:46:48:: e ERROR: HttpPipelineCallback::SendResponse(): failed writing response.
rshost!rshost!1bfc!03/14/2018-21:46:48:: e ERROR: Failed with win32 error 0x10DD, pipeline=0x0000027542592740.
This appears to be directly related to some size limit of the service http response for the following reasons:
The request itself is very small, just a Report Id i.e. httpRuntime maxRequestLength is not related, this has been tested.
The error happens within a few minutes of the request i.e. httpRuntime executionTimeout is not related, this has been tested.
I can reliably and repeatably add one photo too many to the report and it will fail, remove one photo and it renders and sends with no issues, add one photo and it will fail...
The times to render vary so again it appears more related to size than some timeout.
The report server execution logs show that the rendering is successful every time, regardless of whether the report is sent or not.
I have reproduced the error using both the application which normally calls the report and a separate console app that simply generates a web service client and tries to render and receive the report as a byte array using the Render2 method.
I have reproduced this error using SQL Server 2012 and SQL Server 2016, on several different report servers, including setting up a report server locally and running the server and request on the same machine.
Regardless of the combination of photos, the report always renders successfully but fails to send around a bytecount of ~238,000,000 i.e. not related to some bad data.
In all cases I am able to generate reports of the same size or greater through the Report Server portal with no issues.
Has anyone experienced similar behaviour using the RS web service? I have searched online extensively without any luck. Any suggestions on how to address this issue would be greatly appreciated.
Microsoft finally identified HttpSendResponseEntityBody as the source of the error. The function sends entity-body data associated with an HTTP response, and as per MSDN has the following parameter:
EntityChunkCount [in] A number of structures in the array pointed to by pEntityChunks. This count cannot exceed 9999.
Microsoft don't have any SSRS documentation that addresses report size limits. At this stage all they have done is suggest that "we can use other tools for this data extracting" and that "generally we suggest put the data smaller than 100MB or the row counts less than 1,000,000".
We are running a Sails.js API on Google Container Engine with a Cloud SQL database and recently we've been finding some of our endpoints have been stalling, never sending a response.
I had a health check monitoring /v1/status and it registered 100% uptime when I had the following simple response;
status: function( req, res ){
res.ok('Welcome to the API');
}
As soon as we added a database query, the endpoint started timing out. It doesn't happen all the time, but seemingly at random intervals, sometimes for hours on end. This is what we have changed the query to;
status: function( req, res ){
Email.findOne({ value: "someone#example.com" }).then(function( email ){
res.ok('Welcome to the API');
}).fail(function(err){
res.serverError(err);
});
}
Rather suspiciously, this all works fine in our staging and development environments, it's only when the code is deployed in production that the timeout occurs and it only occurs some of the time. The only thing that changes between staging and production is the database we are connecting to and the load on the server.
As I mentioned earlier we are using Google Cloud SQL and the Sails-MySQL adapter. We have the following error stacks from the production server;
AdapterError: Invalid connection name specified
at getConnectionObject (/app/node_modules/sails-mysql/lib/adapter.js:1182:35)
at spawnConnection (/app/node_modules/sails-mysql/lib/adapter.js:1097:7)
at Object.module.exports.adapter.find (/app/node_modules/sails-mysql/lib/adapter.js:801:16)
at module.exports.find (/app/node_modules/sails/node_modules/waterline/lib/waterline/adapter/dql.js:120:13)
at module.exports.findOne (/app/node_modules/sails/node_modules/waterline/lib/waterline/adapter/dql.js:163:10)
at _runOperation (/app/node_modules/sails/node_modules/waterline/lib/waterline/query/finders/operations.js:408:29)
at run (/app/node_modules/sails/node_modules/waterline/lib/waterline/query/finders/operations.js:69:8)
at bound.module.exports.findOne (/app/node_modules/sails/node_modules/waterline/lib/waterline/query/finders/basic.js:78:16)
at bound [as findOne] (/app/node_modules/sails/node_modules/lodash/dist/lodash.js:729:21)
at Deferred.exec (/app/node_modules/sails/node_modules/waterline/lib/waterline/query/deferred.js:501:16)
at tryCatcher (/app/node_modules/sails/node_modules/waterline/node_modules/bluebird/js/main/util.js:26:23)
at ret (eval at <anonymous> (/app/node_modules/sails/node_modules/waterline/node_modules/bluebird/js/main/promisify.js:163:12), <anonymous>:13:39)
at Deferred.toPromise (/app/node_modules/sails/node_modules/waterline/lib/waterline/query/deferred.js:510:61)
at Deferred.then (/app/node_modules/sails/node_modules/waterline/lib/waterline/query/deferred.js:521:15)
at Strategy._verify (/app/api/services/passport.js:31:7)
at Strategy.authenticate (/app/node_modules/passport-local/lib/strategy.js:90:12)
at attempt (/app/node_modules/passport/lib/middleware/authenticate.js:341:16)
at authenticate (/app/node_modules/passport/lib/middleware/authenticate.js:342:7)
at Object.AuthController.login (/app/api/controllers/AuthController.js:119:5)
at bound (/app/node_modules/sails/node_modules/lodash/dist/lodash.js:729:21)
at routeTargetFnWrapper (/app/node_modules/sails/lib/router/bind.js:179:5)
at callbacks (/app/node_modules/sails/node_modules/express/lib/router/index.js:164:37)
Error (E_UNKNOWN) :: Encountered an unexpected error :
Could not connect to MySQL: Error: Pool is closed.
at afterwards (/app/node_modules/sails-mysql/lib/connections/spawn.js:72:13)
at /app/node_modules/sails-mysql/lib/connections/spawn.js:40:7
at process._tickDomainCallback (node.js:381:11)
Looking at the errors alone, I'd be tempted to say that we have something misconfigured. But the fact that it works some of the time (and has previously been working fine!) leads me to believe that there's some other black magic at work here. Our Cloud SQL instance is D0 (though we've tried upping the size to D4) and our activation policy is "Always On".
EDIT: I had seen others complain about Google Cloud SQL eg. this SO post and I was suspicious but we have since moved our database to Amazon RDS and we are still seeing the same issues, so it must be a problem with sails and the mysql adapter.
This issue is leading to hours of downtime a day, we need it resolved, any help is much appreciated!
This appears to be a sails issue, and not necessarily related to Cloud SQL.
Is there any way the QPS limit for Google Cloud SQL is being reached? See here: https://cloud.google.com/sql/faq#sizeqps
Why is my database instance sometimes slow to respond?
In order to minimize the amount you are charged for instances on per use billing plans, by default your instance becomes passive if it is not accessed for 15 minutes. The next time it is accessed there will be a short delay while it is activated. You can change this behavior by configuring the activation policy of the instance. For an example, see Editing an Instance Using the Cloud SDK.
It might be related to your policy setting. If you set it to ON_DEMAND, the instance will sleep to save your budget so that the first query to activate the instance is slow. This might cause the timeout.
https://cloud.google.com/sql/faq?hl=en
SSIS package in question runs a series of stored procedures and fills 13 different excel files with results and sends those excel files to 13 different users in attachments. Package run stops with the message in the title of this question, sometime right in the middle of sending or for example today, on the 4th user. The files get created because I can see them in their directories so only the send mail task is failing. When I go back to visual studio and execute each send task manually, send task works fine even though sometime it still gives me the error yet, still sends the right file to the right person but not thru SSIS package run in SQL server... I tried to delay SMTP processes thinking that might be in the way (to 660000 miliseconds) but did not help. Has this happened to anybody?.. Thanks for all your answers in advance.
Here is the full message for a task that sent the e-mail with attachment regardless the error when task was manually executed...
[Send Mail Task] Error: An error occurred with the following error message: "The operation has timed out.".
Progress: The SendMail task is completed. - 100 percent complete
Task Send Mail Task for Inventory Reports 038 failed
Finished, 12:03:03 PM, Elapsed time: 00:00:00.655
I think I figured it out why this was happening. In case somebody / anybody is interested, here is what I think has happened.
I was trying to expand the timeout period thru a script task, playing with Threading.Thread.Sleep value but I neglected to do the same in my SMTP connection properties. When I changed the timeout value in properties for SMTP connection, error messages stopped coming :)
I wish I could post a picture to show you where exactly that property is located but my reputation failed me!.. :( (less than 10 points yet)
I am in the process of completing all of my changes then I will post again with final result hoping that will resolve all of my problems.
Thanks to all who showed interest.
I am using CRM 4.0 SSRS. I can display reports which take a long time. When a report displays I can export to Excel, XML or another file type within in 10 minutes. But after exactly 10 minutes, I cannot export reports to Excel or other formats.
Report message is :
The report execution ifjzab55k5icxl4510oyfsmt has expired or cannot be found. (rsExecutionNotFound)
Report Server Log Text:
ERROR: Throwing Microsoft.ReportingServices.Diagnostics.Utilities.ReportServerStorageException: , An error occurred within the report server database. This may be due to a connection failure, timeout or low disk condition within the database.;
session!ReportServer_0-10!17c8!05/09/2013-16:03:14:: e ERROR: Error in getting session data: Expired Session: qkmiqv455sdu5wyc2sa23az1
session!ReportServer_0-10!17c8!05/09/2013-16:03:14:: i INFO: LoadSnapshot: Item with session: qkmiqv455sdu5wyc2sa23az1, reportPath: , userName: VRVENDING\crm.service not found in the database
library!ReportServer_0-10!17c8!05/09/2013-16:03:14:: e ERROR: Throwing Microsoft.ReportingServices.Diagnostics.Utilities.ExecutionNotFoundException: , Microsoft.ReportingServices.Diagnostics.Utilities.ExecutionNotFoundException: The report execution qkmiqv455sdu5wyc2sa23az1 has expired or cannot be found"
This is happening because the session that SSRS was using to store your reports data has expired, releasing the cached data; so when you attempt to export there's nothing there to export. Simply clicking "View Report" again should rebuild that cache, and allow you to export, however I can understand that not being the ideal user experience.
2 things I'd suggest trying:
Increase the session timeout for SSRS.
In the web.config, find the "httpRuntime" element, and add a "RequestLength" property to it, set that value to something absurdly high, like 100000, and see if that helps. (do this in both the reportserver and reportmanager web.configs)
Given the error message, I doubt that the 2nd one is your issue, but still may be worth checking out, as I've seen similar behavior that was fixed with that (albeit with a much different error message).
You could also try tinkering with the reports snapshot settings, however the amount of overhead that introduce on your server may outweigh the benefits of letting people export their report...
I am writing an instant messaging library. Currently, when a SocketException is raised while reading or writing to the socket, I start the logout routine from inside the application, passing the SocketException to the enduser as an argument of the LogoutEventArgs. This gives the end user a way of seeing what underlying exception actually caused the unrequested logout.
My question, is what am I to do, if during a user call to the Logout function, the socket actually throws an Exception.
Example - End user calls Logout function, and while the logout function is waiting for existing requests to end gracefully, the socket throws an exception in the reading thread.
I have two options as I see it -
Pretend the error didn't occur, and just act like the socket disconnected as part of our Logout.
When the socket exception is raised, see if a logout request is taking place, and if so, override it. Resulting in the original Logout request throwing an AlreadyLoggedOutException, as well as a separate logout event which passes the exception in the LogoutEventArgs.
Also, slightly related - What am I to do if the server initiates a shutdown that wasn't requested (ie.. the read call returns null).. the .NET Messenger server has a tendency to do this if you send a request it doesn't like. Do I treat this as an exception in itself?
I have found the whole disconnecting/logging out part of my library to be a major thorn in my side. I just can't seem to wrap my head around it. Does anyone know of any open source code applications that handle this situation beautifully?
I have been trying to tackle this thing in my head for so long, it's driving me mad.
I decided not to pass the SocketException to the end user, as a disconnect is not truly an exception and should be expected and dealt with. Instead there is a LogoutReason property on the LogoutEventArgs which specifies why the logout occured.
I decided that if the disconnect occurs during Logout then that's not actually an exception for, as the logout was going to disconnect anyway. I simply disregard the exception in this case.