[MAGNOLIA-6333] java.nio.file.InvalidPathException during publishing and unpublishing on version 5.4 Created: 03/Aug/15  Updated: 15/Apr/16  Resolved: 08/Oct/15

Status: Closed
Project: Magnolia
Component/s: admininterface, resource-loader
Affects Version/s: 5.4
Fix Version/s: 5.4.3

Type: Bug Priority: Major
Reporter: impact Assignee: Mikaël Geljić
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: 0d
Time Spent: 0.25d
Original Estimate: Not Specified

Attachments: Text File AuthorAndPublicStacktrace.txt     Text File bug_exception.txt    
Issue Links:
dependency
is depended upon by MAGNOLIA-6365 Unclosed sessions on JcrResourceOrigi... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Sprint: Basel 14
Story Points: 5

 Description   

I am trying to upgrade to 5.4 magnolia version(from fresh empty schemas). On 5.4 on publishing/unpublishing I get exception(exception log attached):

java.nio.file.InvalidPathException: Illegal char <:> at index 48: C:\dev\apache-tomcat-8.0.21\webapps\mg-auth\/jcr:system/jcr:versionStorage/af/72/95/af72957c-bb65-4132-881c-205eee9e68f3/1.6

The same exception happens when I download magnolia bundle with bundled tomcat and try to run it(so no changes from my side).

then possibly resulting in: "Unclosed session detected"

The resource loader was introduced in 5.4 under admin-ui-central.
As of 5.3.9 we had clean logs during publishing/unpublishing.

Could you please assist me with that? Otherwise I will have to stick with 5.3.9.

The publishing and unpublishing works as expected, just the error messages in the logs. But judging from the severity I am not confident to continue with them.

I am inheriting from parent bundle with following transitive dependencies in web app:

<dependency>
			<groupId>info.magnolia.ui</groupId>
			<artifactId>magnolia-ui-admincentral</artifactId>
		</dependency>
		<dependency>
			<groupId>info.magnolia</groupId>
			<artifactId>magnolia-module-scheduler</artifactId>
		</dependency>
		<dependency>
			<groupId>info.magnolia.widgetset</groupId>
			<artifactId>magnolia-vaadin-widgetset</artifactId>
		</dependency>
		<dependency>
			<groupId>info.magnolia.pages</groupId>
			<artifactId>magnolia-pages-app</artifactId>
		</dependency>
		<dependency>
			<groupId>info.magnolia.security</groupId>
			<artifactId>magnolia-security-app</artifactId>
		</dependency>
		<dependency>
			<groupId>info.magnolia.about</groupId>
			<artifactId>magnolia-about-app</artifactId>
		</dependency>
		<dependency>
			<groupId>info.magnolia</groupId>
			<artifactId>magnolia-rendering</artifactId>
		</dependency>
		<dependency>
			<groupId>info.magnolia</groupId>
			<artifactId>magnolia-templating</artifactId>
		</dependency>
		<dependency>
			<groupId>info.magnolia</groupId>
			<artifactId>magnolia-templating-jsp</artifactId>
		</dependency>
		<dependency>
			<groupId>info.magnolia.cache</groupId>
			<artifactId>magnolia-module-cache</artifactId>
		</dependency>
		<dependency>
			<groupId>info.magnolia.activation</groupId>
			<artifactId>magnolia-module-activation</artifactId>
		</dependency>
		<dependency>
			<groupId>info.magnolia</groupId>
			<artifactId>magnolia-module-mail</artifactId>
		</dependency>
		<dependency>
			<groupId>info.magnolia</groupId>
			<artifactId>magnolia-jaas</artifactId>
		</dependency>
		<dependency>
			<groupId>info.magnolia.dam</groupId>
			<artifactId>magnolia-dam</artifactId>
		</dependency>
		<dependency>
			<groupId>info.magnolia.rest</groupId>
			<artifactId>magnolia-rest-services</artifactId>
		</dependency>
		<dependency>
			<groupId>info.magnolia.rest</groupId>
			<artifactId>magnolia-rest-integration</artifactId>
		</dependency>
		<dependency>
			<groupId>info.magnolia.rest</groupId>
			<artifactId>magnolia-rest-tools</artifactId>
		</dependency>
		<dependency>
			<groupId>org.apache.tika</groupId>
			<artifactId>tika-parsers</artifactId>
		</dependency>
		<dependency>
			<groupId>org.bouncycastle</groupId>
			<artifactId>bcprov-jdk16</artifactId>
			<version>1.46</version>
		</dependency>
		<dependency>
			<groupId>org.bouncycastle</groupId>
			<artifactId>bcmail-jdk16</artifactId>
			<version>1.46</version>
		</dependency>
		<dependency>
			<groupId>village</groupId>
			<artifactId>village</artifactId>
			<version>2.0</version>
		</dependency>

		<dependency>
			<groupId>org.apache.torque</groupId>
			<artifactId>torque-runtime</artifactId>
			<version>4.0</version>
		</dependency>

		<dependency>
			<groupId>net.sourceforge.openutils</groupId>
			<artifactId>openutils-log4j</artifactId>
		</dependency>

		<dependency>
				<groupId>xerces</groupId>
				<artifactId>xercesImpl</artifactId>
				<version>2.11.0</version><!--$NO-MVN-MAN-VER$-->
		</dependency>



 Comments   
Comment by Jan Haderka [ 07/Aug/15 ]

