I am running FreePBX 2.8.0.3 and imported 6,000 records in outbound routes. The import was done with the new CSV import tool from the 2.9 branch. Now every time I view that outbound route firefox freezes and needs to be closed down.
the best is an “svn diff > jsfixes.diff” attached to the ticket you submitted, if you didn’t do the change in an svn pull, you can do “diff -ubB original_file new_file > file.diff” and then attach it to the ticket.
Any explanation you can provide (or comments in the file) are always helpful. We can then have a look at what you did to evaluate it.
Question though, you said it basically paginate’s the patterns. What happens after pulling up the patterns on a page, if you then submit the changes. If it paginates it, does submitting it back end up resulting in only the ones on the current page being entered back in or do you some how pull the full set prior to the submit processing?
thanks for the feedback, we’ll have a look at it in the ticket and see what we can do.
Yes we can view 5,800 records (1 page at a time) and, submit changes in the current page and submit the whole set for saving again. It’s tested, live on our system and it works. Pages load quickly and update. I did not write it though so here are my programmers comments.
“The number of the page being viewed is passed as a parameter to
core_routing_updatepatterns(). Within this function, I pull in the
missing patterns (ie. those which weren’t being viewed/edited), merge
the arrays, then proceed with the DELETE and INSERT. It’s a bit kludgy
but with the patterns not having unique IDs in the database, it was all
I could think of.”
I will attach our fix to the ticket and hope it gets incorporated in FreePbx.
OK We fixed the problem and rewrote the javascript. To contribute our solution do I attach he file to the ticket I opened? Do we also need to submit documentation and an explanation of the changes? (Basically we just paginate the dial plan patterns).
I would like our solution to be integrated in FreePBX so we don’t have to overwrite future changes again.
-
not knowing what a multi-tenant environment is I’ll have to agreee I guess.
-
I also noticed that if you wait long enough and don’t touch anything the browser eventually recovers (5-7 minutes) and you can continue to work.
-
any chance this could be resolved within the 2.8xxx version?
-
we currently have 200 users on a trixbox 2.8 (freePBX 2.5) system that’s running without any issues (except for the standard trixbox issues of no support, no updates, etc…). Anyways we are trying desperately to port everything to a FreePBX system and this is pretty much the last hurdle we encountered so far. Do you expect FreePBX 2.8 to carry the load better or worse than FreePBX 2.5 ?
the dialplan is fundamentally the same, The issue is only in the page load and I don’t know at this time how much work it is going to be to address this situation.
I believe the issue is the ‘onLoad’ js scripts that must run to properly style and prepare all those cells.
So the solution at this point is unknown in the current implementation plus we have to look at it closer to see if that is really where it is failing and then how it might reasonably be handled.
Unfortunately this is a use pattern that is not that common, thus it hasn’t come up before (to my knowledge.
In any case, you should probably file a ticket with the specific information that you have so it stays on the radar.
how do I file a ticket? First time. Sorry.
never mind. I found it.
Actually the CSV import completed ok so it’s not a problem with the CSV import function. We checked with MySQL and all 5,888 records are there. The problem is strictly a GUI page load issue. I hope this helps. If you require me to wipe the records and import via SQL I’ll do it but I don’t think it’ll change anything.
We offer PBX style phone service to our customers. They pay a flat monthly fee and all calls to the USA or Canada are included in that price. To offer that kind of service we have to make sure we always use the lowest cost route for every call so if our customer calls NY city and that route is available from carrier “A” at .003 cents then we want to route with “A” so the outbound routing tables are designed that it checks first if the dial pattern matches “A” and then goes to “B”, “C” etc… Without LCR we would not be able to offer this kind of service.
Thanks,
that helps (e.g. that the numbers are in the DB and you are running into the error).
As far as your usage, if I understand correctly then, you are deploying a PBX to each customer and importing this routing table on each PBX? (or are you putting multiple customers on the same PBX, and doing a form of multi-tenant?)
It’s a simple PBX setup with IP phones in multiple locations connected to the same Asterisk server. Just like a big company PBX except that the phones are not all under the same roof. All customers can call each other and can also call long distance.
Thanks for the usage clarification, so you are effectively setting up a multi-tenant environment it sounds like.
-
On the wholesale side USA providers publish rates as npa/nxx lists and those lists contain upwards of 50,000 records. So if carrier “A” is significantly cheaper than carrier “B” we want to route with “A” whenever possible. Thus rate table “A” contains a highly optimized subset of all dial patterns that cost us less than carrier “B”. We already optimized with wild cards e.g. 20127[46789]xxxx
201280xxxx
etc… -
The browser error says it’s javasvripts.js line 81 that’s causing the problem
-
Why load the entire table in the scroll down box on page load? Why not load only 1,000 records (probably enough for most people anyways) and then load another 1,000 when the user scrolls down?
dcitelecom,
so are you using FreePBX for LCR for wholesale routing? Or are you just doing this on all client systems? Just trying to understand the applications that you are using.
As far as (3), I’d like to hear back from my other question, which was “do you have the same issue if you load the table directly into the SQL database, or just when using the CSV upload option?”
That will better help to understand the circumstances where the problem occurs and thus better attack the problem.
As far as needing that many patterns, I suspect it could be significantly reduced with ‘wild cards’ though I understand that may be an issue to use wildcards.
As far as the use of SQL, it has no effect on the resulting dialplan that is generated which results in a huge outbound routes dialplan section.
So … first question, is it just the CSV upload that is hanging? In other words, if you were to enter the patterns directly into the appropriate SQL table, and then pull up the route, does the page also hang or does it load at that point?
Lastly, are you entry all of these patterns so as to try and avoid some specific routes (such as various high cost NPA Carribean routes and equivalent?). In other words, can you change your routing strategy by listing all the routes that you don’t want (or want to send somewhere else), a much smaller set, and place those in a route that comes first (even if that route points to a bogus trunk or loopback to a recording saying “sorry buddy, can’t call.” Then you could simply use a standard NXXNXXXXXX pattern for the rest? (I realized this does not solve the issue of trying to load 6000 patterns which I’m still interested in per my first question, however, if this results in a significant reduction in patterns it is still a much better solution as it will significantly trim down the size of the generated dialplan.
hmm - well freezing is not good 
however, do you really need 6000 patterns? That’s not going to be great for Asterisk either.
Isn’t it possible to consolidate 6000 patterns in to a much smaller set with other pattern matching abilities?
Lastly and curiously, do other browsers freeze up also? (IE, Safari, Chrome?)
Yes. We need 6,000 patterns. Actually if you do USA npa/nxx least cost routing with 2 carriers you need about 50,000 patterns so this is already heavily consolidated. I thought that moving the dial patterns to SQL would increase Asterisk capacity to handle that many routes.
I have the same 6000 patterns on a trixbox system (based on FreePBX 2.5) and it works ok. My guess is the problem starts with the new dial pattern fields so freepbx 2.7 (text box based) would also accommodate that many patterns.
Freezes in firefox and explorer. I don’t have the other browsers so can’t comment. In IE I get a mssg (after a couple of minutes) that a script on that page is hung and should be terminated or it may cause instability to my computer.