Deleted photos showing on iPhone 11 Pro

My wife requested me to delete photos from here iPhone 11 Pro. So, I did what was requested. 

I tapped the Photos App -> photos -> Year. Then, I went and deleted photos for each month/day by tapping on select all then tapping on the trash been. I did this for each day from 2017 until end of 2018. After a painstaking hour or so, I was able to delete everything she wanted, even clearing the Recently Deleted folder. So, I gave back her phone.

But she handed it back to me saying that the photos are still there. So, I checked by tapping the Photos App -> photos -> All Photos. And indeed, the photos are still there. Something might be wrong! Is it a bug? So, I went and chat with a support representative.

After giving all the requested information, she said that I also need to delete the photos in the "All Photos" album. I asked her why. She said "because it is a different album". Wow! I just can't believe what she said. She continued by saying it was by design. 

So, the reason why your new iPhone storage isn't freeing up even after deleting so many pictures, and clearing the Recently Deleted album is because your photos are being duplicated so they can show up in different albums. What a waste of storage space!!! I cannot believe that this is how they designed this thing. IT IS REALLY A WASTE OF STORAGE SPACE!!! I think my respect for the Apple Engineers went down.

Oh, well, the only way to free-up space is go into the different albums and start deleting photos.

ORA-29861 "domain index is marked LOADING"

Dropping an Oracle text index generates the error:

ORA-29861 "domain index is marked LOADING"

Forcing to drop the text with alter index <index_name> force; generates the end-of-file communication error.

SOLR data/index Directory Growing

We are using SOLR 3.3, and everyday the data directory on most of the slaves is growing. Investigation showed that there were several index directories with the name format as index.YYYYMMDDHHMISS (I may be missing something but it's in that format); newest is today, and the oldest is 3 months ago.

Usually, SOLR segments are in a directory named index but ours doesn't show any. All of them was named index.YYYY*. So, I checked the index.properties file to determine which index directory SOLR is using, then deleted the others.

However, this didn't solve the issue. Our data directory is still huge. Further investigation showed that there are old segments in the data/index directory. I restarted the slaves but it didn't help.

After comparing files, etc., I noticed that the difference between the slaves that has the correct size and those that don't, is the timestamp of the write.lock file. I deleted the write.lock file and forced a DIH process. After the slaves replicated, the old segments are gone. Just a note, there should be at least one document updated on the master for this to work. 

HTH.  

"HttpSolrServer$RemoteSolrException: We are not the leader" Solr Cloud

I created a SolrCloud (4.10) environment using a 3-host Zookeeper environment with a 3-host SOLR cluster. I simulated a crash by deleting one of replica that was running on the leader node for one of the collections (let's call it M01). Because of this, a new leader was elected (let's call it M02) for the collection. Now, the landscape has 2 leaders: M02 for 1 collection, and M01 for the other collections.

I added the replica back. Waited for it to recover but unfortunately, it didn't and there were error messages in the log file:

Error while trying to recover. core=coreName:java.util.concurrent.ExecutionException: org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: We are not the leader
 at java.util.concurrent.FutureTask.report(FutureTask.java:122)
 at java.util.concurrent.FutureTask.get(FutureTask.java:188)
 at org.apache.solr.cloud.RecoveryStrategy.sendPrepRecoveryCmd(RecoveryStrategy.java:615)
 at org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:371)
 at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:235)
Caused by: org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: We are not the leader
 at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:550)
 at org.apache.solr.client.solrj.impl.HttpSolrServer$1.call(HttpSolrServer.java:245)
 at org.apache.solr.client.solrj.impl.HttpSolrServer$1.call(HttpSolrServer.java:241)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:745)

I tried to delete and add the said replica but got the same error.

The solution is to restart the SOLR instance that was on the leader node of the collection where the replica was deleted. This will reset the leader for that collection and eventually have M01 recover.

Hope this helps

Vonage 3000 to Globe Philippines

Last March, 2013, I wrote a blog about Vonage's Unlimited Plan to Globe Philippines. Maybe because of complaints about their plan, they discontinued the unlimited plan and renamed it to Vonage 3000 to Globe Philippines.

Now, what's wrong with this? Nothing. Now people that's interested would know that you are only allowed 3000 minutes per month. Any subsequent usage after 3000 minutes will be additional.

People will say that Vonage is not clear. Well, I would say I haven't encountered this problem yet. Everytime we call the Philippines, we can clearly hear them.

Now, I am okay with the Vonage 3000 to Globe Philippines. At least, I am not expecting to have my subscription unlimited.