Open kodie opened 6 years ago
We do something similar. I haven't run into this issue yet, but I have thought about the possibility of simultaneous sessions being a problem. Here's two things we currently do that might help you cut down on the number of RETS logins and take some work off both your server and the RETS server.
Caching Locally. Your img.php script could store the photo on the filesystem, and before fetching the photo from RETS, check to see if you already have it. You should include the PhotoTimestamp in the URL as well so that your cache is updated when photos are modified. The workflow might look like this.
You might also need to run a cleanup process to remove old files. Possibly by running a scheduled task that removes photos of inactive listings.
Using a Content Delivery Network. We use AWS CloudFront, but there are lots of great services out there. Here's how that works.
https://yoursite.cloudfront.com/img.php?resource=Property&type=Photo&id=123456&index=1&Timestamp=1510801270
These two methods could be used exclusively or together. I know this doesn't answer your question specifically, but hopefully it might be helpful.
@kodie Did you find any solution?
@php5-webmob As @bradroberts suggested, we are caching the results locally. So basically our app is getting images in a two-step process. First, make a RETS call to download all the images we need and save them in local cache, then whenever we need to server an image we just load them from that cache. It's been working pretty good for us so far, however we still run into "Too Many Login" errors from time to time.
Yesterday, I reached a hard limit that resulted in an outage and a day's worth of lost work.
I have encountered a problem where it is not possible to store the $rets connection in a session cookie due to it being a Closure with runtime information. To overcome this, a custom-built session handler needs to be implemented. From examining the source code, it appears that the existing "session/cookies" are only for multiple requests made using the offset and limit strategy. I had previously assumed that the "session/cookies" feature of PHPRETS included the ability to cache sessions, thereby preventing me from reaching the hard limit on logins per day with my RETS feed provider for several years.
This is a fundamentally flawed system and am thinking a whole new RETS library is needed. Something that can be coded to persist a session to avoid hard login limits per day.
I have built a script that allows me to dynamically display images from a RETS server. So basically something like this:
http://mywebsite.com/img.php?resource=Property&type=Photo&id=123456&index=1
and then I can do stuff like this:
<img src="http://mywebsite.com/img.php?resource=Property&type=Photo&id=123456&index=1">
and it works beautifully. However, if I have like 10 images on a page, some of the images will randomly not show. I'm assuming this is due to logging into the server as the same user 10 separate times at the same time.
Is there a way I can get session details to store and reuse?