Cookies error

I have a couple of things to add to this.

1) Rebuilding the entire repository as I've described is a pretty heavy-handed workaround.  That said, I don't have a better idea and neither does Adobe Support at this time.

2) Coming from LC ES3, I'm used to restarting JBoss and watching for the "started in N seconds" line in the log, at which point I know that everything's up and running.  That's not the case here.  If you rebuild the repository it's advisable to wait quite a bit longer (like 1 hour or more) before you access workspace.

3) I believe the problem occurs after logging into CRXDE Lite and AEM Forms Workspace at the same time with the same user account and the same browser.  This causes AEM to get into some conflicty state where you can no longer log into AEM Forms Workspace.  I have adopted a habit of using separate user accounts and separate browsers for CRXDE Lite and Workspace.  Since I started that practice, I have not had the dreaded Cookies problem.

Hi Jared,

Adding to your 2nd point.

Since you have been using J2EE side from long .Instead of just waiting for an hour a good to way to confirm the start /stop operation is to tail the CRX error logs( [AEM-Installation-Directory]/crx-quickstart/logs) and see it the logs have stabilized.So, apart from App server logs, CRX error logs and OSGI bundle state may give you an information about the successful start of an instance.The same would also help in scenarios when you have to patch the environment with any CFP or SP .

Hi Mayank. If we wanted to automatically scan for AEM Forms being ready in the OSGi environment, what should we specifically look for from a logging perspective?

I saw this line recently and wondered if this is what we should scan for:

1. 09.04.2018 14:47:08.833 *INFO* [FelixDispatchQueue] com.adobe.fd.core.startup.AEMFormsStartupListener AEMFormsStartupListener -- startup has finished

Hi Darren,

Although checking for 'AEMFormsStartupListener -- startup has finished' is a good option but you may find that in the number of cases it might not appear in the logs.The best way again would be to log in to system/console and check for the bundle's state.

We are starting to experience this problem as well.   We are running AEM forms 6.2

So far the only difference seems to be the the users getting the error are running Chrome on a Windows 10 machine.

Using Chrome on a Windows 7 machine seems to work ok.

I had this problem also and found another possible reason.

I was using the long URL to access Workspace:

http://<aem_forms_server>/lc/libs/livecycle/core/content/login.html?ap=1

I get the error about the cookies in every browser (Chrome, FF, IE and Edge), both on the server itself, and through remote access.

When I switched to the short URL, it works:

http://<aem_forms_server>/lc/ws

So this error seems to have multiple causes, which reflects the previous comment that it appears to be a catch all, when an unexpected error occurs.