When a user attempts to shut down WebSphere Cluster on which LiveCycle is deployed, the WebSphere server hangs occasionally and the following error message appears in the log:
000002f5 SystemOut O cache has closed down , no further access allowed !, exception caught in inserting data in cache : CLUSTER_INVALIDATION_CACHE key: GLOBAL_PREFERENCES_UPDATE_TIMESTAMP_KEY value : null exception :com.adobe.livecycle.cache.CacheActionException: Cache container closed; normal during shutdown, error during runtime – Error on GET action for cache Replicated:CLUSTER_INVALIDATION_CACHE
000002f5 SystemOut O exception caught in inserting data in cache : CLUSTER_INVALIDATION_CACHE key: GLOBAL_PREFERENCES_UPDATE_TIMESTAMP_KEY value : null exception :com.adobe.livecycle.cache.CacheActionException: Cache container closed; normal during shutdown, error during runtime – Error on GET action for cache Replicated:CLUSTER_INVALIDATION_CACHE
This error occurs because a child thread of the cache disconnect routine is hanging and therefore the servers do not respond to the shutdown command from the WebSphere Administration Console.
To stop the LiveCycle ES servers from the WebSphere Administration Console successfully:
- Log in to the WebSphere Administrative Console and, in the navigation tree, click Servers > Application servers and then, in the right pane, click the server name.
- Under Server Infrastructure, click Java and Process Management > Process Definition.
- Under Additional Properties, click Java Virtual Machine and add or configure following JVM argument:-Dadobe.cache.controlled-shutdown-disabled=true
- Click Apply.
- Click OK and then click save directly to the master configuration.
- Repeat steps 1-6 on each node of the cluster.
- Restart the cluster.
Now, the WebSphere server shuts down successfully.
Microsoft is launching Windows 8 this fall, and touch, one of the newer ways of interacting with devices, will be a first class citizen at par with keyboard and mouse. The Apple iPad® has already made a splash and people are elated. Corporates are piloting touchscreen devices, and many IT professionals – from UI designers to CEOs, have already started carrying iPads instead of regular laptops. Where has this change left us- the technical writers? In this technologically ever-changing world of touch, how do technical writers adapt and stay relevant?
As the industry changes, so do job roles and skills. We are living in a world that is constantly evolving. Technical writers need to equip themselves for the touch world. The future of the technical writers is evolving into two categories. Writers producing documentation for enterprise products would fall into one category. The second category nests writers from the non-enterprise world. These writers (non-enterprise) are more accustomed to the Instructional Design paradigm; for example, a writer who develops content for the touch-based apps.
The non-enterprise writers would work on a lot of short-term projects and need to learn more skills than core writing. These writers would contribute to preparing tutorials, videos, and building community for the product. One such example is Photoshop Touch. Photoshop Touch has a product tutorial that explains the step-by-step usage of the product.
PhotoShop Touch Tutorials
The enterprise technical writers would still be closer to the traditional technical writer paradigm, and these writers would acquire in-depth domain knowledge. These writers may become super-users of the product and can be the voice of the customers in a company. Subject matter expertise and customer-facing experience could enable enterprise writers to suggest new features for a product.
Change is here, in the form of touch apps; probably a good time to pick a tablet and ponder over the change.
I am working on a project that requires submitting the content of the PDF document as a stream to a Servlet. For the most part, the project works fine – the form is posted by the Acrobat/Reader, the server receives the file, creates a local copy and processes it correctly. After the post is successfully received, the last step on the server is to send a reply to the Acrobat/Reader. On not receiving a reply, the Adobe Acrobat/Reader throws an unknown format error.
Reason of the problem is that the Adobe Acrobat/ Reader expect a return from the servlet and the application server was not generating a response that Acrobat/Reader understands. To remove the error message, the servlet should return a properly constructed FDF and the URL of the submit button should end with #FDF.
Note: I am using Adobe LiveCycle Designer; I believe you can use Adobe Acrobat to achieve the same result.
Here are the exact steps to remove the error:
- Open your XDP form in LiveCycle Designer.
- Select the Submit button.
- Either in the Design View or in the Source view, edit submit to URL to add #FDF at the end of the URL.
- Save the XDP.
- In your Java project, create a plain-text file and add the following content:
%FDF-1.2 1 0 obj << /FDF << /Status (Your message goes here.) >> >> endobj trailer << /Root 1 0 R >> %%EOF
- Replace “Your message goes here.” with the text you want to display.
- Save the file. For this example, let us save the file as returnresponse.txt
- Import returnresponse.txt to your Java project.
- Add the following code to your servlet:
response.("returnresponse.txt", "The file has been submitted sucessfully");
The Java code sets the MIME type of the response in the “Content-type” HTTP header to “application/vnd.fdf“.
- Run the program and you should not experience the error again.