This is another finding from our work with the new REST environment introduced in Feature Pack 7 for WebSphere Commerce 220.127.116.11. This one was actually the first issue we hit once we moved from development to the server environment, with the updated store model. One particular page that had been working just fine in development now failed to compile when we went across to the server.
This page was not only calling the new REST environment it was also making a REST request from within the JSP to Commerce itself. That is a big difference to be aware of if you really want to move your pages over to the new Commerce REST framework, as you are now creating a headless app so it could be running outside of Commerce. So even when it is a JSP running in Commerce instead of using databeans it will now make REST requests to Commerce, it sounds a bit strange but the request we were using was this
This meant that this request is made from the Commerce JSP out to the IHS webserver because it has the hostname, back into the application server environment (could be the same websphere instance), serviced and a response then sent back around to the JSP. It sounds an interesting path and is why fixes like JR49956 are important for performance.
What was then happening is the page would fail and tell us that there was a bad character at the start of the input, the following comes from the trace we enabled but the character was always a <.
[18/05/14 14:47:10:851 BST] 00000034 JSONEntityPro < com.ibm.commerce.foundation.rest.providers.JSONEntityProvider writeTo RETURN
[18/05/14 14:47:10:854 BST] 00000032 SystemErr R org.apache.commons.json.JSONException: Error occurred during input read.
After a lot of tracing of all kind of aspects, foundation, rest components, of double and triple checking file differences between dev and WAS we just could not see the issue What we kept seeing from the trace was the request outbound was fine, that Commerce received the request for the inventory lookup, it serviced the request and it built and sent back a JSON response. the response looked good, and then it would fail when the response was received. We could make the call to the URL in a browser
and get back a good response. And then we realised the one difference here that because the request had the server hostname it was always going through the IHS server. Unlike the requests which went through the IHS server straight at the SOLR/REST environment on the main IHS servers we had GZIP enabled, and we certainly had no GZIP in the dev environment where the page worked fine.
And guess what there is a fix for GZIP enabled webserver it is JR49995 – ‘This fix is to add support to gzip function of IHS webserver integration with WebSphere Commerce.’. Before applying it we turned GZIP off and suddenly the request worked fine and the page compiled no error. We turned GZIp back on it failed, we applied the fix and it worked.
It should be noted this was the first fix we had applied for the brave new FEP7 world and the update installer is now different as it updates not only your Commerce instance but also the SOLR instance with the fix. No more manual deployment of SOLR updates, it is all done at the same time.
The moral of this is be prepared to think in a different way when it comes to FEP7, the old thinking is out of the window at times when it comes to debugging, it really is a whole new world.