Hi, Am having issues whereby my etherfax pulls the faxes off the etherfax portal but then is unable to show them/load them. Have reached out to etherfax support but they say it is not an etherfax issue per se. Sent over the following pdf showing fax activity.
Here is the error I get when i try to view faxes.
FaxActivityExport (3).pdf (41.9 KB)
Comment from moderator and leader Jerry Padgett:
Help much appreciated!
@Peter_Litchfield
You need to add your credentials received from etherFax. Just tested v7.0.2 with patch 1 okay and check out OpenEMR Fax and/or SMS Module Guide
Jerry, I’ve added and re-added my credentials but still getting same error message.
Wrong credentials then.
Go in their portal, create an API key then follow guide I pointed out using the key.
Jerry, I’ve had the API key for weeks now. Here are my settings. Just now, I did an API reset. This is the new one. Still showing an error.
Y5HCSHghdBP3Qm/fQjr6cmkvO5+TdbrKUNSrpmXlXNs=
I just tested with your api key with success.
From the look of your screenshot the API Key field looks like not enough characters.
Reenter and save or try saving from module setup.
Note:
changed the API key twice. still same error. must be some kind of error in my instance?
fjeqaFtoXuXCXPZE1M3nRIBHSfmDn7AnZz0WbsTVLDg=
Private message me a login for administrator to your site and I’ll look at tomorrow
@Peter_Litchfield
By turning on User Debug in Config->Logging I trapped api response showing PHP error
Looks like running out of memory available to PHP:
Fatal error</b>: Allowed memory size of 536870912 bytes exhausted (tried to allocate 268435488 bytes)
I’ll need to check code to see if I’m batching because look like you have 165 fax events.
You may need to increase your memory_limit in php.ini
Daniel, IT from my team, should have reached out to you but bottom line is that we aren’t sure what the issue is here.
I’ve tested on dev demo Gamma(my up for grab) linux docker server using your etherfax account and is working well.
It appears from your error code you are running out of memory or we have a race condition. Max memory size for a PHP script can be set in php.ini file with memory_size=xxxMB I think default is 256 or 512MB. Look up online web search.
You may have an issue from patch install. Did you run sql_patch.php after patch install?
Read openemr patch wiki or upgrade guide for how to.
I may want to give you a new patch to test later.
Jerry,
If you need us to look at the files coming down from the etherFAX network to your instance, we can at least give you some idea of the file sizes and help trace the events.
Regards,
Rob …
etherFAX
Thanks Robert but I’m sure this is an issue specific to this site and how we handle a large log which is what gets rendered in UI. 165 entries may be what is the cause on render.
This is why works for me everywhere I’ve tested because the 165 faxes have already been downloaded and logged in Peters instance so I’m not seeing that heavy load in my tests using same account.
Right now I’m trying to ssh into his server with no luck.
I’ll get it but not a etherFax issue I’m pretty sure.
Looks like I’m going to have to find a way to render tiff. Most likely will put in a pdf.
I’m not sure what extra cost is charged to have etherFax covert to pdf by default.
For those watching this thread we have been communicating a lot of the debugging in private due to HIPAA and Peters privacy.
Currently in a nut shell Peters team and I have isolated problem to an issue with rendering UI log after 176 log entries. IMO not a memory issue even though it’s the only PHP error.
The environment we’re running in is setup correctly with more than enough memory so it’s on me and my design perhaps.
At any rate I’ll get to the bottom of issue and will return here to update those interest.
For everyone watching I found the issue!
We where indeed running out of memory allocated to script. I found an unused string being populated with json encoded string that was additive to the string size inside the UI table iteration.
Needless to say it goes to show how finicky interrupted languages without strong typing can be and goes to show why testing with large datasets is important.
Thanks @Peter_Litchfield for bringing to our attention and being gracious in helping resolve the issue.
This can be marked resolved.