Try to install a new c5-8.3.1 without result. I try php 5.6.32 and php 7.0.26 with the same errors.
When I try to install with the full site, Installation crashes during the import files session with error:
An exception occurred while executing 'SELECT t0.fslName AS fslName_1, t0.fslConfiguration AS fslConfiguration_2, t0.fslID AS fslID_3, t0.fslIsDefault AS fslIsDefault_4 FROM FileStorageLocations t0 WHERE t0.fslIsDefault = ? LIMIT 1' with params [1]: Error while sending QUERY packet. PID=5877.
Trace:
0 /home/u960240172/public_html/new/concrete/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(855):
Doctrine\DBAL\DBALException::driverExceptionDuringQuery(Object(Concrete\Core\Database\Driver\PDOMySqlConcrete5\Driver),
Object(Whoops\Exception\ErrorException), 'SELECT t0.fslNa...', Array)
.. follows 30 traces
When I try the Empty site option, it goes through, but when I log in as an Admin I get another error:
An unexpected error occurred.
An exception occurred while executing 'SHOW FULL TABLES WHERE Table_type = 'BASE TABLE'': SQLSTATE[HY000]: General error: 2006 MySQL server has gone away
Any Idea?
This is a MySQL server error, not concrete5's.
See: Error while sending QUERY packet
Error while sending QUERY packet
Related
I got an ER_NET_PACKETS_OUT_OF_ORDER error when running a multithreaded C++ app using Poco::Data::MySQL and Poco::Data::SessionPool. The error message looks like this:
MySQL: [MySQL]: [Comment]: mysql_stmt_prepare error [mysql_stmt_error]: Got packets out of order [mysql_stmt_errno]: 1156 [mysql_stmt_sqlstate]: 08S01 [statemnt]: ...
The app is making queries from multiple threads every 100ms. The connections are provided by a common SessionPool.
I got around this problem by adding reset=true to the connection string. However, as stated in the official docs, adding this option may result in problems with encoding.
I scheduled around 70 concurrent queries using 70 logins to stress test Azure DW (DWU 200) and after a while started getting this error
[Execute SQL Task]
Error: Executing the query "SELECT Distinct S.[Nurse ID],S.[Trust Code],S.[Loc..." failed with the following error: "110802;An internal DMS error occurred that caused this operation to fail.
Details:
Exception: Microsoft.SqlServer.DataWarehouse.DataMovement.Workers.DmsSqlNativeException, Message: NativeOdbcConnection.Open, error in OdbcConnectionCreate: SqlState: HY000, NativeError: 10928, 'Error calling: SQLExecDirect(hstmt, (SQLWCHAR *) L"SELECT ##SPID", SQL_NTS), SQL return code: -1 |
SQL Error Info: SrvrMsgState: 1, SrvrSeverity: 20, Error <1>: ErrorMsg: [Microsoft][ODBC Driver 13 for SQL Server][SQL Server]Resource ID : 1. The request limit for the database is 1600 and has been reached. See 'http://go.microsoft.com/fwlink/?LinkId=267637' for assistance. |
ConnectionString: Driver={pdwodbc};APP=TypeC01-DmsNativeReader:DB22\mpdwsvc (69820)-ODBC;Trusted_Connection=yes;AutoTranslate=no;Server=\\.\pipe\DB.22-f8e91ff83e68\sql\query, ConnectionPooling: 1 | Error calling: pConn->Create(connectionString, useConnectionPooling, packetSize, connectionLoginTimeout, environmentSettings, spid) | state: FFFF, number: 19183, active connections: 266', Connection String: Driver={pdwodbc};APP=TypeC01-DmsNativeReader:DB22\mpdwsvc (69820)-ODBC;Trusted_Connection=yes;AutoTranslate=no;Server=\\.\pipe\DB.22-f8e91ff83e68\sql\query".
Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
But I can't find a corresponding 1600 limit, neither can I understand how I could have hit it? Any help would be truly appreciated, thanks.
Have you read the concurrency article on Azure.com? You are stress testing at 70 concurrent queries at a scale level that will, by design begin queueing those requests. My suspicion is that your queue of queued requests is increasing throughout your load test until you hit one of the limits in the system. The limit I expect you are hitting is the number of open sessions.
If you would like to be certain that is the case then you would need to open a support ticket. However, I would also suggest increasing the DWU to a higher figure if you want to run at 70 concurrent queries in a saturated load test.
I am using avahi for service advertisement and discovery.
As we all know avahi needs dbus as well and hence dbus-1.6.8 library is also added.
i am starting dbus-daemon and avahi-daemon at startup. both daemons are running, which i could see in process list.
But when I try to create avahi client, ::avahi_client_new call fails with error "An unexpected D-Bus error occured", which is AVAHI_ERR_DBUS_ERROR = -22, /**< An unexpected D-Bus error occured */
Bellow is my function all.
Client = ::avahi_client_new(
::avahi_threaded_poll_get(Poll),
static_cast<AvahiClientFlags>(0),
&AvahiWrapper::OnClientStateChange,
NULL,
&error);
PS: Poll = ::avahi_threaded_poll_new(); is successful.
Please let me if anyone has any clue on this problem. Or at-least how to debug.
Thanks in advance.
We are getting deadlocks inside DMS at least 30% of the time or more on several of the larger sprocs which truncate and insert several million rows. However, there is only one query running, so I don't see how the deadlock can be my fault:
Msg 110802, Level 16, State 1, Line 1
110802;An internal DMS error occurred that caused this operation to fail. Details: Exception: Microsoft.SqlServer.DataWarehouse.DataMovement.Workers.DmsSqlNativeException, Message: SqlNativeBufferReader.Run, error in OdbcExecuteQuery: SqlState: 40001, NativeError: 1205, 'Error calling: SQLExecDirect(this->GetHstmt(), (SQLWCHAR *)statementText, SQL_NTS), SQL return code: -1 | SQL Error Info: SrvrMsgState: 71, SrvrSeverity: 13, Error <1>: ErrorMsg: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Transaction (Process ID 2265) was deadlocked on lock | generic waitable object resources with another process and has been chosen as the deadlock victim. Rerun the transaction. | Error calling: pReadConn->ExecuteQuery(statementText, bufferFormat) | state: FFFF, number: 7801, active connections: 120', Connection String: Driver={pdwodbc};APP=TypeC01-DmsNativeReader:DB3\mpdwsvc (13732)-ODBC;Trusted_Connection=yes;AutoTranslate=no;Server=\\.\pipe\DB.3-b6c0a7b26544\sql\query
And:
110802;An internal DMS error occurred that caused this operation to fail. Details: Exception: Microsoft.SqlServer.DataWarehouse.DataMovement.Workers.DmsSqlNativeException, Message: SqlNativeBufferReader.Run, error in OdbcExecuteQuery: SqlState: 40001, NativeError: 1205, 'Error calling: SQLExecDirect(this->GetHstmt(), (SQLWCHAR *)statementText, SQL_NTS), SQL return code: -1 | SQL Error Info: SrvrMsgState: 71, SrvrSeverity: 13, Error <1>: ErrorMsg: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Transaction (Process ID 804) was deadlocked on lock | generic waitable object resources with another process and has been chosen as the deadlock victim. Rerun the transaction. | Error calling: pReadConn->ExecuteQuery(statementText, bufferFormat) | state: FFFF, number: 8106, active connections: 240', Connection String: Driver={pdwodbc};APP=TypeC01-DmsNativeReader:DB38\mpdwsvc (14728)-ODBC;Trusted_Connection=yes;AutoTranslate=no;Server=\\.\pipe\DB.38-b6c0a7b26544\sql\query
Does this point at something obvious to check or fix? Or is an Azure support case the best road to a resolution?
update: support case 115111713384329 is open for this issue
update: our SQL DW got a new update March 4, 2016 which supposedly fixes this issue. (I can't reproduce it on demand so I can't say for sure.) If you run "select ##version" then
10.0.8224.5 or higher should have the fix. If you don't have the fix yet I would imagine opening a support case and requesting it or waiting a few weeks would get you the fix.
Creating an Azure support case would be best in this case. If you can share your stored procedure, that would help us root cause.
I'm running a django-celery application on Ubuntu-12.04.
When I run a celery task from my web interface, I get the following error, taken form postgresql-9.3 logfile (maximum level of log):
2013-11-12 13:57:01 GMT tss_usr 8113 LOG: could not receive data from client: Connection reset by peer
tss_usr is the postgresql user of the django application database and (in this example) 8113 is the pid of the process who killed the connection, I guess.
Have you got any idea on why this happens or at least how to debug this issue?
To make things work again I need to restart postgresql which is extremely uncomfortable.
I know this is an older post, but I just found it because I had the same error today in my postgres logs. I narrowed it down to a PDO select statement. I'm using Zend Framework 1.10.3 on Ubuntu Precise.
The following pdo statement generated an error if $opinion is a long text string. The column opinion is type Text in my postgres table. The query succeeds if $opinion is under a certain number of characters. 1000 characters works fine. 2000 characters fails with "could not receive data from client: Connection reset by peer".
$select = $this->db->select()
->from( 'datauserstopics' )
->where("opinion = ?",trim($opinion))
->where("datatopicsid = ?",trim($tid))
->where("datausersid= ?",$datausersid);
$stmt = $this->db->query($select);
I circumvented the problem by using:
->where("substr(opinion,1,100) = ?",trim(substr($opinion,1,100)))
This is not a perfect solution, but for my purposes, the select statement using substr() suffices.
Note that I have no problem inserting long strings into the same table/column. The disconnect problem only appears for me on the PDO select with relatively long text strings.
I'm getting it in 2017 with 9.4, I have no text fields, don't know what a PDO is. My select statement is about 50 bytes long, I'm trying to fetch an int4 and a double precision. I suspect the error message can mean multiple things.
I've since found https://dba.stackexchange.com/questions/142350/postgres-could-not-receive-data-from-client-connection-reset-by-peer which indicates it could be a problem with the client configuration. My client is libpg and PQconnectdb() is giving me a CONNECTION_OK return. It works at least partly.
For me, restarting the hypervisor where both the Postgres and the application using it helped. I've seen stack traces in dmesg before, though.