Creating reports and dashboards | Stimulsoft community forum

Hello,

In one of my reports, I am getting this exception:

MySql.Data.MySqlClient.MySqlException (0x80004005): Authentication to host '<myserver>' for user '<myuser>' using method 'mysql_native_password' failed with message: Reading from the stream has failed. ---> MySql.Data.MySqlClient.MySqlException (0x80004005): Reading from the stream has failed. ---> System.IO.EndOfStreamException: Attempted to read past the end of the stream.

Background:
We are using Visual Studio 2015.

When I run the reports individually, this works fine.
When I run the reports, e.g. in a big for loop, deployed in a Azure Worker Role (similar to a windows service), I get the above error.

In our .Net code, we wrap our code in the 'using' statement, like this

using (StiReport report = new StiReport())
{
// pseudo code:
report.Load(reportPath);
report.Compile();
(report.CompiledReport.Dictionary.Databases["MasterData"] as StiMySqlDatabase).ConnectionString = _connectionStringMasterDb;
report.Render(false);

// then, we export the report to PDF
}

We then have mapped our sql command like this:
<SqlCommand>CALL `my_stored_proc`(@param1, @param2);</SqlCommand>

My main question - how do I solve this problem? Namely, what is the best practice to manage the database connections?

Thank you.

Hello,

We have found similar issue on
https://bugs.mysql.com/bug.php?id=76597

And the workaround for this issues:

[23 Jan 20:21] Guy Jackman
For anyone having this problem specifically when running in the context of a Windows Scheduled Task, I've finally found a fix that is working for me.

It turns out that scheduled tasks are launched, by default, at a very low process priority relative to the priority that a task gets when launched interactively. I noticed that my particular application, launched as a scheduled task, executed an order of magnitude more slowly.

I can't explain why this would cause a specific MySQL client issue, but perhaps there is a timing critical section of the connection code that causes the problem. I was having the problem, more or less consistently, for weeks. Since the change in priority, I've had no problems for 3 days straight.

If you want to try this solution, here are the steps:
1.Create the task
2.Right click on the task and "export" it
3.Edit the task.xml file that you just exported
4.You will find a line similar to <Priority>7</Priority>
5.Change the value to a normal priority (between 4-6, I used 5)
6.In the task scheduler, delete the task you initially created
7.In the task scheduler, in the actions area, import the task from the XML file

I found this information here: http://serverfault.com/a/257183

Thank you.

Thank you for your assistance.
We are using Azure Worker Role, and I don't see any such setting to change priority.

FYI, as additional information
We have a number of requests messages sent to the Service Bus Queue
We read these messages
and generate these reports using Stimulsoft.

There is some multi-threaded scenarios happening, as Azure Service Bus... but all our code should be creating new instances of everything, and there's no sharing.

--
So the question remains - I want to know how to close a connection open by Stimulsoft. How do I do that?
I am view client connections and after running various reports, the connections are still showing up in "My Sql Workbench 'Client Connections'. May be related?
but

Hello,

Please clarify which version are you use?
Also, please check the last version. Were made many changes and optimizations in this direction.

Thank you.

As a further update, I have a feeling this might be related to being thread-safe? Or MySql being overloaded and the .net connector to the database is dropping connections?
I decreased the number of concurrent connections from the Azure Worker Role reading the Service Bus Queue to 1... and now I don't have problems.

But I'd still like to know why this is failing and best practice for managing these db connections.

We are using version 2016.3

Please advise,
Thank you

Hello,

We couldn't reproduce this problem on our test samples.
We will try to investigate the issue, we will let you know about the result.

Thank you.