ldap_unbind_ext is blocked until the previously initaited ldap search is completed.
I initiate search and unfortunately server takes 3+ minutes to respond.Meanwhile if I attempt to register to another server, the old connection should be tore down and a new connection should be established by my application.
But,as there is an active query on the old connection,ldap_unbind_ext gets blocked until search is completed.
I tried using ldap_abandon_ext before we call ldap_unbind_ext ,but now it blocks in ldap_abandon_ext .
Could someone help me on this.
Thanks in advance!
Using ldap_pvt_tls_destroy shall destroy the connection though there is an active query on the connection.
We need this when we tear down a connection, to allow the global TLS settings to change.
This function is called in ldapsearch, in its tool_destroy() routine, and also in slapd.
Related
I have a Python service which connects to Asterisk via AMI and listens for events to detect when a call has begun.
This seems to work on most of the Asterisk servers I connect to. However, on a few of our servers we just don't see any of the AMI events (e.g. Newstate) when the call happens, though we do later see the Cdr event once the call has completed.
I've confirmed that this isn't specific to the library we're using to connect to AMI (py-Asterisk), because I see exactly the same thing when I connect manually, e.g.
$ openssl s_client -connect my-asterisk-server:5039
...
Asterisk Call Manager/2.10.3
Action: Login
Username: manager
Secret: ThisIsWhereITypedTheActualPassword
Response: Success
Message: Authentication accepted
Event: FullyBooted
Privilege: system,all
Status: Fully Booted
Action: Events
EventMask: on
Response: Success
Events: on
In the above block, I manually connected to AMI, logged in as the same administrator my Python code is using, and ensured that all events are turned on (though my asterisk config should already be displaying all events I care about by default).
After this point what I see on some of my Asterisk servers is a series of expected events like Newstate, followed by an eventual Cdr event. On other servers, I see only the Cdr event, with nothing proceeding it. This is completely consistened within each server, meaning a server either always sends all of the expected events or it never does.
I've checked the versions of asterisk, the manager.conf config file, the extensions.conf dialplan, the asterisk console in verbose mode (i.e. connecting via asterisk -vvvr to the running process), and just generally comparing my config files to my actually-working Asterisk servers.
I'm stumped as to what could be causing this, or even what to try next. If it matters, here's what my manager.conf looks like:
[general]
tlsenable=yes
tlsbindaddr=10.0.0.123:5039
tlscertfile=/etc/pki/asterisk/ami.crt
tlsprivatekey=/etc/pki/asterisk/ami.key
[admin]
secret=TheActualPasswordIsOnThisLine
read=system,call,log,verbose,command,agent,user,originate,cdr
write=system,call,log,verbose,command,agent,user,originate,cdr
EDIT: After some further digging, it seems that the only events which are showing up are Cdr events, so even things like peer registration events don't show up. I've also confirmed that all of my Asterisk 13.19.0-1 servers are exhibiting this behavior, and the only working servers are running much older versions of Asterisk.
The weird thing is that calls do come through successfully, so the problem is not that I'm missing some necessary module. (Or maybe I am? Is there some "make events show up in AMI" module that I need to ensure is loaded?)
FURTHER EDIT: I was able to turn on CEL events (Channel Event Logging), and those events show up, but this is a different set of events than the standard Newchannel/Newstate/etc I'm looking for. In theory I could rewrite a large portion of my service to use the CEL events, but ideally I'd just turn on the standard Newstate/Newchannel/Hangup events.
It turns out the issue is that I was missing
enabled=yes
in my manager.conf. Hopefully this will be helpful to someone in the future: even if you're able to connect to AMI, log into AMI, receive some events from AMI, and send commands to AMI and get responses back, it might not be enabled, and this will suppress most of the core events like Newchannel, Newstate, etc.
One clue was that running manager show settings in the asterisk console returned this:
Global Settings:
----------------
Manager (AMI) No
...
which is apparently how it indicates that it's not enabled.
I have a single web client and a few Lambda functions which use the Admin SDK. I've noticed recently that I've bumped into the 100 simultaneous connection limit but I really shouldn't be anywhere near that limit. Also it would appear that the connections established by my Lamba functions are not dropping off even after the function has completed.
Any idea on:
how I can prevent this run-up on connections from happening?
how I can release connections established by past Lambda scripts?
how can I monitor which processes/threads/stacks are holding connections?
Note: this is a testing environment I'm working out of so I'd prefer to keep this in the free tier and my requirements should definitely not be running into the 100 active limit. I am on a paid plan in prod.
I attempt to avoid calling initializeApp more than once by using the following connection code. In the example I'm talking about I only have a single database as a backend and so the default "name" of DEFAULT is used each time.
const runningApps = new Set(firebase.apps.map(i => i.name));
this.app = runningApps.has(name)
? firebase.app()
: firebase.initializeApp({
credential: firebase.credential.cert(serviceAccount),
databaseURL: config.databaseUrl
});
I'm now trying to explicitly close connections with goOffline but that leads to another issue where on the second connection -- aka, where the DEFAULT application is already setup and it just reuses the connection already established I get the following logging:
# Generated as result of `goOnline`
Connecting to Firebase: [https://xyz.firebaseio.com]
appears to be already connected
# Listening on ".info/connected" comes back as true, resulting in:
AbstractedAdmin: connected to [DEFAULT]
# but then I get this error
NotAllowed: You must first connect before using the database() API at Object._getFirebaseType
The fact that you have unexpected incoming connections to the database, makes it seem like the stale instances keep an open connection.
Best I can think off is to call goOffline() in your function before it completes to explicitly disconnect. That would probably also mean you have to call goOnline at the start of the function, since it might be running on an instance that previously went offline. Both goOnline and goOffline are synchronous calls afaik, but there's definitely going to be some time between going online and the data becoming available in your app.
If Lambda has a way for you to detect life-cycle events of its instances, that would be the preferred place to call goOffline and goOnline.
admin.initializeApp should only get called once in your script/node app.
The Firebase SDK's talks HTTP2 to the Firebase cloud system, so I'm not sure why you would encounter max connection issues as unique sockets are not stood up per call.
One thing to look out for is that calls to 3rd part API's (such as sendgrid) are not supported on the free tier.
I created a Symfony 3 command that is expected to run for days (or even weeks). It uses Doctrine 2 for reading some initial data and for writing the execution status from time to time. The SQLs are expected to take few milliseconds.
My concern is that the whole process will eventually crash if the MySQL connection closes due to inactivity.
Question: is Doctrine keeping the database connection open between flush calls? Or, is it reconnecting every time flush is called?
AFAIK Symfony will open up a connection to the database the first time Doctrine is used in your app and close it when the HTTP request is sent (or if you specifically tell Doctrine to close it). Once connected, Doctrine will have the connection active until you explicitly close it (and will be active before, during and after flush())
In your case you should probably open and close the db connection explicitly when you need it. Something like the following code could solve your problem:
// When you need the DB
/**
* #var \Doctrine\DBAL\Connection $connection
*/
$connection = $this->get('doctrine')->getConnection();
// check if the connection is still active and if not connect to the db
if(!$connection->isConnected()) {
$connection->connect();
}
// Your code to update the database goes after this.
your code
// Once you're done with the db update - close the connection.
if($connection->isConnected()) {
$connection->close(); // close the db connection;
}
This will avoid db connection timeouts and etc, however you should be quite careful with memory leaks if this script will be running as long as you're saying. Using Symfony might not be the best approach to this problem.
You can simply ping the connection every 1000 seconds, less than MySQL's connection limit.
Best thing to do would be to run a supervising process (eg. supervisord), which would restart the process as soon as your app stops. Then you can simply tell your script to exit before the connection is dropped (as it's a configured value, in MySQL for instance it's the wait_timeout variable). Supervising process will notice your app is dead and will restart it.
After moving most of our BT-Applications from BizTalk 2009 to BizTalk 2010 environment, we began the work to remove old applications and unused host. In this process we ended up with a zombie host instance.
This has resulted in that the bts_CleanupDeadProcesses startet to fail with error “Executed as user: RH\sqladmin. Could not find stored procedure 'dbo.int_ProcessCleanup_ProcessLabusHost'. [SQLSTATE 42000] (Error 2812). The step failed.”
After looking at the CleanupDeatProcess process, I found the zombie host instance found in the BTMsgBox.ProcessHeartBeats table, with dtNextHeartbeatTime set to the time when the host was removed.
(I'm assuming that the Host Instance Processes don't exist in your services any longer, and that the SQL Agent job fails)
From looking at the source of the [dbo].[bts_CleanupDeadProcesses] job, it loops through the dbo.ProcessHeartbeats table with a cursor (btsProcessCurse, lol) looking for 'dead' hearbeats.
Each process instance has its own cleanup sproc int_ProcessCleanup_[HostName] and a sproc for the heartbeat watchdog to call, viz bts_ProcessHeartbeat_[HostName] (although FWR the SPROC calls it #ApplicationName), filtered by WHERE (s.dtNextHeartbeatTime < #dtCurrentTime).
It is thus tempting to just delete the record for your deleted / zombie host (or, if you aren't that brave, to simply update the Next dtNextHeartbeatTime on the heartbeat record for your dead host instance to sometime next century). Either way, the SQL agent job should skip the dead instances.
An alternative could be to try and re-create the Host and Instances with the same name through the Admin Console, just to delete them (properly) again. This might however cause additional problems as BizTalk won't be able to create the 2 SPROCs above because of the undeleted objects.
However, I wouldn't obviously do this on your prod environment until you've confirmed this works with a trial run first.
It looks like someone else got stuck with a similar situation here
And there is also a good dive into the details of how the heartbeat mechanism works by XiaoDong Zhu here
Have you tried BTSTerminator? That works for one-off cleanups.
http://www.microsoft.com/en-us/download/details.aspx?id=2846
Can anyone explain how I can remove service instances ?
- I've got a few which the BizTalk console shows as "Running"
- they are all in the Isolated Adapter
- tried doing a Stop with Full Stop option ...
- tried the Terminate Instance option ...
- even tried deleting the BizTalk application
But they're still there ??
my bad, the application delete did remove them, must have forgot to refresh
Event log has the errors ...
A request-response for the "HTTP" adapter at receive location "/foanite/BTSHTTPReceive.dll" has timed out before a response could be delivered.
but I still don't understand why the terminate wouldn't work
If you are running an Receive Location in an isolated host you normally need to perform a iisreset to be able to delete them.
If the IISReset does't help (it often doesn't) then use the BizTalk Health Monitor.
Select "Maintenance" from left-and tree view
For Task Type, select "Delete" and "Terminate Single Instance (Hard Termination)"
Paste the instance id taken from the BizTalk admin console
Click "Execute Task"