Our asterisk have been taking toll since number of subscriptions are too many.
is there is way to limit "watchers"
I have looked on internet but nothing specifically touches this topic of limiting number of subscriptions.
E.g.
Only max of 3 phones can subscribe to BLF/monitor to phone 001
Below is part output from our console.
asterisk -rx 'core show hints'
641#25550094-Default : SIP/6172 State:Idle Watchers 7
643#25550094-Default : SIP/6172 State:Idle Watchers 7
279#25790053-Default : SIP/6128 State:Idle Watchers 5
777#81560062-DEFAULT : SIP/6188 State:Unavailable Watchers 1
799#81560105-DEFAULT : SIP/6188 State:Unavailable Watchers 0
387#81560085-DEFAULT : SIP/6187 State:Idle Watchers 8
683#81560037-DEFAULT : SIP/6188 State:Unavailable Watchers 0
544#81560083-DEFAULT : SIP/6188 State:Unavailable Watchers 0
001#25550042-Default : SIP/6129 State:Idle Watchers 13
002#25550042-Default : SIP/6129 State:Idle Watchers 13
No, there are no way.
You should think about moving to kamailio/opensips and clustering.
Related
I'm trying get ionic up and running using my mac by following the simple instructions on the website (http://ionicframework.com/getting-started/)
Everything is working until i need to emulate
$ ionic emulate ios
I did a little deeper and I realized the same error lies in when I tried to run ios-sim
Here is what I see
$ ios-sim start
2015-02-27 14:01:57.361 ios-sim[1810:208272] [MT] DVTAssertions: ASSERTION FAILURE in /SourceCache/DVTiOSFrameworks/DVTiOSFrameworks-6274/DVTiPhoneSimulatorRemoteClient/DTiPhoneSimulatorSessionConfig.m:143
Details: (runtime) should not be nil.
Object: <DTiPhoneSimulatorSystemRoot>
Method: +rootWithSimRuntime:
Thread: <NSThread: 0x7ff44a5105f0>{number = 1, name = main}
Hints: None
Backtrace:
0 0x0000000110abe24a -[DVTAssertionHandler handleFailureInMethod:object:fileName:lineNumber:assertionSignature:messageFormat:arguments:] (in DVTFoundation)
1 0x0000000110abdc9f _DVTAssertionHandler (in DVTFoundation)
2 0x0000000110abdf8e _DVTAssertionFailureHandler (in DVTFoundation)
3 0x0000000111062614 +[DTiPhoneSimulatorSystemRoot rootWithSimRuntime:] (in DVTiPhoneSimulatorRemoteClient)
4 0x0000000111061897 -[DTiPhoneSimulatorSessionConfig simulatedSystemRoot] (in DVTiPhoneSimulatorRemoteClient)
5 0x000000010ebadab0 -[iPhoneSimulator launchApp:withFamily:uuid:environment:stdoutPath:stderrPath:timeout:args:] (in ios-sim)
6 0x000000010ebaecfd -[iPhoneSimulator runWithArgc:argv:] (in ios-sim)
7 0x000000010ebaefbb main (in ios-sim)
8 0x000000010ebac37c start (in ios-sim)
9 0x0000000000000002
Abort trap: 6
Please advice
I have a MPI program that create a file which have time per iteration of certain amount of calculations. When I run this code without submitting to the queue(this cluster runs SGE), it gives following time in seconds. I grabbed 8 processors using mpirun -np8.
STEP ITIME
-------------
1 0.868128
2 0.426714
3 0.409768
4 0.427312
5 0.412737
6 0.413256
7 0.414480
8 0.414984
9 0.415683
10 0.416826
But when I submit the same amount of work for 8 processors and submit it to the queue, the program take more time for calculation of the iterations. The time per step is almost four times.
STEP ITIME
-------------
1 3.189155
2 1.594365
3 1.600892
4 1.589424
5 1.605402
6 1.589136
7 1.599425
8 1.591966
9 1.601557
10 1.603447
The following bash script was used to submit the job.
#!/bin/sh
#$ -S /bin/bash
#$ -pe orte 8
export PATH=~:$PATH
/opt/openmpi/bin/mpirun -np 8 ./exec
I will appreciate if someone can point me out what might cause this issue?
In your first case (run this code without submitting to the queue), you are probably running 8 processes on the same node. That's usually fine nowadays: you've likely got 8 cores.
Try this out:
$ /opt/openmpi/bin/mpirun -np 8 uname -a
did you get 8 identical lines?
In the SGE case, you might get 8 physical machines, so now there is network communication involved. Confirm as above. I don't know SGE, but your environment no doubt has a "how to assign mpi processes" switch to indicate if you want it to assigndepth first or breadth first.
When i use command format the output is:
AVAILABLE DISK SELECTIONS:
0. c0d0 <DEFAULT cyl 1302 alt 2 hd 255 sec 63>
/pci#0,0/pci-ide#7,1/ide#0/cmdk#0,0
1. c2t0d0 <DEFAULT cyl 1020 alt 2 hd 64 sec 32>
/pci#0,0/pci15ad,1976#10/sd#0,0
But after searching in /dev/dsk $ /dev/rdsk using ls i found:
bash-3.00# ls
c0d0p0 c0d0s11 c0d0s5 c1t0d0p3 c1t0d0s14 c1t0d0s8 c2t0d0s1 c2t0d0s3
c0d0p1 c0d0s12 c0d0s6 c1t0d0p4 c1t0d0s15 c1t0d0s9 c2t0d0s10 c2t0d0s4
c0d0p2 c0d0s13 c0d0s7 c1t0d0s0 c1t0d0s2 c2t0d0p0 c2t0d0s11 c2t0d0s5
c0d0p3 c0d0s14 c0d0s8 c1t0d0s1 c1t0d0s3 c2t0d0p1 c2t0d0s12 c2t0d0s6
c0d0p4 c0d0s15 c0d0s9 c1t0d0s10 c1t0d0s4 c2t0d0p2 c2t0d0s13 c2t0d0s7
c0d0s0 c0d0s2 c1t0d0p0 c1t0d0s11 c1t0d0s5 c2t0d0p3 c2t0d0s14 c2t0d0s8
c0d0s1 c0d0s3 c1t0d0p1 c1t0d0s12 c1t0d0s6 c2t0d0p4 c2t0d0s15 c2t0d0s9
c0d0s10 c0d0s4 c1t0d0p2 c1t0d0s13 c1t0d0s7 c2t0d0s0 c2t0d0s2
Question 1
I know that c0d0p0 is fdisk partitions because i'm on x86 system not spark but still i don't understand why it appeared even though i never used fdisk?
Question 2
As you saw at format output i only have c0d0 [IDE] and c2t0d0 [SCSI] but i don't have c1t0d0s0 ?!! i even used devfsadm -C and still it exists.
i used format /dev/rdsk/c1t0d0s0 and told me No disk found!
I dont understand what is this exactly and using ls -l is sure points on a device file at /device
bash-3.00# ls -l c1t0d0s0
lrwxrwxrwx 1 root root 52 Nov 29 2012 c1t0d0s0 -> ../../devices/pci#0,0/pci-ide#7,1/ide#1/sd#0,0:a,raw
so can you please tell me what is that exactly and how can i remove it?
1: No need to use fdisk to get c0d0p0, the OS provision every possible entry (partition/slice) regardless of whether they actually exist or not.
2: This device is likely not handled by format, might a CD/DVD drive or a remote device (USB key, drive, ...)
I want to configure my Cyborg R.A.T 9 mouse to work with my installation of elementaryOS (luna, 64 Bit).
I used this solution for the last two years, but it doesn't work anymore (I guess it's outdated). Newer post I found included creating a file 910-rat.conf in /etc/X11/xorg.conf.d/, but this folder doesn't exist in my installation. As I don't want to destroy it, I thought it might be better to ask if simply creating that directory and file would work.
TL;DR:
OS: elementaryOS luna (0.2 beta) 64 bit
Mouse: Cyborg R.A.T 9
Xorg X server version: 1.11.3
Question:
Is it ok to create the directory /etc/X11/xorg.conf.d/ and will the conf files in there be used or am I missing any steps?
I found an article in the german ubuntuusers wiki saying that the directory is located in /usr/share/X11/ and not in /etc/X11/ .
So I just added the file in /usr/share/X11/xorg.conf.d/ and it worked.
For further reference:
I added the file 910-rat.conf to the folder /usr/X11/xorg.conf.d/.
The file contained the following content:
Section "InputClass"
Identifier "Cyborg R.A.T. 9"
MatchProduct "R.A.T.7|R.A.T.9"
MatchDevicePath "/dev/input/event*"
Option "Buttons" "17"
Option "ButtonMapping" "1 2 3 4 5 0 0 8 9 7 6 12 0 0 0 16 17"
Option "AutoReleaseButtons" "13 14 15"
Option "ZAxisMapping" "4 5 6 7"
EndSection
in Qt Creator (qt 4.8, winxp) I wrote
QuaZip* zipfile = new QuaZip;
zipfile->setZipName("myzipfile.zip");
zipfile->open(QuaZip::mdUnzip);
if(zipfile->isOpen()){
QStringList files = zipfile->getFileNameList();
} // here the error occurs
when files is destroyed, a messagebox says
Debug Assertion Failed!
Expression: _CrtIsValidHeapPointer(pUserData)
In the debugger I have the following function stack:
0 DbgBreakPoint ntdll 0x7c90120e
1 RtlpBreakPointHeap ntdll 0x7c96c201
2 RtlpValidateHeapEntry ntdll 0x7c96c63e
3 RtlValidateHeap ntdll 0x7c9603b0
4 HeapValidate kernel32 0x7c85f8d7
5 _CrtIsValidHeapPointer dbgheap.c 2103 0x102d1ac9
6 _free_dbg_nolock dbgheap.c 1317 0x102d0b3a
7 _free_dbg dbgheap.c 1258 0x102d09e0
8 free dbgfree.c 49 0x102d8990
9 qFree qmalloc.cpp 60 0x5e2f1d
10 QString::free qstring.cpp 1235 0x65dd22
11 QString::~QString qstring.h 880 0x5ac0d3
12 QString::`scalar deleting destructor' QuizSet 0x4120e0
13 QList<QString>::node_destruct qlist.h 433 0x412180
14 QList<QString>::free qlist.h 759 0x4115fb
15 QList<QString>::~QList<QString> qlist.h 733 0x410967
16 QStringList::~QStringList MyApp 0x414d9f
17 MyApp::myFunction myapp.cpp 561 0x420e1c
...
line 433 in qlist.h is where the debugger stops:
while (from != to) --to, reinterpret_cast<T*>(to)->~T();
the error occurs only if I call ::getFileNameList(), if I fill the list manual it works fine.
Other operations with quazip work, I can unzip and zip data, only the getFileNameList makes trouble.
EDIT: I found the cause: the quazip1.dll I used was the release version of it, only in debug-running this problem arised. So if I use the debug quazip.dll, it works fine. Annoying they're called the same, so I have to rename everytime I switch from debug to release. Anybody knows a workaround to this?
This means that you are mixing release mode Qt DLLs with Debug ones. You have to create 2 sets of Quazip DLLs one for Release mode and one for Debug mode. You cannot mix Qt Debug DLLs with Release DLLs.