The "unclosed session" is indeed most likely result of the other issue you see. As for other issue, from what I can tell, resource loader is for some reason trying to use identifier of a version of content and use it to locate file in the file system. Why? No clue, but it can't succeed even if path was valid. However I failed to reproduce the same issue so it would help if you can provide some steps on how to reproduce it. Does it happen when publishing content that is part of the demo or just your own? On final version of 5.4 or on some earlier milestone build? Do you get it on clean install or only on upgraded instance?

Comment by impact [ 12/Aug/15 ]

On windows machine the default bundle does not work properly throwing mentioned exceptions, linux looks ok.

To reproduce download cms bundle from:

https://documentation.magnolia-cms.com/display/DOCS/Installing+Magnolia#InstallingMagnolia-DownloadMagnolia

Run application as per instructions: magnolia-control.bat start

Install all modules as requested for both author and public, and then run both apps.

Publish: "Travel Home"

Get: Invalid character exception

5.3.9 does not have this issue.

Comment by impact [ 13/Aug/15 ]

Answers to questions:
1. Happens when publishing/unpublishinh demo page "travel home" in preconfigured predownloaded 5.4 with bundled tomcat.

2.version 5.4 release

3. The "invalid char" exception happens on clean install of 5.4 the official magnolia distribution with tomcat bundle.

"Invalid char" and following "unclosed session detected" exceptions happen on 5.3.9 to 5.4 upgrade my own distribution created from archetype.

So the first exception 100% consistently appears when bundled app following the magnolia control bat execution + auto module install. On Windows 7 pro x64.

Thanks.

Comment by impact [ 13/Aug/15 ]

On lubuntu bundled tomcat with magnolia distribution worked with no issues. Clean logs on publishing/unpublishing.

Comment by Jan Haderka [ 13/Aug/15 ]

Which exact version of Java are you using on Windows? And did you try with same version on ubuntu or was it different one?

Comment by impact [ 13/Aug/15 ]

java version "1.8.0_45" on both machines exactly the same. Tomcat 8 initially , but then due to issues I tried with bundled tomcat 7 just to see if that makes any difference. Exactly the same behavior.

Comment by Jan Haderka [ 31/Aug/15 ]

If I'm guessing this right, you should be able to find out same error on startup as well. The problem seems to be caused by the fact that you set your directory for observation to the webapp folder and also have your repository in the webapp (which is why I would expect to see similar errors on startup when Magnolia searches for files to observe). Error is then triggered again when activation updates file system, thus triggering another parse of the files in file system.

As for the observation error, this is unrelated, and will be solved separately in MGNLOBS-35

Comment by Evzen Fochr [ 01/Sep/15 ]

I am afraid that MGNLOBS-35/MAGNOLIA-6363 is not related, because here is not used systemContext. For future, possible culprit is CommandEventListener#createContext() .

Comment by Evzen Fochr [ 01/Sep/15 ]

Created separate ticket for observation issue.

Comment by Edgar Vonk [ 02/Sep/15 ]

We run into this issue as well on Magnolia 5.4.1. It only seems to happen on Windows machines. Not on Mac or Linux.

Comment by Jan Haderka [ 02/Sep/15 ]

@edgar could you please confirm whether it still happens with cache 5.4.2? We are having troubles to replicate this one. Thx

Comment by Stef te Winkel [ 02/Sep/15 ]

I am working with @edgar and can report that switching to the 5.4.2 ehcache didn't work.

First we had problems like the one reported in this issue https://jira.magnolia-cms.com/browse/MGNLCACHE-121 on Windows machines ( Illegal char <:>) .
Going back to the 5.4 version of ehcache did solve that issue, but then the publishing exceptions of this issue occurs.

Referring to the 5.4.2 ehcache (we didn't know it existed already) didn't show the errors we first encountered with https://jira.magnolia-cms.com/browse/MGNLCACHE-121 (first occuring with starting up Jetty) but the publishing still gives the same errors unfortunately.

Comment by Jan Haderka [ 02/Sep/15 ]

twinkel Are you able to find out whether error is coming from public or author instance? (you should be able to see it in appropriate magnolia-[debug|error].log And for that instance, can your provide me w/ value of magnolia.resources.dir and magnolia.repositories.home?
Thanks

Comment by Stef te Winkel [ 02/Sep/15 ]

The errors are in the logs of both instances (and exactly the same).

For both instances also this property is there:

magnolia.resources.dir=${magnolia.home}/../../../magnolia-module-XXX-website/src/main/resources 

furthermore:

magnolia.repositories.home=${serverdata.rootdir}/repositories/magnoliaAuthor
magnolia.repositories.home=${serverdata.rootdir}/repositories/magnoliaPublic

where

 serverdata.rootdir=../../serverdata
Comment by Jan Haderka [ 03/Sep/15 ]

And the path you get in the exception points to the repo correct? That is super weird. It looks like we are observing repo even tho it is outside of the resources ... that shouldn't be. Thanks for all the extra info.

Comment by Stef te Winkel [ 04/Sep/15 ]

Uploaded attachment with some stacktrace with exceptions on Author and Public

Comment by Philip Mundt [ 12/Oct/15 ]

QA tested with EE (5.4.2 and 5.4.3-SNAPSHOT) on Windows:

  • 5.4.2 shows the error before publication (starting the publication workflow is actually not possible)
  • 5.4.3-SNAPSHOT works
Generated at Mon Feb 12 04:13:31 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.