[JBoss JIRA] (WFLY-12815) Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 - More than one context active for scope type javax.enterprise.context.SessionScoped
by NUNO GODINHO DE MATOS (Jira)
[ https://issues.redhat.com/browse/WFLY-12815?page=com.atlassian.jira.plugi... ]
NUNO GODINHO DE MATOS edited comment on WFLY-12815 at 7/28/20 9:03 AM:
-----------------------------------------------------------------------
Hi,
I would Just like to let you know I have dome some small modifications to a sample application to try to make it reproduce the issue discussed here.
Uploadd:
I have uploaded a log file Sample_App_To_reproduceBug_001_RollingFileAppender.7z from my C:\dev\appserver\wildfly\wildfly-13.0.0.Final\user_projects\domains\SampleApp_Postgres\log.
Where you can see the sample application can be used to make the issue happen.
I have also uploaded on a different zip, the 01_snippets_of_code_of_sample_app.7z the interesting parts of the code of the sample app to make the issue happen.
I am not uploading the full sample app because I would need to remove content from it... and there is not much point to it. The code uploaded there can easily be bundled into any WAR file.
The thing to remember is that for this issue, you want to change the standalone.xml to have the servlet container default looking like this:
servlet-container name="default" default-session-timeout="1"
this helps with reproduce the issue, since after 1 minute wildfly will kill of the session.
Having a breakpoint in:
web.wildfly12815.WFLY12815SessionListener.sessionDestroyed(HttpSessionEvent)
Also helps, since this will allow you to login several sessions and have the session destroyed stop in your breakpoint thus corrupting multiple threads.
Testing the patch:
I will now try to build weld core and check if with it the issue stops being reproducible.
I will probably not follow the instruction on doing a FULL scale replacement of the weld core.
I need to continue working with Wildfly 13 for now the way it is vanilla, to experience the same sort of issues of projects using wildfly 13.
So i want o be perfectly in control of what code gets changed or not in my installation...
What I believe I will do is to build the weld code, and then grab the specific classes you have modified in your pull request.
And they I will go the "hacker" way and extract the weld code from my wildfly 13 and sneak in their your new classes.
IF I am lucky they are still compatible and not significant changes have gone into those two files since widlfly 13.
If I am not lucky I would need to replaye the full weld core...
But I will do that as a last resort.
By the way yo get your pull request I actually needed to do:
git fetch origin refs/pull/2005/head:pull/2005
The command on the instruction above seemed to not work.
Many thanks
was (Author: nuno.godinhomatos):
Hi,
I would Just like to let you know I have dome some small modifications to a sample application to try to make it reproduce the issue discussed here.
Uploadd:
I have uploaded a log file Sample_App_To_reproduceBug_001_RollingFileAppender.7z from my C:\dev\appserver\wildfly\wildfly-13.0.0.Final\user_projects\domains\WM6Maint-3925_SampleApp_Postgres\log.
Where you can see the sample application can be used to make the issue happen.
I have also uploaded on a different zip, the 01_snippets_of_code_of_sample_app.7z the interesting parts of the code of the sample app to make the issue happen.
I am not uploading the full sample app because I would need to remove content from it... and there is not much point to it. The code uploaded there can easily be bundled into any WAR file.
The thing to remember is that for this issue, you want to change the standalone.xml to have the servlet container default looking like this:
servlet-container name="default" default-session-timeout="1"
this helps with reproduce the issue, since after 1 minute wildfly will kill of the session.
Having a breakpoint in:
web.wildfly12815.WFLY12815SessionListener.sessionDestroyed(HttpSessionEvent)
Also helps, since this will allow you to login several sessions and have the session destroyed stop in your breakpoint thus corrupting multiple threads.
Testing the patch:
I will now try to build weld core and check if with it the issue stops being reproducible.
I will probably not follow the instruction on doing a FULL scale replacement of the weld core.
I need to continue working with Wildfly 13 for now the way it is vanilla, to experience the same sort of issues of projects using wildfly 13.
So i want o be perfectly in control of what code gets changed or not in my installation...
What I believe I will do is to build the weld code, and then grab the specific classes you have modified in your pull request.
And they I will go the "hacker" way and extract the weld code from my wildfly 13 and sneak in their your new classes.
IF I am lucky they are still compatible and not significant changes have gone into those two files since widlfly 13.
If I am not lucky I would need to replaye the full weld core...
But I will do that as a last resort.
By the way yo get your pull request I actually needed to do:
git fetch origin refs/pull/2005/head:pull/2005
The command on the instruction above seemed to not work.
Many thanks
> Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 - More than one context active for scope type javax.enterprise.context.SessionScoped
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-12815
> URL: https://issues.redhat.com/browse/WFLY-12815
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 13.0.0.Final
> Environment: Environment independent the issue, it is purely a logical problem
> Reporter: NUNO GODINHO DE MATOS
> Assignee: Matěj Novotný
> Priority: Major
> Attachments: 01_snippets_of_code_of_sample_app.7z, Sample_App_To_reproduceBug_001_RollingFileAppender.7z, sourceCodeToSendToWildfly.7z
>
>
> The full description of the problem can be seen in stack overflow.
> Please consulder the issue:
> https://stackoverflow.com/questions/58930939/wildflt-13-weld-001304-more-...
> SUMMARY:
> (1) Setup you wildfly to have a session timeout of 1 minute - so that you can esaily make your http sessions timeout
> (2) Program in your WAR application a sessionDestroyed listener that will be broken.
> In our case whenever the session is timing out, we have some code that explodes in wildfly and not in weblogic because it expected for the RequestScope context to be active, but apparently in wildfly when Undertow to start killing of a session the request scope context is not made active so that caused our session destroyed handling to break
> (3) Do this sufficient amount of times to corrupted as may threads in the thread pool as possible
> (4) Now try to interact with your application making use of some session scoped beans .
> If you travel to ay sort of view that makes use of a session scoped bean that thread will be broken with the exception that multiple session scope context implementation are active.
> But this exception will only come out and aply if the thread handling the HTTP request is one of the threads that in the past were used by undertow to handle the session timeout.
> The only threads that have been corrupted forever are those that had a broken sessin timeout
> Explanation for the issue:
> - When the session timeout is being orchestrated by underdow, wildfly is activating a special HttpSessionDescrutionContext and making it active.
> This ACTIVE TRUE/FALSE flag is a ThreadLocal variable.
> So the activation of the scope context is marked on the thread itself.
> - When the thread blows up the thread context will remain for as long at the thread lives
> - in a future request the flag had that thread local variable active already.
> So when the BeanManagaerImpl is hunting to the one and only active http session context it finds the traditional happy path http session context active plust the DestructionSession context that was activated in a previous call.
> All of the illustrative stack traces that facilitate the comprehention of the issue are shown in the stack overflow thread.
> I am of the oppinion that errors like this can happen in the deployed applications.
> It would not hurt if wildfly would somehow be able to ensure that the thread that hand an explosion in a previous request is not corrupted when it is used to handle new requests.
> Many thanks for having a look.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFLY-12815) Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 - More than one context active for scope type javax.enterprise.context.SessionScoped
by NUNO GODINHO DE MATOS (Jira)
[ https://issues.redhat.com/browse/WFLY-12815?page=com.atlassian.jira.plugi... ]
NUNO GODINHO DE MATOS commented on WFLY-12815:
----------------------------------------------
Hi,
Hi,
I would Just like to let you know I have dome some small modifications to a sample application to try to make it reproduce the issue discussed here.
Uploadd:
I have uploaded a log file Sample_App_To_reproduceBug_001_RollingFileAppender.7z from my C:\dev\appserver\wildfly\wildfly-13.0.0.Final\user_projects\domains\WM6Maint-3925_SampleApp_Postgres\log.
Where you can see the sample application can be used to make the issue happen.
I have also uploaded on a different zip, the 01_snippets_of_code_of_sample_app.7z the interesting parts of the code of the sample app to make the issue happen.
I am not uploading the full sample app because I would need to remove content from it... and there is not much point to it. The code uploaded there can easily be bundled into any WAR file.
The thing to remember is that for this issue, you want to change the standalone.xml to have the servlet container default looking like this:
servlet-container name="default" default-session-timeout="1"
this helps with reproduce the issue, since after 1 minute wildfly will kill of the session.
Having a breakpoint in:
web.wildfly12815.WFLY12815SessionListener.sessionDestroyed(HttpSessionEvent)
Also helps, since this will allow you to login several sessions and have the session destroyed stop in your breakpoint thus corrupting multiple threads.
Testing the patch:
I will now try to build weld core and check if with it the issue stops being reproducible.
I will probably not follow the instruction on doing a FULL scale replacement of the weld core.
I need to continue working with Wildfly 13 for now the way it is vanilla, to experience the same sort of issues of projects using wildfly 13.
So i want o be perfectly in control of what code gets changed or not in my installation...
What I believe I will do is to build the weld code, and then grab the specific classes you have modified in your pull request.
And they I will go the "hacker" way and extract the weld code from my wildfly 13 and sneak in their your new classes.
IF I am lucky they are still compatible and not significant changes have gone into those two files since widlfly 13.
If I am not lucky I would need to replaye the full weld core...
But I will do that as a last resort.
By the way yo get your pull request I actually needed to do:
git fetch origin refs/pull/2005/head:pull/2005
The command on the instruction above seemed to not work.
Many thanks
> Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 - More than one context active for scope type javax.enterprise.context.SessionScoped
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-12815
> URL: https://issues.redhat.com/browse/WFLY-12815
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 13.0.0.Final
> Environment: Environment independent the issue, it is purely a logical problem
> Reporter: NUNO GODINHO DE MATOS
> Assignee: Matěj Novotný
> Priority: Major
> Attachments: 01_snippets_of_code_of_sample_app.7z, Sample_App_To_reproduceBug_001_RollingFileAppender.7z, sourceCodeToSendToWildfly.7z
>
>
> The full description of the problem can be seen in stack overflow.
> Please consulder the issue:
> https://stackoverflow.com/questions/58930939/wildflt-13-weld-001304-more-...
> SUMMARY:
> (1) Setup you wildfly to have a session timeout of 1 minute - so that you can esaily make your http sessions timeout
> (2) Program in your WAR application a sessionDestroyed listener that will be broken.
> In our case whenever the session is timing out, we have some code that explodes in wildfly and not in weblogic because it expected for the RequestScope context to be active, but apparently in wildfly when Undertow to start killing of a session the request scope context is not made active so that caused our session destroyed handling to break
> (3) Do this sufficient amount of times to corrupted as may threads in the thread pool as possible
> (4) Now try to interact with your application making use of some session scoped beans .
> If you travel to ay sort of view that makes use of a session scoped bean that thread will be broken with the exception that multiple session scope context implementation are active.
> But this exception will only come out and aply if the thread handling the HTTP request is one of the threads that in the past were used by undertow to handle the session timeout.
> The only threads that have been corrupted forever are those that had a broken sessin timeout
> Explanation for the issue:
> - When the session timeout is being orchestrated by underdow, wildfly is activating a special HttpSessionDescrutionContext and making it active.
> This ACTIVE TRUE/FALSE flag is a ThreadLocal variable.
> So the activation of the scope context is marked on the thread itself.
> - When the thread blows up the thread context will remain for as long at the thread lives
> - in a future request the flag had that thread local variable active already.
> So when the BeanManagaerImpl is hunting to the one and only active http session context it finds the traditional happy path http session context active plust the DestructionSession context that was activated in a previous call.
> All of the illustrative stack traces that facilitate the comprehention of the issue are shown in the stack overflow thread.
> I am of the oppinion that errors like this can happen in the deployed applications.
> It would not hurt if wildfly would somehow be able to ensure that the thread that hand an explosion in a previous request is not corrupted when it is used to handle new requests.
> Many thanks for having a look.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFLY-12815) Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 - More than one context active for scope type javax.enterprise.context.SessionScoped
by NUNO GODINHO DE MATOS (Jira)
[ https://issues.redhat.com/browse/WFLY-12815?page=com.atlassian.jira.plugi... ]
NUNO GODINHO DE MATOS edited comment on WFLY-12815 at 7/28/20 9:02 AM:
-----------------------------------------------------------------------
Hi,
I would Just like to let you know I have dome some small modifications to a sample application to try to make it reproduce the issue discussed here.
Uploadd:
I have uploaded a log file Sample_App_To_reproduceBug_001_RollingFileAppender.7z from my C:\dev\appserver\wildfly\wildfly-13.0.0.Final\user_projects\domains\WM6Maint-3925_SampleApp_Postgres\log.
Where you can see the sample application can be used to make the issue happen.
I have also uploaded on a different zip, the 01_snippets_of_code_of_sample_app.7z the interesting parts of the code of the sample app to make the issue happen.
I am not uploading the full sample app because I would need to remove content from it... and there is not much point to it. The code uploaded there can easily be bundled into any WAR file.
The thing to remember is that for this issue, you want to change the standalone.xml to have the servlet container default looking like this:
servlet-container name="default" default-session-timeout="1"
this helps with reproduce the issue, since after 1 minute wildfly will kill of the session.
Having a breakpoint in:
web.wildfly12815.WFLY12815SessionListener.sessionDestroyed(HttpSessionEvent)
Also helps, since this will allow you to login several sessions and have the session destroyed stop in your breakpoint thus corrupting multiple threads.
Testing the patch:
I will now try to build weld core and check if with it the issue stops being reproducible.
I will probably not follow the instruction on doing a FULL scale replacement of the weld core.
I need to continue working with Wildfly 13 for now the way it is vanilla, to experience the same sort of issues of projects using wildfly 13.
So i want o be perfectly in control of what code gets changed or not in my installation...
What I believe I will do is to build the weld code, and then grab the specific classes you have modified in your pull request.
And they I will go the "hacker" way and extract the weld code from my wildfly 13 and sneak in their your new classes.
IF I am lucky they are still compatible and not significant changes have gone into those two files since widlfly 13.
If I am not lucky I would need to replaye the full weld core...
But I will do that as a last resort.
By the way yo get your pull request I actually needed to do:
git fetch origin refs/pull/2005/head:pull/2005
The command on the instruction above seemed to not work.
Many thanks
was (Author: nuno.godinhomatos):
Hi,
Hi,
I would Just like to let you know I have dome some small modifications to a sample application to try to make it reproduce the issue discussed here.
Uploadd:
I have uploaded a log file Sample_App_To_reproduceBug_001_RollingFileAppender.7z from my C:\dev\appserver\wildfly\wildfly-13.0.0.Final\user_projects\domains\WM6Maint-3925_SampleApp_Postgres\log.
Where you can see the sample application can be used to make the issue happen.
I have also uploaded on a different zip, the 01_snippets_of_code_of_sample_app.7z the interesting parts of the code of the sample app to make the issue happen.
I am not uploading the full sample app because I would need to remove content from it... and there is not much point to it. The code uploaded there can easily be bundled into any WAR file.
The thing to remember is that for this issue, you want to change the standalone.xml to have the servlet container default looking like this:
servlet-container name="default" default-session-timeout="1"
this helps with reproduce the issue, since after 1 minute wildfly will kill of the session.
Having a breakpoint in:
web.wildfly12815.WFLY12815SessionListener.sessionDestroyed(HttpSessionEvent)
Also helps, since this will allow you to login several sessions and have the session destroyed stop in your breakpoint thus corrupting multiple threads.
Testing the patch:
I will now try to build weld core and check if with it the issue stops being reproducible.
I will probably not follow the instruction on doing a FULL scale replacement of the weld core.
I need to continue working with Wildfly 13 for now the way it is vanilla, to experience the same sort of issues of projects using wildfly 13.
So i want o be perfectly in control of what code gets changed or not in my installation...
What I believe I will do is to build the weld code, and then grab the specific classes you have modified in your pull request.
And they I will go the "hacker" way and extract the weld code from my wildfly 13 and sneak in their your new classes.
IF I am lucky they are still compatible and not significant changes have gone into those two files since widlfly 13.
If I am not lucky I would need to replaye the full weld core...
But I will do that as a last resort.
By the way yo get your pull request I actually needed to do:
git fetch origin refs/pull/2005/head:pull/2005
The command on the instruction above seemed to not work.
Many thanks
> Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 - More than one context active for scope type javax.enterprise.context.SessionScoped
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-12815
> URL: https://issues.redhat.com/browse/WFLY-12815
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 13.0.0.Final
> Environment: Environment independent the issue, it is purely a logical problem
> Reporter: NUNO GODINHO DE MATOS
> Assignee: Matěj Novotný
> Priority: Major
> Attachments: 01_snippets_of_code_of_sample_app.7z, Sample_App_To_reproduceBug_001_RollingFileAppender.7z, sourceCodeToSendToWildfly.7z
>
>
> The full description of the problem can be seen in stack overflow.
> Please consulder the issue:
> https://stackoverflow.com/questions/58930939/wildflt-13-weld-001304-more-...
> SUMMARY:
> (1) Setup you wildfly to have a session timeout of 1 minute - so that you can esaily make your http sessions timeout
> (2) Program in your WAR application a sessionDestroyed listener that will be broken.
> In our case whenever the session is timing out, we have some code that explodes in wildfly and not in weblogic because it expected for the RequestScope context to be active, but apparently in wildfly when Undertow to start killing of a session the request scope context is not made active so that caused our session destroyed handling to break
> (3) Do this sufficient amount of times to corrupted as may threads in the thread pool as possible
> (4) Now try to interact with your application making use of some session scoped beans .
> If you travel to ay sort of view that makes use of a session scoped bean that thread will be broken with the exception that multiple session scope context implementation are active.
> But this exception will only come out and aply if the thread handling the HTTP request is one of the threads that in the past were used by undertow to handle the session timeout.
> The only threads that have been corrupted forever are those that had a broken sessin timeout
> Explanation for the issue:
> - When the session timeout is being orchestrated by underdow, wildfly is activating a special HttpSessionDescrutionContext and making it active.
> This ACTIVE TRUE/FALSE flag is a ThreadLocal variable.
> So the activation of the scope context is marked on the thread itself.
> - When the thread blows up the thread context will remain for as long at the thread lives
> - in a future request the flag had that thread local variable active already.
> So when the BeanManagaerImpl is hunting to the one and only active http session context it finds the traditional happy path http session context active plust the DestructionSession context that was activated in a previous call.
> All of the illustrative stack traces that facilitate the comprehention of the issue are shown in the stack overflow thread.
> I am of the oppinion that errors like this can happen in the deployed applications.
> It would not hurt if wildfly would somehow be able to ensure that the thread that hand an explosion in a previous request is not corrupted when it is used to handle new requests.
> Many thanks for having a look.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFCORE-5067) Wildfly as Windows Service fails to stop in a timely fashion
by Cedric HENRY (Jira)
[ https://issues.redhat.com/browse/WFCORE-5067?page=com.atlassian.jira.plug... ]
Cedric HENRY edited comment on WFCORE-5067 at 7/28/20 9:02 AM:
---------------------------------------------------------------
While further investigating the issue in matter after documenting my assumption in the [comment mentioned in the description|https://issues.redhat.com/browse/WFCORE-1719?focusedCommentId...], I have discovered in the _wildfly-stderr.2020-07-28.log_ file from server the following message:
{noformat}
2020-07-28 13:03:48 Commons Daemon procrun stderr initialized
" was unexpected at this time.{noformat}
which matches an attempt in stopping the Wildfly windows service.
Hence, I have looked into _service.bat_ (under _%JBOSS_HOME%\bin\service_) and I have observed the difference of formatting between STARTPARAM and STOPPARAM, as well as the [PROCRUN|https://commons.apache.org/proper/commons-daemon/procrun.html] documentation, and the fact _jboss-cli.bat_ is apparently not called on service stop...
Looking into this, I have worked out a solution tested on the standalone configuration with WIldfly 10.1.0.Final.
h2. The Solution
STOPPARAM must not use the " character (as mentioned in the error message above), thus shall be formatted otherwise
* *For Standalone Configuration:*
On line 475 of the service.bat script
{code:java}
set STOPPARAM=/c#!STOP_SCRIPT!#--controller=%CONTROLLER%#--connect#--command=:shutdown%CREDENTIALS%
{code}
* *For Domain Configuration:*
On line 469 of the service.bat script (not tested though)
{code:java}
set STOPPARAM=/c#%STOP_SCRIPT%#--controller=%CONTROLLER%#--connect#--command=/host=!DC_HOST!:shutdown%CREDENTIALS%{code}
*Note* that this implies having {{CREDENTIALS}} formatted as follow when set (line 444):
{code:java}
CREDENTIALS=#--user=%JBOSSUSER%#--password=%JBOSSPASS%{code}
Once this is applied and Wildfly is re-installed as a Windows Service, everything works like a charm.
was (Author: cedric-henry):
While further investigating the issue in matter after documenting my assumption in the [comment mentioned in the description|https://issues.redhat.com/browse/WFCORE-1719?focusedCommentId...], I have discovered in the _wildfly-stderr.2020-07-28.log_ file from server the following message:
{noformat}
2020-07-28 13:03:48 Commons Daemon procrun stderr initialized
" was unexpected at this time.{noformat}
which matches an attempt in stopping the Wildfly windows service.
Hence, I have looked into _service.bat_ (under _%JBOSS_HOME%\bin\service_) and I have observed the difference of formatting between STARTPARAM and STOPPARAM, as well as the [PROCRUN|https://commons.apache.org/proper/commons-daemon/procrun.html] documentation, and the fact _jboss-cli.bat_ is apparently not called on service stop...
Looking into this, I have worked out a solution tested on the standalone configuration with WIldfly 10.1.0.Final.
h2. The Solution
STOPPARAM must not use the " character (as mentioned in the error message above), thus shall be formatted otherwise
* *For Standalone Configuration:*
On line 475 of the service.bat script
{code:java}
set STOPPARAM=/c#!STOP_SCRIPT!#--controller=%CONTROLLER%#--connect#--command=:shutdown%CREDENTIALS%
{code}
* *For Domain Configuration:*
On line 469 of the service.bat script (not tested though)
{code:java}
set STOPPARAM=/c#%STOP_SCRIPT%#--controller=%CONTROLLER%#--connect#--command=/host=!DC_HOST!:shutdown%CREDENTIALS%{code}
*Note* that this implies having {{CREDENTIALS}} formatted as follow when set (line 444):
{code:java}
CREDENTIALS=#--user=%JBOSSUSER%#--password=%JBOSSPASS%{code}
Once this is applied and Wildfly is re-installed as a Windows Service, everything works like a charm.
> Wildfly as Windows Service fails to stop in a timely fashion
> ------------------------------------------------------------
>
> Key: WFCORE-5067
> URL: https://issues.redhat.com/browse/WFCORE-5067
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Cedric HENRY
> Assignee: Jeff Mesnil
> Priority: Major
>
> As already discussed under WFCORE-1719, there a problem when stopping the 'Wildfly' Windows service resulting in error dialog about the service not stopping in a timely fashion.
> Further details got also provided in the comment https://issues.redhat.com/browse/WFCORE-1719?focusedCommentId=143...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFCORE-5067) Wildfly as Windows Service fails to stop in a timely fashion
by Cedric HENRY (Jira)
[ https://issues.redhat.com/browse/WFCORE-5067?page=com.atlassian.jira.plug... ]
Cedric HENRY edited comment on WFCORE-5067 at 7/28/20 9:01 AM:
---------------------------------------------------------------
While further investigating the issue in matter after documenting my assumption in the [comment mentioned in the description|https://issues.redhat.com/browse/WFCORE-1719?focusedCommentId...], I have discovered in the _wildfly-stderr.2020-07-28.log_ file from server the following message:
{noformat}
2020-07-28 13:03:48 Commons Daemon procrun stderr initialized
" was unexpected at this time.{noformat}
which matches an attempt in stopping the Wildfly windows service.
Hence, I have looked into _service.bat_ (under _%JBOSS_HOME%\bin\service_) and I have observed the difference of formatting between STARTPARAM and STOPPARAM, as well as the [PROCRUN|https://commons.apache.org/proper/commons-daemon/procrun.html] documentation, and the fact _jboss-cli.bat_ is apparently not called on service stop...
Looking into this, I have worked out a solution tested on the standalone configuration with WIldfly 10.1.0.Final.
h2. The Solution
STOPPARAM must not use the " character (as mentioned in the error message above), thus shall be formatted otherwise
* *For Standalone Configuration:*
On line 475 of the service.bat script
{code:java}
set STOPPARAM=/c#!STOP_SCRIPT!#--controller=%CONTROLLER%#--connect#--command=:shutdown%CREDENTIALS%
{code}
* *For Domain Configuration:*
On line 469 of the service.bat script (not tested though)
{code:java}
set STOPPARAM=/c#%STOP_SCRIPT%#--controller=%CONTROLLER%#--connect#--command=/host=!DC_HOST!:shutdown%CREDENTIALS%{code}
*Note* that this implies having {{CREDENTIALS}} formatted as follow when set (line 444):
{code:java}
CREDENTIALS=#--user=%JBOSSUSER%#--password=%JBOSSPASS%{code}
Once this is applied and Wildfly is re-installed as a Windows Service, everything works like a charm.
was (Author: cedric-henry):
While further investigating the issue in matter after documenting my assumption in the [comment mentioned in the description|https://issues.redhat.com/browse/WFCORE-1719?focusedCommentId...], I have discovered in the _wildfly-stderr.2020-07-28.log_ file from server the following message:
{noformat}
2020-07-28 13:03:48 Commons Daemon procrun stderr initialized
" was unexpected at this time.{noformat}
which matches an attempt in stopping the Wildfly windows service.
Hence, I have looked into _service.bat_ (under _%JBOSS_HOME%\bin\service_) and I have observed the difference of formatting between STARTPARAM and STOPPARAM, as well as the [PROCRUN|https://commons.apache.org/proper/commons-daemon/procrun.html] documentation, and the fact _jboss-cli.bat_ is apparently not called on service stop...
Looking into this, I have worked out a solution tested on the standalone configuration with WIldfly 10.1.0.Final.
h2. The Solution
STOPPARAM must not use the " character (as mentioned in the error message above), thus shall be formatted otherwise
* *For Standalone Configuration:*
On line 475 of the service.bat script
{code:java}
set STOPPARAM=/c#!STOP_SCRIPT!#--controller=%CONTROLLER%#--connect#--command=:shutdown%CREDENTIALS%
{code}
* *For Domain Configuration:*
On line 469 of the service.bat script (not tested though)
{code:java}
set STOPPARAM=/c#%STOP_SCRIPT%#--controller=%CONTROLLER%#--connect#--command=/host=!DC_HOST!:shutdown%CREDENTIALS%{code}
*Note* that this implies having {{CREDENTIALS}} formatted as follow when set (line 444):
{code:java}
CREDENTIALS=#--user=%JBOSSUSER%#--password=%JBOSSPASS%{code}
> Wildfly as Windows Service fails to stop in a timely fashion
> ------------------------------------------------------------
>
> Key: WFCORE-5067
> URL: https://issues.redhat.com/browse/WFCORE-5067
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Cedric HENRY
> Assignee: Jeff Mesnil
> Priority: Major
>
> As already discussed under WFCORE-1719, there a problem when stopping the 'Wildfly' Windows service resulting in error dialog about the service not stopping in a timely fashion.
> Further details got also provided in the comment https://issues.redhat.com/browse/WFCORE-1719?focusedCommentId=143...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFCORE-5067) Wildfly as Windows Service fails to stop in a timely fashion
by Cedric HENRY (Jira)
[ https://issues.redhat.com/browse/WFCORE-5067?page=com.atlassian.jira.plug... ]
Cedric HENRY edited comment on WFCORE-5067 at 7/28/20 8:53 AM:
---------------------------------------------------------------
While further investigating the issue in matter after documenting my assumption in the [comment mentioned in the description|https://issues.redhat.com/browse/WFCORE-1719?focusedCommentId...], I have discovered in the _wildfly-stderr.2020-07-28.log_ file from server the following message:
{noformat}
2020-07-28 13:03:48 Commons Daemon procrun stderr initialized
" was unexpected at this time.{noformat}
which matches an attempt in stopping the Wildfly windows service.
Hence, I have looked into _service.bat_ (under _%JBOSS_HOME%\bin\service_) and I have observed the difference of formatting between STARTPARAM and STOPPARAM, as well as the [PROCRUN|https://commons.apache.org/proper/commons-daemon/procrun.html] documentation, and the fact _jboss-cli.bat_ is apparently not called on service stop...
Looking into this, I have worked out a solution tested on the standalone configuration with WIldfly 10.1.0.Final.
h2. The Solution
STOPPARAM must not use the " character (as mentioned in the error message above), thus shall be formatted otherwise
* *For Standalone Configuration:*
On line 475 of the service.bat script
{code:java}
set STOPPARAM=/c#!STOP_SCRIPT!#--controller=%CONTROLLER%#--connect#--command=:shutdown%CREDENTIALS%
{code}
* *For Domain Configuration:*
On line 469 of the service.bat script (not tested though)
{code:java}
set STOPPARAM=/c#%STOP_SCRIPT%#--controller=%CONTROLLER%#--connect#--command=/host=!DC_HOST!:shutdown%CREDENTIALS%{code}
*Note* that this implies having {{CREDENTIALS}} formatted as follow when set (line 444):
{code:java}
CREDENTIALS=#--user=%JBOSSUSER%#--password=%JBOSSPASS%{code}
was (Author: cedric-henry):
While further investigating the issue in matter after documenting my assumption in the comment mentioned in the description, I have discovered in the _wildfly-stderr.2020-07-28.log_ file from server the following message:
{noformat}
2020-07-28 13:03:48 Commons Daemon procrun stderr initialized
" was unexpected at this time.{noformat}
which matches an attempt in stopping the Wildfly windows service.
Hence, I have looked into _service.bat_ (under _%JBOSS_HOME%\bin\service_) and I have observed the difference of formatting between STARTPARAM and STOPPARAM, as well as the [PROCRUN|https://commons.apache.org/proper/commons-daemon/procrun.html] documentation, and the fact _jboss-cli.bat_ is apparently not called on service stop...
Looking into this, I have worked out a solution tested on the standalone configuration with WIldfly 10.1.0.Final.
h2. The Solution
STOPPARAM must not use the " character (as mentioned in the error message above), thus shall be formatted otherwise
* *For Standalone Configuration:*
On line 475 of the service.bat script
{code:java}
set STOPPARAM=/c#!STOP_SCRIPT!#--controller=%CONTROLLER%#--connect#--command=:shutdown%CREDENTIALS%
{code}
* *For Domain Configuration:*
On line 469 of the service.bat script (not tested though)
{code:java}
set STOPPARAM=/c#%STOP_SCRIPT%#--controller=%CONTROLLER%#--connect#--command=/host=!DC_HOST!:shutdown%CREDENTIALS%{code}
*Note* that this implies having {{CREDENTIALS}} formatted as follow when set (line 444):
{code:java}
CREDENTIALS=#--user=%JBOSSUSER%#--password=%JBOSSPASS%{code}
> Wildfly as Windows Service fails to stop in a timely fashion
> ------------------------------------------------------------
>
> Key: WFCORE-5067
> URL: https://issues.redhat.com/browse/WFCORE-5067
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Cedric HENRY
> Assignee: Jeff Mesnil
> Priority: Major
>
> As already discussed under WFCORE-1719, there a problem when stopping the 'Wildfly' Windows service resulting in error dialog about the service not stopping in a timely fashion.
> Further details got also provided in the comment https://issues.redhat.com/browse/WFCORE-1719?focusedCommentId=143...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFCORE-5067) Wildfly as Windows Service fails to stop in a timely fashion
by Cedric HENRY (Jira)
[ https://issues.redhat.com/browse/WFCORE-5067?page=com.atlassian.jira.plug... ]
Cedric HENRY edited comment on WFCORE-5067 at 7/28/20 8:52 AM:
---------------------------------------------------------------
While further investigating the issue in matter after documenting my assumption in the comment mentioned in the description, I have discovered in the _wildfly-stderr.2020-07-28.log_ file from server the following message:
{noformat}
2020-07-28 13:03:48 Commons Daemon procrun stderr initialized
" was unexpected at this time.{noformat}
which matches an attempt in stopping the Wildfly windows service.
Hence, I have looked into _service.bat_ (under _%JBOSS_HOME%\bin\service_) and I have observed the difference of formatting between STARTPARAM and STOPPARAM, as well as the [PROCRUN|https://commons.apache.org/proper/commons-daemon/procrun.html] documentation, and the fact _jboss-cli.bat_ is apparently not called on service stop...
Looking into this, I have worked out a solution tested on the standalone configuration with WIldfly 10.1.0.Final.
h2. The Solution
STOPPARAM must not use the " character (as mentioned in the error message above), thus shall be formatted otherwise
* *For Standalone Configuration:*
On line 475 of the service.bat script
{code:java}
set STOPPARAM=/c#!STOP_SCRIPT!#--controller=%CONTROLLER%#--connect#--command=:shutdown%CREDENTIALS%
{code}
* *For Domain Configuration:*
On line 469 of the service.bat script (not tested though)
{code:java}
set STOPPARAM=/c#%STOP_SCRIPT%#--controller=%CONTROLLER%#--connect#--command=/host=!DC_HOST!:shutdown%CREDENTIALS%{code}
*Note* that this implies having {{CREDENTIALS}} formatted as follow when set (line 444):
{code:java}
CREDENTIALS=#--user=%JBOSSUSER%#--password=%JBOSSPASS%{code}
was (Author: cedric-henry):
While further investigating the issue in matter after the documenting my assumption in the comment mentioned in the description, I have discovered in the _wildfly-stderr.2020-07-28.log_ file from server the following message:
{noformat}
2020-07-28 13:03:48 Commons Daemon procrun stderr initialized
" was unexpected at this time.{noformat}
which matches an attempt in stopping the Wildfly windows service.
Hence, I have looked into _service.bat_ (under _%JBOSS_HOME%\bin\service_) and I have observed the difference of formatting between STARTPARAM and STOPPARAM, as well as the [PROCRUN|https://commons.apache.org/proper/commons-daemon/procrun.html] documentation, and the fact _jboss-cli.bat_ is apparently not called on service stop...
Looking into this, I have worked out a solution tested on the standalone configuration with WIldfly 10.1.0.Final.
h2. The Solution
STOPPARAM must not use the " character (as mentioned in the error message above), thus shall be formatted otherwise
* *For Standalone Configuration:*
On line 475 of the service.bat script
{code:java}
set STOPPARAM=/c#!STOP_SCRIPT!#--controller=%CONTROLLER%#--connect#--command=:shutdown%CREDENTIALS%
{code}
* *For Domain Configuration:*
On line 469 of the service.bat script (not tested though)
{code:java}
set STOPPARAM=/c#%STOP_SCRIPT%#--controller=%CONTROLLER%#--connect#--command=/host=!DC_HOST!:shutdown%CREDENTIALS%{code}
*Note* that this implies having {{CREDENTIALS}} formatted as follow when set (line 444):
{code:java}
CREDENTIALS=#--user=%JBOSSUSER%#--password=%JBOSSPASS%{code}
> Wildfly as Windows Service fails to stop in a timely fashion
> ------------------------------------------------------------
>
> Key: WFCORE-5067
> URL: https://issues.redhat.com/browse/WFCORE-5067
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Cedric HENRY
> Assignee: Jeff Mesnil
> Priority: Major
>
> As already discussed under WFCORE-1719, there a problem when stopping the 'Wildfly' Windows service resulting in error dialog about the service not stopping in a timely fashion.
> Further details got also provided in the comment https://issues.redhat.com/browse/WFCORE-1719?focusedCommentId=143...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFCORE-5067) Wildfly as Windows Service fails to stop in a timely fashion
by Cedric HENRY (Jira)
[ https://issues.redhat.com/browse/WFCORE-5067?page=com.atlassian.jira.plug... ]
Cedric HENRY edited comment on WFCORE-5067 at 7/28/20 8:50 AM:
---------------------------------------------------------------
While further investigating the issue in matter after the documenting my assumption in the comment mentioned in the description, I have discovered in the _wildfly-stderr.2020-07-28.log_ file from server the following message:
{noformat}
2020-07-28 13:03:48 Commons Daemon procrun stderr initialized
" was unexpected at this time.{noformat}
which matches an attempt in stopping the Wildfly windows service.
Hence, I have looked into _service.bat_ (under _%JBOSS_HOME%\bin\service_) and I have observed the difference of formatting between STARTPARAM and STOPPARAM, as well as the [PROCRUN|https://commons.apache.org/proper/commons-daemon/procrun.html] documentation, and the fact _jboss-cli.bat_ is apparently not called on service stop...
Looking into this, I have worked out a solution tested on the standalone configuration with WIldfly 10.1.0.Final.
h2. The Solution
STOPPARAM must not use the " character (as mentioned in the error message above), thus shall be formatted otherwise
* *For Standalone Configuration:*
On line 475 of the service.bat script
{code:java}
set STOPPARAM=/c#!STOP_SCRIPT!#--controller=%CONTROLLER%#--connect#--command=:shutdown%CREDENTIALS%
{code}
* *For Domain Configuration:*
On line 469 of the service.bat script (not tested though)
{code:java}
set STOPPARAM=/c#%STOP_SCRIPT%#--controller=%CONTROLLER%#--connect#--command=/host=!DC_HOST!:shutdown%CREDENTIALS%{code}
*Note* that this implies having {{CREDENTIALS}} formatted as follow when set (line 444):
{code:java}
CREDENTIALS=#--user=%JBOSSUSER%#--password=%JBOSSPASS%{code}
was (Author: cedric-henry):
While further investigating the issue in matter after the documenting my assumption in the comment mentioned in the description, I have discovered in the _wildfly-stderr.2020-07-28.log_ file from server the following message:
{noformat}
2020-07-28 13:03:48 Commons Daemon procrun stderr initialized
" was unexpected at this time.{noformat}
which matches an attempt in stopping the Wildfly windows service.
Hence, I have looked into _service.bat_ (under _%JBOSS_HOME%\bin\service_) and I have observed the difference of formatting between STARTPARAM and STOPPARAM, as well as the [PROCRUN|https://commons.apache.org/proper/commons-daemon/procrun.html] documentation, and the fact _jboss-cli.bat_ is apparently not called on service stop...
Looking into this, I have worked out a solution tested on the standalone configuration with WIldfly 10.1.0.Final.
h2. The Solution
STOPPARAM must not use the " character (as mentioned in the error message above), thus shall be formatted otherwise
* *For Standalone Configuration:*
On line 475 of the service.bat script
{code:java}
set STOPPARAM=/c#!STOP_SCRIPT!#--controller=%CONTROLLER%#--connect#--command=:shutdown%CREDENTIALS%
{code}
Note that this implies having {{CREDENTIALS}} formatted as follow when set (line 444):
{code:java}
CREDENTIALS=#--user=%JBOSSUSER%#--password=%JBOSSPASS%
{code}
* *For Domain Configuration:*
On line 469 of the service.bat script (not tested though)
{code:java}
set STOPPARAM=/c#%STOP_SCRIPT%#--controller=%CONTROLLER%#--connect#--command=/host=!DC_HOST!:shutdown%CREDENTIALS%{code}
> Wildfly as Windows Service fails to stop in a timely fashion
> ------------------------------------------------------------
>
> Key: WFCORE-5067
> URL: https://issues.redhat.com/browse/WFCORE-5067
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Cedric HENRY
> Assignee: Jeff Mesnil
> Priority: Major
>
> As already discussed under WFCORE-1719, there a problem when stopping the 'Wildfly' Windows service resulting in error dialog about the service not stopping in a timely fashion.
> Further details got also provided in the comment https://issues.redhat.com/browse/WFCORE-1719?focusedCommentId=143...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFLY-12815) Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 - More than one context active for scope type javax.enterprise.context.SessionScoped
by NUNO GODINHO DE MATOS (Jira)
[ https://issues.redhat.com/browse/WFLY-12815?page=com.atlassian.jira.plugi... ]
NUNO GODINHO DE MATOS updated WFLY-12815:
-----------------------------------------
Attachment: 01_snippets_of_code_of_sample_app.7z
> Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 - More than one context active for scope type javax.enterprise.context.SessionScoped
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-12815
> URL: https://issues.redhat.com/browse/WFLY-12815
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 13.0.0.Final
> Environment: Environment independent the issue, it is purely a logical problem
> Reporter: NUNO GODINHO DE MATOS
> Assignee: Matěj Novotný
> Priority: Major
> Attachments: 01_snippets_of_code_of_sample_app.7z, Sample_App_To_reproduceBug_001_RollingFileAppender.7z, sourceCodeToSendToWildfly.7z
>
>
> The full description of the problem can be seen in stack overflow.
> Please consulder the issue:
> https://stackoverflow.com/questions/58930939/wildflt-13-weld-001304-more-...
> SUMMARY:
> (1) Setup you wildfly to have a session timeout of 1 minute - so that you can esaily make your http sessions timeout
> (2) Program in your WAR application a sessionDestroyed listener that will be broken.
> In our case whenever the session is timing out, we have some code that explodes in wildfly and not in weblogic because it expected for the RequestScope context to be active, but apparently in wildfly when Undertow to start killing of a session the request scope context is not made active so that caused our session destroyed handling to break
> (3) Do this sufficient amount of times to corrupted as may threads in the thread pool as possible
> (4) Now try to interact with your application making use of some session scoped beans .
> If you travel to ay sort of view that makes use of a session scoped bean that thread will be broken with the exception that multiple session scope context implementation are active.
> But this exception will only come out and aply if the thread handling the HTTP request is one of the threads that in the past were used by undertow to handle the session timeout.
> The only threads that have been corrupted forever are those that had a broken sessin timeout
> Explanation for the issue:
> - When the session timeout is being orchestrated by underdow, wildfly is activating a special HttpSessionDescrutionContext and making it active.
> This ACTIVE TRUE/FALSE flag is a ThreadLocal variable.
> So the activation of the scope context is marked on the thread itself.
> - When the thread blows up the thread context will remain for as long at the thread lives
> - in a future request the flag had that thread local variable active already.
> So when the BeanManagaerImpl is hunting to the one and only active http session context it finds the traditional happy path http session context active plust the DestructionSession context that was activated in a previous call.
> All of the illustrative stack traces that facilitate the comprehention of the issue are shown in the stack overflow thread.
> I am of the oppinion that errors like this can happen in the deployed applications.
> It would not hurt if wildfly would somehow be able to ensure that the thread that hand an explosion in a previous request is not corrupted when it is used to handle new requests.
> Many thanks for having a look.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFCORE-5067) Wildfly as Windows Service fails to stop in a timely fashion
by Cedric HENRY (Jira)
[ https://issues.redhat.com/browse/WFCORE-5067?page=com.atlassian.jira.plug... ]
Cedric HENRY edited comment on WFCORE-5067 at 7/28/20 8:49 AM:
---------------------------------------------------------------
While further investigating the issue in matter after the documenting my assumption in the comment mentioned in the description, I have discovered in the _wildfly-stderr.2020-07-28.log_ file from server the following message:
{noformat}
2020-07-28 13:03:48 Commons Daemon procrun stderr initialized
" was unexpected at this time.{noformat}
which matches an attempt in stopping the Wildfly windows service.
Hence, I have looked into _service.bat_ (under _%JBOSS_HOME%\bin\service_) and I have observed the difference of formatting between STARTPARAM and STOPPARAM, as well as the [PROCRUN|https://commons.apache.org/proper/commons-daemon/procrun.html] documentation, and the fact _jboss-cli.bat_ is apparently not called on service stop...
Looking into this, I have worked out a solution tested on the standalone configuration with WIldfly 10.1.0.Final.
h2. The Solution
STOPPARAM must not use the " character (as mentioned in the error message above), thus shall be formatted otherwise
* *For Standalone Configuration:*
On line 475 of the service.bat script
{code:java}
set STOPPARAM=/c#!STOP_SCRIPT!#--controller=%CONTROLLER%#--connect#--command=:shutdown%CREDENTIALS%
{code}
Note that this implies having {{CREDENTIALS}} formatted as follow when set (line 444):
{code:java}
CREDENTIALS=#--user=%JBOSSUSER%#--password=%JBOSSPASS%
{code}
* *For Domain Configuration:*
On line 469 of the service.bat script (not tested though)
{code:java}
set STOPPARAM=/c#%STOP_SCRIPT%#--controller=%CONTROLLER%#--connect#--command=/host=!DC_HOST!:shutdown%CREDENTIALS%{code}
was (Author: cedric-henry):
While further investigating the issue in matter after the documenting my assumption in the comment mentioned in the description, I have discovered in the _wildfly-stderr.2020-07-28.log_ file from server the following message:
{noformat}
2020-07-28 13:03:48 Commons Daemon procrun stderr initialized
" was unexpected at this time.{noformat}
which matches an attempt in stopping the Wildfly windows service.
Hence, I have looked into _service.bat_ (under _%JBOSS_HOME%\bin\service_) and I have observed the difference of formatting between STARTPARAM and STOPPARAM, as well as the [PROCRUN|https://commons.apache.org/proper/commons-daemon/procrun.html] documentation, and the fact _jboss-cli.bat_ is apparently not called on service stop...
Looking into this, I have worked out a solution tested on the standalone configuration with WIldfly 10.1.0.Final.
h2. The Solution
STOPPARAM must not use the " character (as mentioned in the error message above), thus shall be formatted otherwise
* *For Standalone Configuration:*
On line 475 of the service.bat script
{code:java}
set STOPPARAM=/c#!STOP_SCRIPT!#--controller=%CONTROLLER%#--connect#--command=:shutdown(timeout=0)%CREDENTIALS%
{code}
Note that this implies having {{CREDENTIALS}} formatted as follow when set (line 444):
{code:java}
CREDENTIALS=#--user=%JBOSSUSER%#--password=%JBOSSPASS%
{code}
* *For Domain Configuration:*
On line 469 of the service.bat script (not tested though)
{code:java}
set STOPPARAM=/c#%STOP_SCRIPT%#--controller=%CONTROLLER%#--connect#--command=/host=!DC_HOST!:shutdown(timeout=0)%CREDENTIALS%{code}
> Wildfly as Windows Service fails to stop in a timely fashion
> ------------------------------------------------------------
>
> Key: WFCORE-5067
> URL: https://issues.redhat.com/browse/WFCORE-5067
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Cedric HENRY
> Assignee: Jeff Mesnil
> Priority: Major
>
> As already discussed under WFCORE-1719, there a problem when stopping the 'Wildfly' Windows service resulting in error dialog about the service not stopping in a timely fashion.
> Further details got also provided in the comment https://issues.redhat.com/browse/WFCORE-1719?focusedCommentId=143...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months