[MGNLIMG-59] Can't expire image generation jobs, the jcr session can be already closed Created: 28/Jul/09  Updated: 04/Dec/13  Resolved: 04/Sep/09

Status: Closed
Project: Imaging
Component/s: image operations
Affects Version/s: None
Fix Version/s: 2.0.2

Type: Bug Priority: Major
Reporter: Magnolia International Assignee: Magnolia International
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
duplicate
is duplicated by MGNLETK-8 Passing NodeData as a parameter to im... 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:

 Description   

It seems there is a consistent exception being thrown when images are being generated the first time - at least with the stk integration:

2009-07-28 10:30:09,595 ERROR info.magnolia.cms.core.DefaultNodeData            : Failed to get handle
2009-07-28 10:30:09,595 ERROR info.magnolia.cms.core.DefaultNodeData            : this session has been closed
javax.jcr.RepositoryException: this session has been closed
	at org.apache.jackrabbit.core.SessionImpl.sanityCheck(SessionImpl.java:381)
	at org.apache.jackrabbit.core.ItemImpl.sanityCheck(ItemImpl.java:137)
	at org.apache.jackrabbit.core.ItemImpl.getPath(ItemImpl.java:1270)
	at info.magnolia.cms.core.DefaultNodeData.getHandle(DefaultNodeData.java:571)
	at info.magnolia.cms.util.NodeDataWrapper.getHandle(NodeDataWrapper.java:114)
	at info.magnolia.imaging.parameters.SimpleEqualityNodeDataWrapper.hashCode(SimpleEqualityNodeDataWrapper.java:39)
	at info.magnolia.module.extendedtemplatingkit.imaging.generation.STKParameter.hashCode(STKParameter.java:79)
	at info.magnolia.imaging.caching.ImageGenerationJob.hashCode(ImageGenerationJob.java:62)
	at com.google.common.collect.MapMaker$Strength$3.hash(MapMaker.java:374)
	at com.google.common.collect.MapMaker$StrategyImpl.hashKey(MapMaker.java:498)
	at com.google.common.collect.CustomConcurrentHashMap$Impl.hash(CustomConcurrentHashMap.java:634)
	at com.google.common.collect.CustomConcurrentHashMap$Impl.remove(CustomConcurrentHashMap.java:1495)
	at com.google.common.collect.MapMaker$StrategyImpl$1.run(MapMaker.java:483)
	at java.util.TimerThread.mainLoop(Timer.java:512)
	at java.util.TimerThread.run(Timer.java:462)

Images are however correctly generated and seemingly properly cached.



 Comments   
Comment by Philipp Bärfuss [ 30/Jul/09 ]

The session is closed as soon the request which processed the image returns. The questions is why the TimerThread tries to remove the item from the map but not the thread processing the image. Or is in fact an other thread processing the image than the requests one (which would be questionable)?. Anyway the STKParameter cannot create the hash code at this point as it can't read the handle from the node data any more.

This might actually be quite dangerous as this thread (TimerThread) uses content acquired by an other Thread's context. This simply means that a this 'foreign' Thread is keeping a reverence to the jcr session.

Generated at Mon Feb 12 02:11:52 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.