Open Source Training Seminar FreePBX Paid Support

Ticket #2832 (closed Bugs: worksforme)

Opened 3 months ago

Last modified 3 weeks ago

Graphic not working on large calls number

Reported by: lanzaandrea Assigned to:
Priority: minor Milestone: 2.5
Component: Reports Version: 2.4.0
Keywords: Cc:
Confirmation: Unreviewed SVN Revision (if applicable):
Backend Engine: All Backend Engine Version:

Description

This bug was also present in earlier version, as the http://www.freepbx.org/trac/ticket/2792 was. Anyway this is worst. If you try to get the second graph in the reports-->DaylyLoad?, you succed in it only if the calls are not too much. I can't explain better, but looking on a server medium-loaded (abount 6 hundred calls per hour) you get the graph only on the hours containing less calls. If I try to get the graph beetween 9 and 10, I get a red cross image. If I filter the calls in that hour using only the zap channels calls, I get the graph, idicating a maximum load of about 10 calls. So it is not a missing php problem, but perhaps a bad dimensioned variable (maybe?) No errors are detected into apache log, nor in the messages log. I am using opensuse 10.2, kernel 2.6.18.8-0.5-default #1 SMP , php5.

Where can I check and what can I do to help you to solve this issue ?

Change History

05/30/08 11:20:11 changed by p_lindheimer

  • milestone changed from Cut Line to 3.0.

lanzaandrea, it's a priority thing of someone taking the time to find the bug and fix it, and the reporting code is a part of the code base that is not as well known by the developers active on the project. (It was originally imported from another project). Also - it sounds like it may take a very large CDR table to reproduce it from what I understand in your description. Do you have any coders who could look at it? As a side note, I would consider 600 calls per hour heavily loaded for a FreePBX system. Is this a call center or just a large number of phones?

06/03/08 01:16:51 changed by lanzaandrea

I am a coder, unfortunately php is not familiar to me... Anyway I will try to have a look at the source. On the other side, 600 call at peak time having a quad pri and about 400 internal users is not a very high volume. In the past (more than 2 years ago) we did trunking h323/pri , and we had about 25,000 minutes per day of calls, and we had no problems in wartching the graphs. Anyway that was an amportal version 1.0.8, if I correctly remember. Maybe it could be an issue due to using php5 instead of php4

I will dig the php code... or at least I will try !

06/03/08 02:37:23 changed by lanzaandrea

I found the "problem" is only an i.e.7 issue. Using mozilla firefox you have no problem Actually I don't know what bad thing i.e. finds in that image... Maybe the tools used to create the image adds something bad for i.e. on greater images... So, according to me, this issue can be considered closed. Thanks, Andrea

06/03/08 04:45:44 changed by lanzaandrea

Meanwhile: I solved the error regarding ticket 2792

http://www.freepbx.org/trac/ticket/2792

3 errors were present there.

I will post there the solution

06/15/08 02:14:52 changed by lazytt

  • status changed from new to closed.
  • resolution set to duplicate.

is the solution the same as #2792?

06/16/08 00:17:21 changed by lanzaandrea

no, I didn't fid any solutiono for this ticket. I only pointed out that using mozilla firefox is all ok Using MS. I.E. with a large number of calls it does not work It is not a duplicate of 2792: 2792 is a different thing. I spoke about 2792 because it is another ticket opened by me, which was ununswered and regarding graph too. 2792 is solved according to me, but the solution needs further testing (correctly) according to p_lindheimer

06/16/08 08:09:10 changed by p_lindheimer

  • status changed from closed to reopened.
  • resolution deleted.

re-opening bug since reporter indicates it is not a duplicate of #2792. (And lanzaandrea, I haven't seen anyone give feedback on #2792 so it is current stalled...

08/02/08 19:32:46 changed by p_lindheimer

  • status changed from reopened to closed.
  • resolution set to worksforme.

rereading this ticket, it sounds like the issue is closed. If there is an error with IE7 that can't display something, then a new ticket should be opened. That new ticket should include a source capture of the exact page that is having problems displaying in IE and properly displays in FF. That will allow someone to reproduce the issue.

Donate



Support
Download
Develop
Forums
News
Documentation
Paid Support
About

Paid Ads