Turbine 4.0.1 seems to "stall" after long period

Discussion:

Jeffery Painter

2018-03-27 13:49:00 UTC

Hello,

As you know I have been busily building some new apps with Turbine 4.0.1

I am using Ubuntu 17.10 with the default Tomcat install: tomcat8
8.5.21-1ubuntu1 and Java 1.8.0_162

After some period (>24 hours), when I go to login to the Turbine app, it
just sits there and hangs. I am going to increase the log levels to
debug, but I don't see any immediate errors popping up. It just hangs on
trying to process the user login action. If I go into the Tomcat admin
manager and stop/start the app, it works again and will process user
logins. I think this is a pretty critical issue.

Not sure if anyone else is seeing this. It has happened to me a few
times. At first, I thought there might be some issues with having old
Turbine 2.3.x apps running in the same container (I was getting some odd
behavior with mixed versions and logging - it was throwing all the logs
from the new apps into the 2.3.x log folder).

I made a point to rename all my app log files with
[appname]-turbine.log, [appname]-velocity.log etc, and at least then
they were not colliding.

I have since gotten rid of all my Turbine 2.3.x based apps, and the
logging issue has gone away (all apps log to their own log directories
properly now). But the stall out on user logins has reared its ugly
head again.

I haven't put anything into real production yet, so I will give it a few
days and see if the behavior is repeatable.

Anyone else seeing this?

Thanks
--
Jeff Painter

CEO and Founder of JiveCast
Software and analytics, made together
http://jivecast.com

301 Fayetteville St. Unit 2301, Raleigh, NC 27601
(919) 533-9024

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@turbine.apache.org
For additional commands, e-mail: dev-***@turbine.apache.org

Georg Kallidis

2018-03-27 15:49:39 UTC

Permalink

