I'm debugging a really strange issue with a Deployer extension which indexes content into Solr using SolrJ. This is not with SI4T or SS4T but a custom deployer.
Occasionally when a bulk publish is performed one of the Solr fields - date
, will get an incorrect value:
<date name="date">20142013-12-01T09:00:00Z</date>
This field is defined in Solr as a TrieDateField.
Here's what I think is happening. In the deployer extension, the DATE_FORMAT is stored as a static final
variable of type SimpleDateFormat:
private static final SimpleDateFormat DATE_FORMAT = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss");
I don't believe SimpleDateFormat is thread safe and I think when a mass publish occurs the Deployer (10 workers as default) is picking up multiple packages at once and somehow when the field is added to Solr, it's getting someone else's value, there's also some code to add the year
into a different field:
public void setDate(Date date)
{
if (date != null)
{
addField("date", date);
Calendar cal = Calendar.getInstance();
cal.setTime(date);
addField("year", Integer.toString(cal.get(Calendar.YEAR)));
}
}
So my theory is that somehow year field value is ending up in the date field as well as the date. However, I've been unable to reproduce this issue anywhere but Production thus far.
Production has a scaled out publisher so might be faster at getting packages onto the CD box for the Deployer to get more thready with. I'd expect to see this on any environment with enough publishing though.
Anyone got a better theory? Currently had to ban bulk publishing and I'm not sure that will fix it either if multiple people are publishing.