Есть такая проблема (
При кроссерверных запросах иногда выпадает следующая ошибка «Connection timed out after 15000 milliseconds» , на php установлен timeout 15 сек.
Каждую минуту на удаленные хосты в среднем отправляется 300 запросов и в таком режиме каждые 15 мин происходит от 1 — 10 таких ошибок. Если после такой ошибки снова отправить такой же запрос, на тот же хост — он мгновенно пройдет . Это может возникать при запросах на любые удаленные хосты.
Установлен входящий nginx proxy .
Архитектура сервера : host (nginx proxy, kvm host) -> virtual machine (nginx, php …) везде ubuntu server 16.04
Как решить эту проблему?
-
Вопрос заданболее трёх лет назад
-
2486 просмотров
Пригласить эксперта
нельзя выставлять столь длинные значения таймаута, смысл его тогда теряется.
Стольо длинные хиты это явно или выгрузки или работа по апи.
А следовательно наличие сервера с той стороны и доступности его не дело nginx
а легко решается в самом скрипте обмена.
Что же касается времяни то именно для этого скрипта можно сделать исключение позволяющее делать таймаут вплоть до -1
Но при этом общая система не пострадает.
попробуйте увеличить число одновременно открытых дескрипторов файлов в /etc/security/limits.conf — по умолчанию — 1024
* soft nofile 65535
* hard nofile 65535
Ну и сами удаленные хосты тоже могут не отвечать иногда, их право!
Запросы небольшие?
Что делает другой сервер при этом?
Проверьте использование памяти (свап), диска, нагрузку сети и процессора как на гипервизор так и на виртуалки.
Просмотрите логи виртуалки нет ли там ошибок от что виртуалка замирает.
Попробуйте отправлять ежесекундно мелкие udp/tcp запросы в обе стороны и пишите их в файл. Отправляемые данные пронумеруйте и затем посмотрите не выпадает ли что-то. Поснифьте tcpdump-ом трафик который отправляете/принимаете с обеих сторон.
Проверить драйвера сетевых карт.
Посмотреть настройки и статистику файрвола.
Проверьте использование памяти (свап), диска, нагрузку сети и процессора как на гипервизор так и на виртуалки.
С этим все норм …
-
Показать ещё
Загружается…
05 июн. 2023, в 17:51
2800 руб./в час
05 июн. 2023, в 17:46
4500 руб./за проект
05 июн. 2023, в 17:42
15000 руб./за проект
Минуточку внимания
Есть такая проблема (
При кроссерверных запросах иногда выпадает следующая ошибка «Connection timed out after 15000 milliseconds» , на php установлен timeout 15 сек.
Каждую минуту на удаленные хосты в среднем отправляется 300 запросов и в таком режиме каждые 15 мин происходит от 1 — 10 таких ошибок. Если после такой ошибки снова отправить такой же запрос, на тот же хост — он мгновенно пройдет . Это может возникать при запросах на любые удаленные хосты.
Установлен входящий nginx proxy .
Архитектура сервера : host (nginx proxy, kvm host) -> virtual machine (nginx, php …) везде ubuntu server 16.04
Как решить эту проблему?
-
Вопрос заданболее трёх лет назад
-
2378 просмотров
Пригласить эксперта
нельзя выставлять столь длинные значения таймаута, смысл его тогда теряется.
Стольо длинные хиты это явно или выгрузки или работа по апи.
А следовательно наличие сервера с той стороны и доступности его не дело nginx
а легко решается в самом скрипте обмена.
Что же касается времяни то именно для этого скрипта можно сделать исключение позволяющее делать таймаут вплоть до -1
Но при этом общая система не пострадает.
попробуйте увеличить число одновременно открытых дескрипторов файлов в /etc/security/limits.conf — по умолчанию — 1024
* soft nofile 65535
* hard nofile 65535
Ну и сами удаленные хосты тоже могут не отвечать иногда, их право!
Запросы небольшие?
Что делает другой сервер при этом?
Проверьте использование памяти (свап), диска, нагрузку сети и процессора как на гипервизор так и на виртуалки.
Просмотрите логи виртуалки нет ли там ошибок от что виртуалка замирает.
Попробуйте отправлять ежесекундно мелкие udp/tcp запросы в обе стороны и пишите их в файл. Отправляемые данные пронумеруйте и затем посмотрите не выпадает ли что-то. Поснифьте tcpdump-ом трафик который отправляете/принимаете с обеих сторон.
Проверить драйвера сетевых карт.
Посмотреть настройки и статистику файрвола.
Проверьте использование памяти (свап), диска, нагрузку сети и процессора как на гипервизор так и на виртуалки.
С этим все норм …
-
Показать ещё
Загружается…
30 янв. 2023, в 11:41
1600 руб./в час
30 янв. 2023, в 11:09
1000 руб./за проект
30 янв. 2023, в 10:45
25000 руб./за проект
Минуточку внимания
timeout of 15000ms exceeded
anonymous
- 3 года назад
- обновлен 3 года назад
- Исправлен
Что это за ошибка В МОЙ ФТИС ЕГРН
Прикрепленные ответы
Специалист Техподдержки
- 3 года назад
- Ответ
- На рассмотрении
Здравствуйте.
Такая ошибка может возникнуть при поиске объектов, когда Росреестр висит и не отвечает.
Ответы 2
-
Новые сверху
Новые сверху
Старые сверху
Специалист Техподдержки
- 3 года назад
- Исправлен
Специалист Техподдержки
- 3 года назад
- Ответ
- На рассмотрении
Здравствуйте.
Такая ошибка может возникнуть при поиске объектов, когда Росреестр висит и не отвечает.
Войти, чтобы оставить комментарий
Подтверждение
Issue: unable to set requestTimeout with configuration parameter for «mssql» dilect
No matter whatever value is in requestTimeout parameter, the driver sets default value of «15000ms».
Hence, Timeout error occurs for all query that takes longer than 15s.
Application log is as follows:
Executing (default): SELECT [AnalysisTagID], [RefDate], [CategorySet], [AssetID], [Category] FROM [EMA_RiskAllocCategoriesView] AS [EMA_RiskAllocCategoriesView] ORDER BY [EMA_RiskAllocCategoriesView].[AssetID] OFFSET 0 ROWS FETCH NEXT 3 ROWS ONLY;
Error EMA_RiskAllocCategoriesView.getAll DatabaseError [SequelizeDatabaseError]: Timeout: Request failed to complete in 15000ms
at Query.formatError (/Users/abinash/Desktop/my-app/new-dashboard/ember-electron/resources/sapiat-server/node_modules/sequelize/lib/dialects/mssql/query.js:309:12)
at Request.userCallback (/Users/abinash/Desktop/my-app/new-dashboard/ember-electron/resources/sapiat-server/node_modules/sequelize/lib/dialects/mssql/query.js:69:23)
at Request.callback (/Users/abinash/Desktop/my-app/new-dashboard/ember-electron/resources/sapiat-server/node_modules/tedious/lib/request.js:37:27)
at Connection.message (/Users/abinash/Desktop/my-app/new-dashboard/ember-electron/resources/sapiat-server/node_modules/tedious/lib/connection.js:2181:24)
at Connection.dispatchEvent (/Users/abinash/Desktop/my-app/new-dashboard/ember-electron/resources/sapiat-server/node_modules/tedious/lib/connection.js:1172:36)
at MessageIO.<anonymous> (/Users/abinash/Desktop/my-app/new-dashboard/ember-electron/resources/sapiat-server/node_modules/tedious/lib/connection.js:1045:14)
at MessageIO.emit (events.js:200:13)
at Message.<anonymous> (/Users/abinash/Desktop/my-app/new-dashboard/ember-electron/resources/sapiat-server/node_modules/tedious/lib/message-io.js:32:14)
at Message.emit (events.js:205:15)
at endReadableNT (/Users/abinash/Desktop/my-app/new-dashboard/ember-electron/resources/sapiat-server/node_modules/tedious/node_modules/readable-stream/lib/_stream_readable.js:1077:12)
at processTicksAndRejections (internal/process/task_queues.js:84:9) {
name: 'SequelizeDatabaseError',
parent: RequestError: Timeout: Request failed to complete in 15000ms
at RequestError (/Users/abinash/Desktop/my-app/new-dashboard/ember-electron/resources/sapiat-server/node_modules/tedious/lib/errors.js:32:12)
at Connection.requestTimeout (/Users/abinash/Desktop/my-app/new-dashboard/ember-electron/resources/sapiat-server/node_modules/tedious/lib/connection.js:1117:21)
at Timeout._onTimeout (/Users/abinash/Desktop/my-app/new-dashboard/ember-electron/resources/sapiat-server/node_modules/tedious/lib/connection.js:1085:14)
at listOnTimeout (internal/timers.js:531:17)
at processTimers (internal/timers.js:475:7) {
message: 'Timeout: Request failed to complete in 15000ms',
code: 'ETIMEOUT',
sql: 'SELECT [AnalysisTagID], [RefDate], [CategorySet], ' +
'[AssetID], [Category] FROM [EMA_RiskAllocCategoriesView] ' +
'AS [EMA_RiskAllocCategoriesView] ORDER BY ' +
'[EMA_RiskAllocCategoriesView].[AssetID] OFFSET 0 ROWS ' +
'FETCH NEXT 3 ROWS ONLY;'
},
What are you doing?
sequelize is instantiated as follows where requestTimeout is set to 30s
const sequelize = new Sequelize(config.db.schema, config.db.username, config.db.password, { "host": config.db.url, "dialect": "mssql", "dialectOptions": { "requestTimeout": 300000 }, pool: { max: 5, min: 0, acquire: 30000, idle: 10000 } });
A query that does full scan in a large table is run as follows:
EMA_RiskAllocCategoriesView.findAll({
}).catch((err)=>{
console.log("Error EMA_RiskAllocCategoriesView.getAll",err)
});
To Reproduce
Steps to reproduce the behavior:
- Initiate sequelize with requestTimeout set to 30s
- Use a query that takes longer than 15s
- See error which says «Request failed to complete in 15000ms»
What do you expect to happen?
Not thow request timeout error for queries that run for 30s if sequelize is set to have requestTimeout of 30s.
What is actually happening?
Timeout Error for all query that takes longer than 15 s
Output, either JSON or SQL
Executing (default): SELECT [AnalysisTagID], [RefDate], [CategorySet], [AssetID], [Category] FROM [EMA_RiskAllocCategoriesView] AS [EMA_RiskAllocCategoriesView] ORDER BY [EMA_RiskAllocCategoriesView].[AssetID] OFFSET 0 ROWS FETCH NEXT 3 ROWS ONLY;
Error EMA_RiskAllocCategoriesView.getAll DatabaseError [SequelizeDatabaseError]: Timeout: Request failed to complete in 15000ms
at Query.formatError (/Users/abinash/Desktop/my-app/new-dashboard/ember-electron/resources/sapiat-server/node_modules/sequelize/lib/dialects/mssql/query.js:309:12)
at Request.userCallback (/Users/abinash/Desktop/my-app/new-dashboard/ember-electron/resources/sapiat-server/node_modules/sequelize/lib/dialects/mssql/query.js:69:23)
at Request.callback (/Users/abinash/Desktop/my-app/new-dashboard/ember-electron/resources/sapiat-server/node_modules/tedious/lib/request.js:37:27)
at Connection.message (/Users/abinash/Desktop/my-app/new-dashboard/ember-electron/resources/sapiat-server/node_modules/tedious/lib/connection.js:2181:24)
at Connection.dispatchEvent (/Users/abinash/Desktop/my-app/new-dashboard/ember-electron/resources/sapiat-server/node_modules/tedious/lib/connection.js:1172:36)
at MessageIO.<anonymous> (/Users/abinash/Desktop/my-app/new-dashboard/ember-electron/resources/sapiat-server/node_modules/tedious/lib/connection.js:1045:14)
at MessageIO.emit (events.js:200:13)
at Message.<anonymous> (/Users/abinash/Desktop/my-app/new-dashboard/ember-electron/resources/sapiat-server/node_modules/tedious/lib/message-io.js:32:14)
at Message.emit (events.js:205:15)
at endReadableNT (/Users/abinash/Desktop/my-app/new-dashboard/ember-electron/resources/sapiat-server/node_modules/tedious/node_modules/readable-stream/lib/_stream_readable.js:1077:12)
at processTicksAndRejections (internal/process/task_queues.js:84:9) {
name: 'SequelizeDatabaseError',
parent: RequestError: Timeout: Request failed to complete in 15000ms
at RequestError (/Users/abinash/Desktop/my-app/new-dashboard/ember-electron/resources/sapiat-server/node_modules/tedious/lib/errors.js:32:12)
at Connection.requestTimeout (/Users/abinash/Desktop/my-app/new-dashboard/ember-electron/resources/sapiat-server/node_modules/tedious/lib/connection.js:1117:21)
at Timeout._onTimeout (/Users/abinash/Desktop/my-app/new-dashboard/ember-electron/resources/sapiat-server/node_modules/tedious/lib/connection.js:1085:14)
at listOnTimeout (internal/timers.js:531:17)
at processTimers (internal/timers.js:475:7) {
message: 'Timeout: Request failed to complete in 15000ms',
code: 'ETIMEOUT',
sql: 'SELECT [AnalysisTagID], [RefDate], [CategorySet], ' +
'[AssetID], [Category] FROM [EMA_RiskAllocCategoriesView] ' +
'AS [EMA_RiskAllocCategoriesView] ORDER BY ' +
'[EMA_RiskAllocCategoriesView].[AssetID] OFFSET 0 ROWS ' +
'FETCH NEXT 3 ROWS ONLY;'
},
Environment
Dialect:
- mssql
Dialect library version: tedious 6.1.2
Database version: mcr.microsoft.com/mssql/server:2017-latest (docker)
Sequelize version: 5.8.7
Node Version: v12.3.1
OS: osx
If TypeScript related: TypeScript version: XXX
Tested with latest release:
- No
Self investigation.
hard coded fix is to change the value of the following variable in «lib/connection.js» module of tedious library
const DEFAULT_CLIENT_REQUEST_TIMEOUT = 15 * 1000;
У меня есть 3 узла Akka Cluster, и на каждом узле кластера работают 3 субъекта. Кластер работает нормально около 2 часов, но через 2 часа я получаю следующее предупреждение:
[INFO] [06/07/2018 15:08:51.923] [ClusterSystem-akka.remote.default-remote-dispatcher-6] [akka.tcp://ClusterSystem@192.168.2.8:2552/system/transports/akkaprotocolmanager.tcp0/akkaProtocol-tcp%3A%2F%2FClusterSystem%40192.168.2.7%3A2552-112] No response from remote for outbound association. Handshake timed out after [15000 ms].
[WARN] [06/07/2018 15:08:51.923] [ClusterSystem-akka.remote.default-remote-dispatcher-18] [akka.tcp://ClusterSystem@192.168.2.8:2552/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FClusterSystem%40192.168.2.7%3A2552-8] Association with remote system [akka.tcp://ClusterSystem@192.168.2.7:2552] has failed, address is now gated for [5000] ms. Reason: [Association failed with [akka.tcp://ClusterSystem@192.168.2.7:2552]] Caused by: [No response from remote for outbound association. Handshake timed out after [15000 ms].]
[WARN] [06/07/2018 16:07:06.347] [ClusterSystem-akka.actor.default-dispatcher-101] [akka.remote.PhiAccrualFailureDetector@3895fa5b] heartbeat interval is growing too large: 2839 millis
Редактировать: Ответ Akka CLuster Managemant от API
{
"selfNode": "akka.tcp://ClusterSystem@127.0.0.1:2551",
"leader": "akka.tcp://ClusterSystem@127.0.0.1:2551",
"oldest": "akka.tcp://ClusterSystem@127.0.0.1:2551",
"unreachable": [
{
"node": "akka.tcp://ClusterSystem@127.0.0.1:2552",
"observedBy": [
"akka.tcp://ClusterSystem@127.0.0.1:2551",
"akka.tcp://ClusterSystem@127.0.0.1:2560"
]
}
],
"members": [
{
"node": "akka.tcp://ClusterSystem@127.0.0.1:2551",
"nodeUid": "105742380",
"status": "Up",
"roles": [
"Frontend",
"dc-default"
]
},
{
"node": "akka.tcp://ClusterSystem@127.0.0.1:2552",
"nodeUid": "-150160059",
"status": "Up",
"roles": [
"RuleExecutor",
"dc-default"
]
},
{
"node": "akka.tcp://ClusterSystem@127.0.0.1:2560",
"nodeUid": "-158907672",
"status": "Up",
"roles": [
"RuleExecutor",
"dc-default"
]
}
]
}
** Edit1: ** Конфигурация установки кластера и конфигурация детектора отказов
cluster {
jmx.multi-mbeans-in-same-jvm = on
roles = ["Frontend"]
seed-nodes = [
"akka.tcp://ClusterSystem@192.168.2.9:2551"]
auto-down-unreachable-after = off
failure-detector {
# FQCN of the failure detector implementation.
# It must implement akka.remote.FailureDetector and have
# a public constructor with a com.typesafe.config.Config and
# akka.actor.EventStream parameter.
implementation-class = "akka.remote.PhiAccrualFailureDetector"
# How often keep-alive heartbeat messages should be sent to each connection.
# heartbeat-interval = 10 s
# Defines the failure detector threshold.
# A low threshold is prone to generate many wrong suspicions but ensures
# a quick detection in the event of a real crash. Conversely, a high
# threshold generates fewer mistakes but needs more time to detect
# actual crashes.
threshold = 18.0
# Number of the samples of inter-heartbeat arrival times to adaptively
# calculate the failure timeout for connections.
max-sample-size = 1000
# Minimum standard deviation to use for the normal distribution in
# AccrualFailureDetector. Too low standard deviation might result in
# too much sensitivity for sudden, but normal, deviations in heartbeat
# inter arrival times.
min-std-deviation = 100 ms
# Number of potentially lost/delayed heartbeats that will be
# accepted before considering it to be an anomaly.
# This margin is important to be able to survive sudden, occasional,
# pauses in heartbeat arrivals, due to for example garbage collect or
# network drop.
acceptable-heartbeat-pause = 15 s
# Number of member nodes that each member will send heartbeat messages to,
# i.e. each node will be monitored by this number of other nodes.
monitored-by-nr-of-members = 2
# After the heartbeat request has been sent the first failure detection
# will start after this period, even though no heartbeat message has
# been received.
expected-response-after = 10 s
}
}
Я пытаюсь запустить хранимую процедуру в моей базе данных SQL с сервера узла, используя seriate. однако я получаю следующую ошибку, и я не уверен, почему. Я был бы очень признателен за вашу помощь.
Ошибка: { [RequestError: Ошибка SqlContext. Сбой на шаге «GetData» с: «Тайм-аут: запрос не выполнен i 15000 мс»] имя: «RequestError», сообщение: «Ошибка SqlContext. Сбой на шаге «GetData» с: «Запрос тайм-аута не выполнен за 15000 мс», код: «ETIMEOUT», номер: «ETIMEOUT», номер строки: не определено, состояние: не определено, класс: не определено, serverName: не определено, procName: не определено , PreviousErrors: [], шаг: ‘GetData’ }
Это мой код:
var sql = require( "seriate" );
var connection = {
name: "example-1",
user: "user",
password: "pass",
host: "host_ip",
database: "Test"
};
exports.getDataSql = function(req, res) {
var results = {};
sql.execute( connection, {
procedure: "GetData",
params: {
Name: {
type: sql.NVARCHAR(50),
val: "user2"
},
LName: {
type: sql.NVARCHAR(50),
val: "user1"
},
finalName: {
type: sql.NVARCHAR(50),
val: "user3"
}
}
}).then( function( results ) {
console.log("getting data: ");
res.json(results[0][0]);
}, function( err ) {
console.log( "Error", err );
res.status(500).send({ error: 'Something failed!' });
} );
};
3 ответа
Вероятно, вам нужно увеличить время ожидания запроса следующим образом:
var connection = {
name: "example-1",
user: "user",
password: "pass",
host: "host_ip",
database: "Test",
requestTimeout: 300000
};
Существует также свойство connectionTimeout, которое также может повлиять на вас. Но эта проблема, вероятно, является requestTimeout
9
ktam33
4 Май 2016 в 21:08
В моем случае ошибка связана с незафиксированной транзакцией. Закрытие SQL Management Studio освобождает таблицы, так как у меня была ошибка при совершении предыдущей транзакции из редактора.
0
Federico Caccia
15 Фев 2020 в 03:39
Я использую mssql, который реализует эта библиотека. mssql использует утомительно для подключения к удаленной базе данных. В моем случае я использовал его внутри функции Azure и не вызывал
pool.close()
В конце каждого выполнения, поэтому у него закончились соединения, а затем началось время ожидания. tedious, вероятно, должен предоставить лучшее описание ошибки.
0
Dharman
9 Дек 2020 в 17:54
I keep getting this error:
{«name»:»RequestError»,»message»:»Timeout: Request failed to complete in 15000ms»,»code»:»ETIMEOUT»,»number»:»ETIMEOUT»,»precedingErrors»:[]}
How do I increase the timeout for my request?
I am not sure if this is coming from the sql server database or from the node.js service?
How do I see what is happening with sql server from azure?
I have sql server management studio and visual studio so i can login to my database, but don’t see how to increase timeout etc.
Are there any parameters I set in node.js to increase timeout?
I found this:
http://azure.github.io/azure-mobile-apps-node/global.html#dataConfiguration
and presume I have to set something in my query object?
My node.js API that I call, searchService.js
var HttpStatus = require('http-status-codes');
module.exports = {
"post": function (req, res, next) {
var resultSet = {
TotalRecords: 0,
Results: null
};
var parameters = [
{ name: 'forumId', value: req.body.forumId },
{ name: 'registrantId', value: req.body.registrantId },
{ name: 'userId', value: req.azureMobile.user.id },
{ name: 'exclusive', value: req.body.exclusive },
{ name: 'type', value: req.body.type },
{ name: 'categoryIds', value: req.body.categoryIds.join(",") },
{ name: 'locationIds', value: req.body.locationIds.join(",") },
{ name: 'unitIds', value: req.body.unitIds.join(",") },
{ name: 'priceIds', value: req.body.priceIds.join(",") },
{ name: 'delimiter', value: "," }
];
console.log("parameters = " + JSON.stringify(parameters));
var query = {
sql: "exec SearchServicesStrictTotal @forumId, @registrantId, @userId, @exclusive, @type, @categoryIds, @locationIds, @unitIds, @priceIds, @delimiter",
parameters: parameters
};
req.azureMobile.data.execute(query)
.then(function(result) {
console.log("got result " + JSON.stringify(result));
resultSet.TotalRecords = result[0].Total;
res.status(HttpStatus.OK).send(resultSet);
}).catch(function(error){
console.log("error one " + JSON.stringify(error));
res.status(HttpStatus.BAD_REQUEST).send(error);
});
}
};
I keep getting this error:
{«name»:»RequestError»,»message»:»Timeout: Request failed to complete in 15000ms»,»code»:»ETIMEOUT»,»number»:»ETIMEOUT»,»precedingErrors»:[]}
How do I increase the timeout for my request?
I am not sure if this is coming from the sql server database or from the node.js service?
How do I see what is happening with sql server from azure?
I have sql server management studio and visual studio so i can login to my database, but don’t see how to increase timeout etc.
Are there any parameters I set in node.js to increase timeout?
I found this:
http://azure.github.io/azure-mobile-apps-node/global.html#dataConfiguration
and presume I have to set something in my query object?
My node.js API that I call, searchService.js
var HttpStatus = require('http-status-codes');
module.exports = {
"post": function (req, res, next) {
var resultSet = {
TotalRecords: 0,
Results: null
};
var parameters = [
{ name: 'forumId', value: req.body.forumId },
{ name: 'registrantId', value: req.body.registrantId },
{ name: 'userId', value: req.azureMobile.user.id },
{ name: 'exclusive', value: req.body.exclusive },
{ name: 'type', value: req.body.type },
{ name: 'categoryIds', value: req.body.categoryIds.join(",") },
{ name: 'locationIds', value: req.body.locationIds.join(",") },
{ name: 'unitIds', value: req.body.unitIds.join(",") },
{ name: 'priceIds', value: req.body.priceIds.join(",") },
{ name: 'delimiter', value: "," }
];
console.log("parameters = " + JSON.stringify(parameters));
var query = {
sql: "exec SearchServicesStrictTotal @forumId, @registrantId, @userId, @exclusive, @type, @categoryIds, @locationIds, @unitIds, @priceIds, @delimiter",
parameters: parameters
};
req.azureMobile.data.execute(query)
.then(function(result) {
console.log("got result " + JSON.stringify(result));
resultSet.TotalRecords = result[0].Total;
res.status(HttpStatus.OK).send(resultSet);
}).catch(function(error){
console.log("error one " + JSON.stringify(error));
res.status(HttpStatus.BAD_REQUEST).send(error);
});
}
};
Я пытаюсь запустить хранимую процедуру в моей базе данных SQL с сервера узлов с помощью seriate. однако я получаю следующую ошибку, и я не уверен, почему. Я бы очень признателен вам за вашу помощь.
Ошибка: {[RequestError: ошибка SqlContext. Не удалось выполнить шаг «GetData» с: «Тайм-аут: запрос не удалось завершить я 15000ms»] name: «RequestError», сообщение: «Ошибка SqlContext. Не удалось выполнить шаг «GetData» с: «Запрос на тайм-аут не завершился в 15000мс», код: «ETIMEOUT», номер: «ETIMEOUT», строка «Номер»: undefined, state: undefined, class: undefined, serverName: undefined, procName: undefined, beforeErrors: [], step: ‘GetData’}
Это мой код:
var sql = require( "seriate" );
var connection = {
name: "example-1",
user: "user",
password: "pass",
host: "host_ip",
database: "Test"
};exports.getDataSql = function(req, res) {
var results = {};sql.execute( connection, {
procedure: "GetData",
params: {
Name: {
type: sql.NVARCHAR(50),
val: "user2"
},
LName: {
type: sql.NVARCHAR(50),
val: "user1"
},
finalName: {
type: sql.NVARCHAR(50),
val: "user3"
}
}
}).then( function( results ) {
console.log("getting data: ");
res.json(results[0][0]);}, function( err ) {
console.log( "Error", err );
res.status(500).send({ error: 'Something failed!' });
} );
};
Getting these issues on the server after deploying the code. It’s working fine in localhost.
Even I am adding the dummy products ie
$data = [
'name' => 'TBI Test Product',
'type' => 'simple',
'regular_price' => '10.00',
'description' => 'Simple product full description.',
'short_description' => 'Simple product short description.',
'categories' => [
[
'id' => 1
]
],
'images' => [
[
'src' => 'http://demo.woothemes.com/woocommerce/wp-content/uploads/sites/56/2013/06/T_2_front.jpg'
],
[
'src' => 'http://demo.woothemes.com/woocommerce/wp-content/uploads/sites/56/2013/06/T_2_back.jpg'
]
]
];
$product = Product::create($data);
**Complete error is:**
message: "cURL Error: Operation timed out after 15001 milliseconds with 0 bytes received",…}
exception: "Exception"
file: "/home/development/public_html/project/vendor/codexshaper/laravel-woocommerce/src/Traits/WooCommerceTrait.php"
line: 63
message: "cURL Error: Operation timed out after 15001 milliseconds with 0 bytes received"
trace: [{,…}, {,…}, {,…}, {,…},…]
Вы видите ошибку «error cURL 28: Connection timed out» на вашем сайте WordPress?
Ошибка cURL 28 — это распространенная проблема WordPress REST API, которая может повлиять на производительность вашего веб-сайта и привести к его непредсказуемому поведению.
В этой статье мы покажем вам, как легко исправить проблему «error cURL 28: Connection timed out» на вашем веб-сайте WordPress.
Что такое cURL в WordPress?
CURL — это программная утилита, используемая WordPress и многими другими веб-приложениями для отправки и получения запросов данных с использованием URL-адресов.
WordPress использует cURL для обработки нескольких запросов API. Он доступен как расширение языка программирования PHP.
Библиотека cURL играет решающую роль в том, как WordPress работает за кулисами. Если он не настроен должным образом, ваш веб-сайт WordPress не будет работать должным образом.
Что вызывает ошибку cURL 28 в WordPress?
Неспособность своевременно ответить на запросы данных сервера вызывает ошибку 28 cURL в WordPress.
WordPress использует REST API (метод программирования) для отправки и получения запросов данных. Если время ожидания этих запросов истекло, вы увидите это как критическую проблему в отчете о работоспособности сайта с заголовком «error REST API».
Расширение ошибки покажет вам дополнительную информацию, включая сообщение об ошибке:
Error: cURL error 28: Operation timed out after x milliseconds with x bytes received (http_request_failed)
Вы также можете увидеть другую связанную проблему с заголовком ‘Your site could not complete a loopback request’. Он будет иметь аналогичное сообщение об ошибке со следующим описанием.
‘The loopback request to your site failed, this means features relying on them are not currently working as expected.’
Что может вызвать тайм-аут cURL?
Ряд сценариев может вызвать тайм-аут cURL в WordPress.
Например, плагин брандмауэра WordPress может блокировать запрос REST API, считая его подозрительным действием.
Если ваш DNS-сервер работает некорректно, это также может привести к сбою HTTP-запросов и вызвать ошибку тайм-аута cURL в WordPress.
Плохо настроенный хостинг-сервер WordPress может просто иметь очень низкий порог тайм-аута, что может помешать правильной работе определенных процессов WordPress.
При этом давайте посмотрим, как устранить и исправить проблему ‘curl error 28: Connection timed out’ в WordPress.
1. Временно отключите брандмауэр WordPress.
Если вы используете брандмауэр WordPress или плагин безопасности, временно отключите его.
После этого вам нужно посетить страницу отчета о работоспособности сайта WordPress, чтобы узнать, решена ли ваша проблема.
Если да, то вам нужно проверить журналы брандмауэра WordPress, чтобы узнать, какие запросы API были заблокированы.
Это либо определит источник проблемы, либо вы можете настроить параметры брандмауэра, чтобы не блокировать законные запросы API.
2. Деактивировать все плагины WordPress.
Плагины WordPress создают собственные запросы API для отправки и получения данных. Если эти вызовы слишком часты или занимают слишком много времени для выполнения, это может вызвать ошибку cURL в отчете о работоспособности вашего сайта.
Самый простой способ выяснить это — отключить все плагины WordPress. Просто перейдите на страницу Плагины » Установленные и выберите все плагины.
После этого щелкните раскрывающееся меню «Массовые действия», чтобы выбрать «Деактивировать», а затем нажмите кнопку «Применить».
Теперь вы можете посетить отчет о работоспособности сайта, чтобы узнать, исчезла ли проблема. Если это устранило проблему, вы можете активировать плагины один за другим, пока проблема не появится снова.
Это поможет вам найти плагин, который может вызывать проблему, а затем вы сможете попросить поддержки у автора плагина.
3. Убедитесь, что ваш хостинг-сервер использует новейшее программное обеспечение.
Следующий шаг — убедиться, что ваш хостинг-сервер WordPress использует последние версии PHP, библиотеки cURL и OpenSSL.
Вы можете проверить это, посмотрев на вкладку системной информации на странице Инструменты » Здоровье сайта.
Просто перейдите на вкладку «Информация» и разверните раздел «Сервер». Отсюда вы можете получить информацию о программном обеспечении, установленном на вашем хостинг-сервере WordPress.
В идеале ваш сервер должен использовать PHP 7.4.13 или выше, curl 7.74.0 или выше и OpenSSL 1.1.1 или выше.
Если это не так, вам необходимо связаться с вашей хостинговой компанией WordPress и попросить их обновить программное обеспечение для вашей учетной записи хостинга.
4. Устранение проблем с небезопасным контентом SSL
Если ваш сайт WordPress использует HTTPS/SSL, но не настроен должным образом, это также может привести к тому, что ваш веб-сервер заблокирует небезопасные запросы cURL.
Точно так же, если ваш сайт WordPress не использует HTTPS/SSL, но он сделал вызов API с использованием URL-адреса HTTP, то эти запросы тоже завершатся ошибкой, и вместо этого вы можете увидеть следующую ошибку cURL:
‘Error: cURL error 7: Failed to connect to localhost port 443: Connection refused (http_request_failed)
Чтобы исправить это, вы можете попросить своего хостинг-провайдера переустановить сертификат SSL для вашего сайта.
5. Обратитесь за помощью к поставщику услуг хостинга.
Если описанные выше действия не помогли устранить ошибку cURL 28 на вашем сайте WordPress, проблема, скорее всего, связана с средой хостинга.
Есть много факторов, которые могут контролироваться и исправляться только вашей хостинговой компанией. Например, если их DNS-серверы не могут своевременно разрешать запросы, это приведет к тайм-ауту запросов cURL.
Другой сценарий может заключаться в более медленном подключении или сетевых проблемах с вашим хост-сервером.
Просто отправьте им запрос в службу поддержки с подробными сведениями об ошибке, и их технический персонал сможет устранить неполадки и применить исправление для ее решения.
Мы надеемся, что эта статья помогла вам узнать, как исправить ошибку cURL 28 в WordPress.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Приветствуем вас! Вы видите ошибку cURL 28: Превышено время ожидания соединения на вашем сайте WordPress? Ошибка cURL 28 — распространенная проблема WordPress REST API, которая может повлиять на производительность вашего веб-сайта и привести к его непредсказуемому поведению.
В этой статье мы покажем вам, как легко исправить проблему cURL error 28 на вашем веб-сайте WordPress.
Что такое cURL в WordPress?
CURL — это программная утилита, используемая WordPress и многими другими веб-приложениями для отправки и получения запросов данных с использованием URL-адресов.
WordPress использует cURL для обработки нескольких запросов API. Он доступен как расширение языка программирования PHP, и ваша хостинговая компания WordPress позаботится об этом.
Библиотека cURL играет решающую роль в том, как WordPress работает за кулисами. Если он не настроен должным образом, ваш веб-сайт не будет работать должным образом.
Что вызывает ошибку cURL 28 в WordPress?
Неспособность своевременно ответить на запросы данных сервера вызывает ошибку 28 cURL в WordPress.
WordPress использует REST API (метод программирования) для отправки и получения запросов данных. Если время ожидания этих запросов истекло, вы увидите это как критическую проблему в отчете о работоспособности сайта с заголовком «Ошибка REST API».
Расширение ошибки покажет вам дополнительную информацию, включая сообщение об ошибке:
Error: cURL error 28: Operation timed out after x milliseconds with x bytes received (http_request_failed)
Вы также можете увидеть другую связанную проблему с заголовком «Ваш сайт не может выполнить запрос обратной связи». В нем будет аналогичное сообщение об ошибке со следующим описанием.
«Запрос обратной связи к вашему сайту не удался, это означает, что функции, использующие их, в настоящее время не работают должным образом».
Что может вызвать тайм-аут cURL?
Ряд сценариев может вызвать тайм-аут cURL в WordPress:
- Например, плагин брандмауэра WordPress может блокировать запрос REST API, считая его подозрительным действием.
- Если ваш DNS-сервер работает некорректно, это также может вызвать сбой HTTP-запросов и вызвать ошибку тайм-аута cURL в WordPress.
- Плохо настроенный хостинг-сервер может просто иметь очень низкий порог тайм-аута, что может помешать правильной работе определенных процессов WordPress.
Давайте посмотрим, как устранить и исправить данную проблему.
1. Временно отключите брандмауэр WordPress
Если вы используете брандмауэр WordPress или плагин безопасности, временно отключите его.
После этого вам нужно посетить страницу отчета о работоспособности сайта WordPress, чтобы узнать, решена ли ваша проблема.
Если да, то вам нужно проверить журналы брандмауэра WordPress, чтобы узнать, какие запросы API были заблокированы. Это либо определит источник проблемы, либо вы можете настроить параметры брандмауэра, чтобы не блокировать законные запросы API.
2. Отключите все плагины WordPress
Плагины WordPress создают собственные запросы API для отправки и получения данных. Если эти вызовы слишком часты или для выполнения требуется слишком много времени, это может вызвать ошибку cURL в отчете о работоспособности вашего сайта.
Самый простой способ выяснить это — отключить все плагины WordPress. Просто перейдите на страницу «Плагины»-«Установленные» и выберите все плагины.
После этого щелкните раскрывающееся меню «Массовые действия», чтобы выбрать «Деактивировать», а затем нажмите кнопку «Применить».
Теперь вы можете посетить отчет о работоспособности сайта, чтобы узнать, исчезла ли проблема. Если это устранило проблему, вы можете активировать свои плагины один за другим, пока проблема не появится снова.
Это поможет вам найти плагин, который может вызывать проблему.
3. Убедитесь, что ваш хостинг-сервер использует новейшее программное обеспечение
Следующий шаг — убедиться, что ваш хостинг-сервер WordPress использует последние версии PHP, библиотеки cURL и OpenSSL.
Вы можете проверить это, просмотрев вкладку системной информации на странице «Инструменты»-«Здоровье сайта».
Просто перейдите на вкладку «Информация» и разверните раздел «Сервер». Отсюда вы можете получить информацию о программном обеспечении, установленном на вашем хостинг-сервере WordPress.
В идеале ваш сервер должен использовать PHP 7.4.13 или выше, curl 7.74.0 или выше и OpenSSL 1.1.1 или выше.
Если это не так, вам необходимо связаться с вашей хостинговой компанией и попросить их обновить программное обеспечение для вашей учетной записи хостинга.
4. Устранение проблем с небезопасным контентом SSL
Если ваш сайт использует HTTPS / SSL, но он не настроен должным образом, это также может привести к тому, что ваш веб-сервер заблокирует небезопасные запросы cURL.
Точно так же, если ваш веб-сайт не использует HTTPS / SSL, но он сделал вызов API с использованием URL-адреса HTTP, то эти запросы тоже не будут выполнены, и вместо этого вы можете увидеть следующую ошибку cURL:
Ошибка: ошибка cURL 7: не удалось подключиться к порту localhost 443: в соединении отказано (http_request_failed)
Чтобы исправить это, вы можете попросить своего хостинг-провайдера переустановить сертификат SSL для вашего сайта.
5. Обратитесь за помощью к поставщику услуг хостинга
Если описанные выше действия не помогли устранить ошибку cURL 28 то, проблема, скорее всего, связана с средой хостинга.
Есть много факторов, которые могут контролироваться и исправляться только вашей хостинговой компанией. Например, если их DNS-серверы не могут своевременно разрешать запросы, это приведет к тайм-ауту запросов cURL.
Другой сценарий может заключаться в более медленном подключении или сетевых проблемах с вашим хост-сервером.
Просто отправьте им запрос в службу поддержки с подробными сведениями об ошибке, и их технический персонал сможет устранить неполадки и применить исправление для ее решения. Ну что, у нас на этом все. Всем пока!
С уважением Вячеслав и Валерия!