Universal Tracker

Sitecore in on a journey from monolith to NET Core based Service Architecture by leaving the safety of the monolith but because of tight coupling we have to live with large instances, slow start up and all or nothing upgrades. This old approach is hard to scale, bug in one feature can affect the whole platform. It always slowed down the adoption of new technologies.  Now, Sitecore is going into direction where they creating  a new building blocks on the same Sitecore Host (hOS+). One of them is Universal Tracker. But what is it ?

Universal Tracker is a headless API for xDB collection. You asking your self isn’t that xConnect? It is not. xConnect only accepts immutable history and it designed for trusted service communication – Authentication only, no authorization. Universal Tracker is needed to not expose xConnect. I has been told that in the future, Sitecore will use Universal Tracker instead of Sitecore.Analytics.Tracker. The Universal Tracker will allow collection of interaction data from all channels, wherever they may be, including Sitecore websites (web tracker), other websites (JS tracker) and even mobile applications (mobile tracker).

Where xConnect is concerned with collecting completed interactions, the universal tracker is concerned with collecting live interactions as they happen, and submit them to xConnect when they’re done.

Continue reading

Solr 6.6.2 exceptions while rebuilding large indexes

sitecore Caused by: org.apache.lucene.store.AlreadyClosedException: this IndexWriter is closed

sitecore o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: Exception writing document id

 

For last few weeks I was getting this exception while I was working on my local machine using a copy of production master and web databases. It never happened before, never with our dev databases synchronized by Unicorn.   Rebuild started normally, and then half an hour later I was getting an exception pointing into a random item saying that Sitecore is not able to write document ID.  Data corruption? But why is working on staging? No, the Java heap is running out of space.

By default heap size is  512 MBSolrDashboard

 

You can change it by uncommenting set  SOLR_JAVA_MEM  in solr.in.cmd file

SolrConfig

SolrDashboardAfter