Using Tomcat 7.x and Java 7/8 no problems are encountered here. You have
probably already checked pool size, memory and non-closed database
connections (anything remarkable in the database connections/log and
reviewed the top cmd?

Tomcat 8.5 has removed log4 1.x anymore, though.. as a last resort, if you
want to change logging you can exclude log4j (and even commons-logging)
and use e.g. log4j-over-slf4j (and jcl-over-slf4j) and another binding
(e.g. logback). You may then have to map log4j.properties to logback.xml
and provide logbackConfigLocation in web.xml. Switch back to Tomcat 8.0.x?

https://tomcat.apache.org/tomcat-8.5-doc/changelog.html

-Georg

Von: Jeffery Painter <***@jivecast.com>
An: Turbine Developers List <***@turbine.apache.org>
Datum: 27.03.2018 15:49
Betreff: Turbine 4.0.1 seems to "stall" after long period

Hello,

As you know I have been busily building some new apps with Turbine 4.0.1

I am using Ubuntu 17.10 with the default Tomcat install: tomcat8
8.5.21-1ubuntu1 and Java 1.8.0_162

After some period (>24 hours), when I go to login to the Turbine app, it
just sits there and hangs. I am going to increase the log levels to
debug, but I don't see any immediate errors popping up. It just hangs on
trying to process the user login action. If I go into the Tomcat admin
manager and stop/start the app, it works again and will process user
logins. I think this is a pretty critical issue.

Not sure if anyone else is seeing this. It has happened to me a few
times. At first, I thought there might be some issues with having old
Turbine 2.3.x apps running in the same container (I was getting some odd
behavior with mixed versions and logging - it was throwing all the logs
from the new apps into the 2.3.x log folder).

I made a point to rename all my app log files with
[appname]-turbine.log, [appname]-velocity.log etc, and at least then
they were not colliding.

I have since gotten rid of all my Turbine 2.3.x based apps, and the
logging issue has gone away (all apps log to their own log directories
properly now). But the stall out on user logins has reared its ugly
head again.

I haven't put anything into real production yet, so I will give it a few
days and see if the behavior is repeatable.

Anyone else seeing this?

Thanks
--
Jeff Painter

CEO and Founder of JiveCast
Software and analytics, made together
http://jivecast.com

301 Fayetteville St. Unit 2301, Raleigh, NC 27601
(919) 533-9024

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@turbine.apache.org
For additional commands, e-mail: dev-***@turbine.apache.org

Jeffery Painter

2018-03-27 17:32:15 UTC

Permalink

Thanks Georg,

As I said, I can't force the error - I have increased logging and will
just see if I can catch it happening in the wild to determine what might
be causing the problem. Nothing else is running on this dev machine
except tomcat and a MySQL instance.

If I can track it down, I will come back to the list with the info. I
was just wondering if anyone else has noticed it yet.

I can try setting up additional VMs with Tomcat 7 and 8.0.x, then let it
run for a few days and see if it happens there or not. Unfortunately,
Ubuntu doesn't push tomcat releases as often as I would like, so I could
try to manually setup the latest 8.5 series and see if they corrected
it.... looks like more testing in my future!

--
Jeff

Post by Georg Kallidis
Using Tomcat 7.x and Java 7/8 no problems are encountered here. You have
probably already checked pool size, memory and non-closed database
connections (anything remarkable in the database connections/log and
reviewed the top cmd?
Tomcat 8.5 has removed log4 1.x anymore, though.. as a last resort, if you
want to change logging you can exclude log4j (and even commons-logging)
and use e.g. log4j-over-slf4j (and jcl-over-slf4j) and another binding
(e.g. logback). You may then have to map log4j.properties to logback.xml
and provide logbackConfigLocation in web.xml. Switch back to Tomcat 8.0.x?
https://tomcat.apache.org/tomcat-8.5-doc/changelog.html
-Georg
Datum: 27.03.2018 15:49
Betreff: Turbine 4.0.1 seems to "stall" after long period
Hello,
As you know I have been busily building some new apps with Turbine 4.0.1
I am using Ubuntu 17.10 with the default Tomcat install: tomcat8
8.5.21-1ubuntu1 and Java 1.8.0_162
After some period (>24 hours), when I go to login to the Turbine app, it
just sits there and hangs. I am going to increase the log levels to
debug, but I don't see any immediate errors popping up. It just hangs on
trying to process the user login action. If I go into the Tomcat admin
manager and stop/start the app, it works again and will process user
logins. I think this is a pretty critical issue.
Not sure if anyone else is seeing this. It has happened to me a few
times. At first, I thought there might be some issues with having old
Turbine 2.3.x apps running in the same container (I was getting some odd
behavior with mixed versions and logging - it was throwing all the logs
from the new apps into the 2.3.x log folder).
I made a point to rename all my app log files with
[appname]-turbine.log, [appname]-velocity.log etc, and at least then
they were not colliding.
I have since gotten rid of all my Turbine 2.3.x based apps, and the
logging issue has gone away (all apps log to their own log directories
properly now). But the stall out on user logins has reared its ugly
head again.
I haven't put anything into real production yet, so I will give it a few
days and see if the behavior is repeatable.
Anyone else seeing this?
Thanks

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@turbine.apache.org
For additional commands, e-mail: dev-***@turbine.apache.org

Thomas Vandahl

2018-03-30 07:41:43 UTC

Permalink

Hi Jeffery,

Post by Jeffery Painter
After some period (>24 hours), when I go to login to the Turbine app, it
just sits there and hangs. I am going to increase the log levels to
debug, but I don't see any immediate errors popping up. It just hangs on
trying to process the user login action. If I go into the Tomcat admin
manager and stop/start the app, it works again and will process user
logins. I think this is a pretty critical issue.

If you want to debug this, you may force a thread dump from the command
line (kill -3 <java-pid>) and see if some locked thread looks familiar.

Bye, Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@turbine.apache.org
For additional commands, e-mail: dev-***@turbine.apache.org

Jeffery Painter

2018-04-01 15:44:47 UTC

Permalink

Hi Thomas,

It happened again. I have 3 Turbine 4.0.1 apps running on the same
Tomcat 8.5 instance. I had just uploaded a new version of the software
yesterday at 2:52pm. A friend came over, I showed him my software and
we logged out at 9:20pm.

I checked the logs. There was no attempted access between 9:20pm and
this morning (almost 12 hours later) at 9:58am.

I went to the login screen, and it just hangs. The other two
applications are running fine. I tried kill -3 <pid> but it didn't
actually kill the tomcat instance. Instead, I went back to the tomcat
manager, hit "reload" on the app, and it started responding fine again.

The application.log file shows the following behavior now:

-- last calls to the server last night around 9:20pm...

2018-03-31 21:20:43,037 [http-nio-8080-exec-70] DEBUG
org.apache.turbine.util.ServerData - setServerScheme(http)
2018-03-31 21:20:43,037 [http-nio-8080-exec-70] DEBUG
org.apache.turbine.util.ServerData - setScriptName(/app)
2018-03-31 21:20:43,037 [http-nio-8080-exec-70] DEBUG
org.apache.turbine.util.ServerData - setContextPath(/smarttext)
2018-03-31 21:20:43,037 [http-nio-8080-exec-70] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Looking up service
for injection: org.apache.fulcrum.localization.LocalizationService for
object ***@bc7a8a9
2018-03-31 21:20:43,037 [http-nio-8080-exec-70] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Injection of
org.apache.fulcrum.localization.LocalizationService into object
***@bc7a8a9
2018-03-31 21:20:43,037 [http-nio-8080-exec-70] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Looking up service
for injection: org.apache.fulcrum.intake.IntakeService for object
***@4489ce5c
2018-03-31 21:20:43,037 [http-nio-8080-exec-70] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Injection of
org.apache.fulcrum.intake.IntakeService into object
***@4489ce5c
-- end of activity from March-31

-- first call to the server on April-01 at 9:58am

2018-04-01 09:58:35,249 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.Turbine - Changing Input Encoding to UTF-8
2018-04-01 09:58:35,249 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.util.ServerData - setServerName(dev.jivecast.com)
2018-04-01 09:58:35,249 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.util.ServerData - setServerPort(443)
2018-04-01 09:58:35,249 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.util.ServerData - setServerScheme(https)
2018-04-01 09:58:35,249 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.util.ServerData - setScriptName(/app)
2018-04-01 09:58:35,249 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.util.ServerData - setContextPath(/smarttext)
2018-04-01 09:58:35,249 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.pipeline.DetermineActionValve - No action
.
.
.
2018-04-01 09:58:35,278 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.util.ServerData - Copy
Constructor(https://dev.jivecast.com/smarttext/app)
2018-04-01 09:58:35,278 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.util.ServerData - setServerName(dev.jivecast.com)
2018-04-01 09:58:35,278 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.util.ServerData - setServerPort(443)
2018-04-01 09:58:35,278 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.util.ServerData - setServerScheme(https)
2018-04-01 09:58:35,278 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.util.ServerData - setScriptName(/app)
2018-04-01 09:58:35,278 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.util.ServerData - setContextPath(/smarttext)
2018-04-01 09:58:35,278 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Looking up service
for injection: org.apache.fulcrum.localization.LocalizationService for
object ***@2e2f2614
2018-04-01 09:58:35,278 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Injection of
org.apache.fulcrum.localization.LocalizationService into object
***@2e2f2614
2018-04-01 09:58:35,278 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Looking up service
for injection: org.apache.fulcrum.intake.IntakeService for object
***@6d9097ee
2018-04-01 09:58:35,278 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Injection of
org.apache.fulcrum.intake.IntakeService into object
***@6d9097ee

--- Application just stops here.... --- Subsequent calls are stopping at
the same point

2018-04-01 09:59:31,661 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.Turbine - Changing Input Encoding to UTF-8
2018-04-01 09:59:31,661 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.util.ServerData - setServerName(dev.jivecast.com)
2018-04-01 09:59:31,661 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.util.ServerData - setServerPort(443)
2018-04-01 09:59:31,661 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.util.ServerData - setServerScheme(https)
2018-04-01 09:59:31,661 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.util.ServerData - setScriptName(/app)
2018-04-01 09:59:31,661 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.util.ServerData - setContextPath(/smarttext)
2018-04-01 09:59:31,661 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.pipeline.DetermineActionValve - No action
2018-04-01 09:59:31,661 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.pipeline.DetermineActionValve - Action is now:
2018-04-01 09:59:31,661 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.pipeline.DetermineTargetValve - No target screen
2018-04-01 09:59:31,661 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.pipeline.DetermineTargetValve - Screen Target is now:
2018-04-01 09:59:31,661 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.services.assemblerbroker.TurbineAssemblerBrokerService
- Loading class
org.apache.turbine.modules.Action:sessionvalidator.TemplateSessionValidator

.
.
.

2018-04-01 09:59:31,676 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.util.ServerData - setContextPath(/smarttext)
2018-04-01 09:59:31,676 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Looking up service
for injection: org.apache.fulcrum.localization.LocalizationService for
object ***@5b07b50e
2018-04-01 09:59:31,676 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Injection of
org.apache.fulcrum.localization.LocalizationService into object
***@5b07b50e
2018-04-01 09:59:31,677 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Looking up service
for injection: org.apache.fulcrum.intake.IntakeService for object
***@389175eb
2018-04-01 09:59:31,677 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Injection of
org.apache.fulcrum.intake.IntakeService into object
***@389175eb

-- fails to process any further but still listening...

After reload, it will go past this point and the relevant injection
steps it takes are show below (which do execute properly)

2018-04-01 11:17:11,167 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.util.ServerData - setContextPath(/smarttext)
2018-04-01 11:17:11,168 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Looking up service
for injection: org.apache.fulcrum.localization.LocalizationService for
object ***@7eb80b1d
2018-04-01 11:17:11,168 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Injection of
org.apache.fulcrum.localization.LocalizationService into object
***@7eb80b1d
2018-04-01 11:17:11,168 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Looking up service
for injection: org.apache.fulcrum.intake.IntakeService for object
***@563e26b0
2018-04-01 11:17:11,168 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Injection of
org.apache.fulcrum.intake.IntakeService into object
***@563e26b0
2018-04-01 11:17:11,170 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Looking up service
for injection: SecurityService for object
***@72834b31
2018-04-01 11:17:11,170 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Injection of
SecurityService into object
***@72834b31
2018-04-01 11:17:11,170 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Injection of
***@10b3d93b into
object ***@72834b31
2018-04-01 11:17:11,170 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.services.pull.TurbinePullService - Adding
***@708a648a to ctx as
sessionData
2018-04-01 11:17:11,172 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.services.template.mapper.LayoutTemplateMapper -
doMapping(Login.vm)
2018-04-01 11:17:11,172 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.services.template.mapper.LayoutTemplateMapper -
templateName is Login.vm
2018-04-01 11:17:11,172 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.services.template.mapper.LayoutTemplateMapper -
templatePackage is now:
2018-04-01 11:17:11,172 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.services.template.mapper.LayoutTemplateMapper -
Looking for layouts/Login.vm
2018-04-01 11:17:11,172 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.services.template.mapper.LayoutTemplateMapper -
templatePackage is now:
2018-04-01 11:17:11,172 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.services.template.mapper.LayoutTemplateMapper -
Looking for layouts/Default.vm
2018-04-01 11:17:11,172 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.services.template.mapper.LayoutTemplateMapper - Found
it, returning Default.vm
2018-04-01 11:17:11,172 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.services.template.mapper.ClassMapper -
doMapping(Login.vm)
2018-04-01 11:17:11,172 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.services.template.mapper.ClassMapper - className is
Login.vm
2018-04-01 11:17:11,172 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.services.template.mapper.ClassMapper - classPackage
is now:
2018-04-01 11:17:11,172 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.services.template.mapper.ClassMapper - Looking for Login

.
.
.
etc...

I am wondering if there is something I may have configured wrong in the
lifecycle of my FluxTool code. I am using the same as what I had put on
github, so Georg, if you have had a chance to look at it, do you see
anything wrong with how I set it up?

https://github.com/jlpainter/turbine-flux/blob/master/src/main/flux/org/apache/turbine/flux/tools/FluxTool.java

In TR.props, I have it loading as a request tool:

#
# Custom tools
#
tool.request.flux=com.jivecast.smarttext.flux.tools.FluxTool

--
Jeffery

Post by Thomas Vandahl
Hi Jeffery,

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@turbine.apache.org
For additional commands, e-mail: dev-***@turbine.apache.org

Jeffery Painter

2018-04-02 17:41:26 UTC

Permalink

I suspect the problem was with the lifecycle of the FluxTool I had built
for the turbine-webapp - I just pushed a change to the SVN repo (modeled
it more closely after the Intake tool's dispose lifecycle). I will test
a couple more days and see if this fixes the stalling bug I have been
seeing.

Thanks!
Jeff

Post by Jeffery Painter
Hi Thomas,
It happened again. I have 3 Turbine 4.0.1 apps running on the same
Tomcat 8.5 instance. I had just uploaded a new version of the
software yesterday at 2:52pm. A friend came over, I showed him my
software and we logged out at 9:20pm.
I checked the logs. There was no attempted access between 9:20pm and
this morning (almost 12 hours later) at 9:58am.
I went to the login screen, and it just hangs. The other two
applications are running fine. I tried kill -3 <pid> but it didn't
actually kill the tomcat instance. Instead, I went back to the tomcat
manager, hit "reload" on the app, and it started responding fine again.
-- last calls to the server last night around 9:20pm...
2018-03-31 21:20:43,037 [http-nio-8080-exec-70] DEBUG
org.apache.turbine.util.ServerData - setServerScheme(http)
2018-03-31 21:20:43,037 [http-nio-8080-exec-70] DEBUG
org.apache.turbine.util.ServerData - setScriptName(/app)
2018-03-31 21:20:43,037 [http-nio-8080-exec-70] DEBUG
org.apache.turbine.util.ServerData - setContextPath(/smarttext)
2018-03-31 21:20:43,037 [http-nio-8080-exec-70] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Looking up service
for injection: org.apache.fulcrum.localization.LocalizationService for
2018-03-31 21:20:43,037 [http-nio-8080-exec-70] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Injection of
org.apache.fulcrum.localization.LocalizationService into object
2018-03-31 21:20:43,037 [http-nio-8080-exec-70] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Looking up service
for injection: org.apache.fulcrum.intake.IntakeService for object
2018-03-31 21:20:43,037 [http-nio-8080-exec-70] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Injection of
org.apache.fulcrum.intake.IntakeService into object
-- end of activity from March-31
-- first call to the server on April-01 at 9:58am
2018-04-01 09:58:35,249 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.Turbine - Changing Input Encoding to UTF-8
2018-04-01 09:58:35,249 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.util.ServerData - setServerName(dev.jivecast.com)
2018-04-01 09:58:35,249 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.util.ServerData - setServerPort(443)
2018-04-01 09:58:35,249 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.util.ServerData - setServerScheme(https)
2018-04-01 09:58:35,249 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.util.ServerData - setScriptName(/app)
2018-04-01 09:58:35,249 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.util.ServerData - setContextPath(/smarttext)
2018-04-01 09:58:35,249 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.pipeline.DetermineActionValve - No action
.
.
.
2018-04-01 09:58:35,278 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.util.ServerData - Copy
Constructor(https://dev.jivecast.com/smarttext/app)
2018-04-01 09:58:35,278 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.util.ServerData - setServerName(dev.jivecast.com)
2018-04-01 09:58:35,278 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.util.ServerData - setServerPort(443)
2018-04-01 09:58:35,278 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.util.ServerData - setServerScheme(https)
2018-04-01 09:58:35,278 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.util.ServerData - setScriptName(/app)
2018-04-01 09:58:35,278 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.util.ServerData - setContextPath(/smarttext)
2018-04-01 09:58:35,278 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Looking up service
for injection: org.apache.fulcrum.localization.LocalizationService for
2018-04-01 09:58:35,278 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Injection of
org.apache.fulcrum.localization.LocalizationService into object
2018-04-01 09:58:35,278 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Looking up service
for injection: org.apache.fulcrum.intake.IntakeService for object
2018-04-01 09:58:35,278 [ajp-nio-8009-exec-59] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Injection of
org.apache.fulcrum.intake.IntakeService into object
--- Application just stops here.... --- Subsequent calls are stopping
at the same point
2018-04-01 09:59:31,661 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.Turbine - Changing Input Encoding to UTF-8
2018-04-01 09:59:31,661 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.util.ServerData - setServerName(dev.jivecast.com)
2018-04-01 09:59:31,661 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.util.ServerData - setServerPort(443)
2018-04-01 09:59:31,661 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.util.ServerData - setServerScheme(https)
2018-04-01 09:59:31,661 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.util.ServerData - setScriptName(/app)
2018-04-01 09:59:31,661 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.util.ServerData - setContextPath(/smarttext)
2018-04-01 09:59:31,661 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.pipeline.DetermineActionValve - No action
2018-04-01 09:59:31,661 [ajp-nio-8009-exec-63] DEBUG
2018-04-01 09:59:31,661 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.pipeline.DetermineTargetValve - No target screen
2018-04-01 09:59:31,661 [ajp-nio-8009-exec-63] DEBUG
2018-04-01 09:59:31,661 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.services.assemblerbroker.TurbineAssemblerBrokerService
- Loading class
org.apache.turbine.modules.Action:sessionvalidator.TemplateSessionValidator
.
.
.
2018-04-01 09:59:31,676 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.util.ServerData - setContextPath(/smarttext)
2018-04-01 09:59:31,676 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Looking up service
for injection: org.apache.fulcrum.localization.LocalizationService for
2018-04-01 09:59:31,676 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Injection of
org.apache.fulcrum.localization.LocalizationService into object
2018-04-01 09:59:31,677 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Looking up service
for injection: org.apache.fulcrum.intake.IntakeService for object
2018-04-01 09:59:31,677 [ajp-nio-8009-exec-63] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Injection of
org.apache.fulcrum.intake.IntakeService into object
-- fails to process any further but still listening...
After reload, it will go past this point and the relevant injection
steps it takes are show below (which do execute properly)
2018-04-01 11:17:11,167 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.util.ServerData - setContextPath(/smarttext)
2018-04-01 11:17:11,168 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Looking up service
for injection: org.apache.fulcrum.localization.LocalizationService for
2018-04-01 11:17:11,168 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Injection of
org.apache.fulcrum.localization.LocalizationService into object
2018-04-01 11:17:11,168 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Looking up service
for injection: org.apache.fulcrum.intake.IntakeService for object
2018-04-01 11:17:11,168 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Injection of
org.apache.fulcrum.intake.IntakeService into object
2018-04-01 11:17:11,170 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Looking up service
for injection: SecurityService for object
2018-04-01 11:17:11,170 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Injection of
SecurityService into object
2018-04-01 11:17:11,170 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Injection of
2018-04-01 11:17:11,170 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.services.pull.TurbinePullService - Adding
sessionData
2018-04-01 11:17:11,172 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.services.template.mapper.LayoutTemplateMapper -
doMapping(Login.vm)
2018-04-01 11:17:11,172 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.services.template.mapper.LayoutTemplateMapper -
templateName is Login.vm
2018-04-01 11:17:11,172 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.services.template.mapper.LayoutTemplateMapper -
2018-04-01 11:17:11,172 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.services.template.mapper.LayoutTemplateMapper -
Looking for layouts/Login.vm
2018-04-01 11:17:11,172 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.services.template.mapper.LayoutTemplateMapper -
2018-04-01 11:17:11,172 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.services.template.mapper.LayoutTemplateMapper -
Looking for layouts/Default.vm
2018-04-01 11:17:11,172 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.services.template.mapper.LayoutTemplateMapper -
Found it, returning Default.vm
2018-04-01 11:17:11,172 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.services.template.mapper.ClassMapper -
doMapping(Login.vm)
2018-04-01 11:17:11,172 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.services.template.mapper.ClassMapper - className is
Login.vm
2018-04-01 11:17:11,172 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.services.template.mapper.ClassMapper - classPackage
2018-04-01 11:17:11,172 [ajp-nio-8009-exec-64] DEBUG
org.apache.turbine.services.template.mapper.ClassMapper - Looking for Login
.
.
.
etc...
I am wondering if there is something I may have configured wrong in
the lifecycle of my FluxTool code. I am using the same as what I had
put on github, so Georg, if you have had a chance to look at it, do
you see anything wrong with how I set it up?
https://github.com/jlpainter/turbine-flux/blob/master/src/main/flux/org/apache/turbine/flux/tools/FluxTool.java
#
# Custom tools
#
tool.request.flux=com.jivecast.smarttext.flux.tools.FluxTool
--
Jeffery

Post by Thomas Vandahl
Hi Jeffery,

---------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@turbine.apache.org
For additional commands, e-mail: dev-***@turbine.apache.org

Thomas Vandahl

2018-04-03 06:44:27 UTC

Permalink

Hi Jeffery,

Post by Jeffery Painter
I suspect the problem was with the lifecycle of the FluxTool I had built
for the turbine-webapp - I just pushed a change to the SVN repo (modeled
it more closely after the Intake tool's dispose lifecycle). I will test
a couple more days and see if this fixes the stalling bug I have been
seeing.

Especially when service injection is used extensively, it is important
to set module.cache=true in TR.props. It looks like the following

Post by Jeffery Painter

Post by Jeffery Painter
2018-03-31 21:20:43,037 [http-nio-8080-exec-70] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Looking up service
for injection: org.apache.fulcrum.localization.LocalizationService for
2018-03-31 21:20:43,037 [http-nio-8080-exec-70] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Injection of
org.apache.fulcrum.localization.LocalizationService into object
2018-03-31 21:20:43,037 [http-nio-8080-exec-70] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Looking up service
for injection: org.apache.fulcrum.intake.IntakeService for object
2018-03-31 21:20:43,037 [http-nio-8080-exec-70] DEBUG
org.apache.turbine.annotation.AnnotationProcessor - Injection of
org.apache.fulcrum.intake.IntakeService into object

This may help with lifecycle issues, too.

Bye, Thomas.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@turbine.apache.org
For additional commands, e-mail: dev-***@turbine.apache.org

Jeffery Painter

2018-04-04 15:32:27 UTC

Permalink

Hi Thomas,

Updated test code has been running 2 days with the patch to the flux
tool and no more stalls. I will make sure to turn on caching before
deploying to production :-)

Thanks for your help!

--
Jeffery

Post by Thomas Vandahl
Hi Jeffery,

Especially when service injection is used extensively, it is important
to set module.cache=true in TR.props. It looks like the following

Post by Jeffery Painter

This may help with lifecycle issues, too.
Bye, Thomas.
---------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@turbine.apache.org
For additional commands, e-mail: dev-***@turbine.apache.org

Georg Kallidis

2018-05-14 09:47:32 UTC

Permalink

Hi all,

As I am in the process to get a GIT clone for Turbine webapp repo, cft.
INFRA-16437 and reading the last comment

https://issues.apache.org/jira/browse/INFRA-16437?focusedCommentId=16472623&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16472623

we might consider to migrate Turbine Webapp as a _writeable_ GIT repo to
apache gitbox! (gitbox.apache.org = "GitHub Dual Master", not Git Wip,
although only the latter is mentioned in
https://www.apache.org/dev/writable-git). I think gitbox is just more
git-centric, the release is done completely with git. Dind one example
discussion here:
https://mail-archives.apache.org/mod_mbox/infra-issues/201804.mbox/%***@Atlassian.JIRA%3E

This is just implemented as a self service, i.e. we could do this ourself
(at one point of time), but we are completely free to do it as we like it
(IMO), even as a SVN backed GIT, cft.
https://wiki.apache.org/general/GitAtApache, which might not be the
recommended way IMO.

I would suggest to start with cloning/importing (not the main project)
just the svn repo

https://svn.apache.org/repos/asf/turbine/maven/archetypes to the gitbox as
turbine-archetypes-git.

The GitHub - Connection could then be done at any time later as far as I
can see.

We may decide to do it before the next release to perform a git release
(@Jeffery)?

Before more time is wasted, I would like to do this as a vote (procedural
type, i.e. majority vote would apply).

[ ] +1 yes, start using gitbox in general, start the migration to a
writeable git repo with one svn repo (turbine archetypes or another one),
connect to github and check using more github features, use this feature
optionally for more git repos, if needed.
[ ] 0 don't care
[ ] -1 no, because.

If there are any further compatible/consistent suggestions and they match
the general direction, I would just continue the process.

Thanks and...

Best regards, Georg

Georg Kallidis

2018-05-14 09:48:32 UTC

Permalink

[x] +1 yes, start using gitbox in general, start the migration to a
writeable git repo with one svn repo (turbine archetypes or another one),
connect to github and check using more github features, use this feature
optionally for more git repos, if needed.
[ ] 0 don't care
[ ] -1 no, because

-Georg

Von: "Georg Kallidis" <***@cedis.fu-berlin.de>
An: "Turbine Developers List" <***@turbine.apache.org>
Kopie: ***@turbine.apache.org
Datum: 14.05.2018 11:47
Betreff: [VOTE][GIT] Use (writable) gitbox, start with for Turbine
Archetypes

Hi all,

As I am in the process to get a GIT clone for Turbine webapp repo, cft.
INFRA-16437 and reading the last comment

https://issues.apache.org/jira/browse/INFRA-16437?focusedCommentId=16472623&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16472623

we might consider to migrate Turbine Webapp as a _writeable_ GIT repo to
apache gitbox! (gitbox.apache.org = "GitHub Dual Master", not Git Wip,
although only the latter is mentioned in
https://www.apache.org/dev/writable-git). I think gitbox is just more
git-centric, the release is done completely with git. Dind one example
discussion here:
https://mail-archives.apache.org/mod_mbox/infra-issues/201804.mbox/%***@Atlassian.JIRA%3E

This is just implemented as a self service, i.e. we could do this ourself
(at one point of time), but we are completely free to do it as we like it
(IMO), even as a SVN backed GIT, cft.
https://wiki.apache.org/general/GitAtApache, which might not be the
recommended way IMO.

I would suggest to start with cloning/importing (not the main project)
just the svn repo

https://svn.apache.org/repos/asf/turbine/maven/archetypes to the gitbox as

turbine-archetypes-git.

The GitHub - Connection could then be done at any time later as far as I
can see.

We may decide to do it before the next release to perform a git release
(@Jeffery)?

Before more time is wasted, I would like to do this as a vote (procedural
type, i.e. majority vote would apply).

[ ] +1 yes, start using gitbox in general, start the migration to a
writeable git repo with one svn repo (turbine archetypes or another one),
connect to github and check using more github features, use this feature
optionally for more git repos, if needed.
[ ] 0 don't care
[ ] -1 no, because.

If there are any further compatible/consistent suggestions and they match
the general direction, I would just continue the process.

Thanks and...

Best regards, Georg

Jeffery Painter

2018-05-16 14:00:51 UTC

Permalink

Hi Georg,

Sorry I have been quiet on the list. I (thankfully) have a new
contract, so my time has been diverted for the next couple weeks.

[X] +1 yes, start using gitbox in general, start the migration to a
writeable git repo with one svn repo (turbine archetypes or another one),
connect to github and check using more github features, use this feature
optionally for more git repos, if needed.
[ ] 0 don't care
[ ] -1 no, because.

Adding to your vote! I hope to be free again soon to help out.

--
Jeff

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@turbine.apache.org
For additional commands, e-mail: dev-***@turbine.apache.org

Continue reading on narkive:

Search results for 'Turbine 4.0.1 seems to "stall" after long period' (Questions and Answers)

replies

How much wind...?

started 2006-07-26 04:13:55 UTC

society & culture

replies

Have you ever saved an abused or abandoned dog or cat??

started 2006-11-22 18:40:27 UTC

dogs

replies

How efficiency of a wind turbine is calculated?