Sometimes CFTHREAD cannot join with other CFTHREAD of same page. Pls open ticket if you can/want.

[Desmond Miles]

Hi,

I'm testing cfthread since few days now in order to develop a specifc backend feature.

I know about ACF9 behaviour and that's why this led me to this recently : https://groups.google.com/forum/#!topic/lucee/as_hgdxc42w

Today I've encounter a kind of problem/bug with Lucee's cfthread (Lucee 4.5.1.015 / JDK7, Tomcat8 / Linux).

I would describe the bug as follow :

• Sometimes onRequestEnd() is finished before all child threads are created/started.
• Maybe this happens randomly but when it is the case then a given child thread will fail to join with others.
  
• i.e The child thread getPageContext().getParentPageContext().getThreadScopeNames() will return an empty array.
  

One possible explanation could be that thread creation/start is deferred from the application listener execution.

One workaround in the meantime is to make the current request wait for all thread creation/start before onRequestEnd().

If someone could confirm this issue and/or raise a ticket I would really appreciate (In fact I could but long and hard to explain why I don't).

Also you may not be able to easily reproduce the bug (may or may not) because this may seem to happen randomly while it doesn't.

In my case I couldn't reproduce the bug when I refreshed the same page. But I could when I open the same page in a new browser page (i.e instead of refreshing).

This is a snippet which could help to understand the issue (the "var" keywords came from a function of mine...) :

<cfscript>
	// Say this file is index.cfm and an Application.cfc exists in the same dir
	
	// A basic thread
	cfthread(name="T1",action="run") {
		writeLog("=== T1 starts ===");
		// Does a lot of thing here which last more than a second
	};
	// Another thread which wants to join with the first above
	cfthread(name="T1-monitor",action="run") {
		writeLog("=== T1 monitor starts ===");
		try {
			threadJoin("T1",someTimeouValue);
			// Does a lot of thing here which last more than a second
		} catch(any error) {
			// An exception is catched here when the bug occurs
			// It mainly says that there's no thread named "T1" and that there's no other threads eithers in the page context
		}
	};
	/* Say in Application.onRequestStart() there's a log like "Executing onRequestStart()"
	And in Application.onRequestEnd() there's a log like "Executing onRequestEnd()".
	
	So when the bug occurs, then you get the following log output :
	-> "Executing onRequestStart()"
	-> "Executing onRequestEnd()"
	-> "=== T1 starts ==="
	-> "=== T1 monitor starts ==="
	
	And when the bug DOES NOT occurs, then you get the following log output :
	-> "Executing onRequestStart()"
	-> "=== T1 starts ==="
	-> "=== T1 monitor starts ==="
	-> "Executing onRequestEnd()"
	*/
</cfscript>

One can test the result of one of : structKeyList(cfthread), getPageContext().getThreadScopeNames(), etc...

PS : Also if someone could advice a good online copy/paste cfml syntax highlighter that works with google groups...

[Desmond Miles]

I've noticed that my log example in the comment above may be confusing to understand the real issue here...

So please notice that this bug "probably" occurs because the main page context content is released before the doJoin() could get the thread names from the parent page context.

[Desmond Miles]

Hence the workaround I stated cannot work (sadly) i.e "making the current request thread wait for child thread creation before onRequestEnd()" -> No effect

[Desmond Miles]

For those interested, the current error message can be foun here in doJoin() :

https://bitbucket.org/lucee/lucee/src/2a207d2b9da27d9935afc48d069627cb1bb47069/lucee-java/lucee-core/src/lucee/runtime/tag/ThreadTag.java?at=master#cl-334

PS : Sorry for posting several pieces like that :(

[Desmond Miles]

My first ticket created ! Here : https://luceeserver.atlassian.net/browse/LDEV-380

<cfset waitBeforeJoin=500>
<cfset waitToMakeJoinHappenBefore=0>

<cfthread name="T1" action="run">
	<cflog text="=== #thread.name# starts ===">
	<!--- Sleep long enough --->
	<cfset sleep(waitBeforeJoin + waitToMakeJoinHappenBefore + 2000)>
	<cflog text="=== #thread.name# ends ===">
</cfthread>
<cfthread name="T2" action="run">
	<cftry>
		<cflog text="=== #thread.name# starts ===">
		<!--- This sleep will cause the bug if it last too long than waitToMakeJoinHappenBefore
		Because Application.onRequestEnd() will finish before this join i.e getThreadScopeName() is empty
		For example these values won't never cause the error
		-> waitBeforeJoin=500
		-> waitToMakeJoinHappenBefore=waitBeforeJoin + 700
		--->
		<cfif waitBeforeJoin GT 0>
			<cfset sleep(waitBeforeJoin)>
		</cfif>
		<!--- Join sometimes fails because getPageContext().getParentContext().getThreadScopeName() is empty
		Error : "T2 join error: there is no thread running with the name [t1], only the following threads existing []"
		--->
		<cfthread action="join" name="T1" timeout="5000">
		<cflog text="=== #thread.name# join passed successfully ===">
		<cfcatch type="any">
			<cflog type="error" text=">>> #thread.name# join error: #cfcatch.message#">
		</cfcatch>
	</cftry>
</cfthread>
<!--- Sometimes this can be a workaround : Wait and perhaps the join will start before onRequestEnd()  --->
<cfif waitToMakeJoinHappenBefore GT 0>
	<cfset sleep(waitToMakeJoinHappenBefore)>
</cfif>

<!--- Just a dummy output --->
<cfoutput>Page ends i.e next is Application.onRequestEnd()<br></cfoutput>

[Dominic Watson]

Nice one :) (though obviously not so good re the bug)

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/49042e9d-5cb2-476b-a662-87449565633d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Pixl8 Interactive, 3 Tun Yard, Peardon Street, London SW8 3HT, United Kingdom T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: in...@pixl8.co.uk

Follow us on: Facebook Twitter LinkedIn

CONFIDENTIAL AND PRIVILEGED - This e-mail and any attachment is intended solely for the addressee, is strictly confidential and may also be subject to legal, professional or other privilege or may be protected by work product immunity or other legal rules. If you are not the addressee please do not read, print, re-transmit, store or act in reliance on it or any attachments. Instead, please email it back to the sender and then immediately permanently delete it. Pixl8 Interactive Ltd Registered in England. Registered number: 04336501. Registered office: 8 Spur Road, Cosham, Portsmouth, Hampshire, PO6 3EB

[Desmond Miles]

Thanks.
Sorry but what do you mean by "re the bug" ?

[Alex Skinner]

Dominic means nice one / good find, though its not good that there is the bug of course.

Cheers

Alex

On 2 June 2015 at 17:36, Desmond Miles <onel...@gmail.com> wrote:

Thanks.
Sorry but what do you mean by "re the bug" ?

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/85f35577-7f67-4d06-88ea-741ae6850a7e%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Alex Skinner
Managing Director

Pixl8 Interactive, 3 Tun Yard, Peardon Street, London SW8 3HT, United Kingdom T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: in...@pixl8.co.uk

[Andrew Dixon]

Hi Desmond,

Good find!!! If you have time soon do you want to take a stab at triaging the issue and writing the test case? Instructions can be found here:

http://www.strayegg.com/2015/05/10/triaging-lucee-issues-in-jira/

Kind regards,

Andrew

about.me - mso - Lucee Association Member

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAFrbJ5UA%3Dm39pjX8hc9X1Vc37QG-Q9%2B4AGQ18EN83WLZ%3DziD-g%40mail.gmail.com.

[Desmond Miles]

Hi Andrew,

To be honest, I think this won't be possible. I will probably try but I can't promise anything on it.

Most of my dev time is at the company I work for and our methodology is focused on workaround and/or use other solution when not working.

e.g in this case it could have ended by using java.concurrent API if no workaround.

It would be nice if someone else can triage the issue (not forcing anyone here though).

Your link about "triaging" really interest me because I also do cfml on free time along with many other personal stuff.

So this may be where I probably try to achieve "issue triaging". The problem is this is not for the immediate timing.