[JBoss JIRA] (AS7-6031) deploy directories not cleaned up
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6031?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on AS7-6031:
---------------------------------------
This sounds familiar; I believe it may be a duplicate. I commented on the other issue with some thoughts.
> deploy directories not cleaned up
> ---------------------------------
>
> Key: AS7-6031
> URL: https://issues.jboss.org/browse/AS7-6031
> Project: Application Server 7
> Issue Type: Bug
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Shaun Appleton
> Assignee: Bartosz Baranowski
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (AS7-5411) adding JSSE to a security domain with the CLI does not persist
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/AS7-5411?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar resolved AS7-5411.
------------------------------
Fix Version/s: 7.2.0.Alpha1
Resolution: Rejected
Problem is in CLI command and not in subsystem itself.
in provided command there is keystore set in {noformat}[{"url" => ...}]{noformat}
which means it is a list of objects and not a object.
proper command is:
{noformat}
/subsystem=security/security-domain=mydomain/jsse=classic:add(keystore={"url" => "${jboss.server.config.dir}/jboss.keystore","password" => "secret"})
{noformat}
> adding JSSE to a security domain with the CLI does not persist
> --------------------------------------------------------------
>
> Key: AS7-5411
> URL: https://issues.jboss.org/browse/AS7-5411
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Tom Fonteyne
> Assignee: Tomaz Cerar
> Fix For: 7.2.0.Alpha1
>
>
> Adding JSSE setting to a security domain works in-memory, but they are not written to the xml file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (AS7-5879) Eliminate imports of jboss-as-controller classes from arquillian modules
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/AS7-5879?page=com.atlassian.jira.plugin.s... ]
Bartosz Baranowski reassigned AS7-5879:
---------------------------------------
Assignee: Bartosz Baranowski
> Eliminate imports of jboss-as-controller classes from arquillian modules
> ------------------------------------------------------------------------
>
> Key: AS7-5879
> URL: https://issues.jboss.org/browse/AS7-5879
> Project: Application Server 7
> Issue Type: Task
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Brian Stansberry
> Assignee: Bartosz Baranowski
> Fix For: 7.2.0.CR1
>
>
> The arquillian modules have some imports of classes in the jboss-as-controller module in client-side classes. I've seen them in the ManagementClient classes; there may be others. Basically imports of string constants and some static utility methods.
> The controller module is a server side module and its classes should not leak out to client-side code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (AS7-6031) deploy directories not cleaned up
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/AS7-6031?page=com.atlassian.jira.plugin.s... ]
Bartosz Baranowski reassigned AS7-6031:
---------------------------------------
Assignee: Bartosz Baranowski
> deploy directories not cleaned up
> ---------------------------------
>
> Key: AS7-6031
> URL: https://issues.jboss.org/browse/AS7-6031
> Project: Application Server 7
> Issue Type: Bug
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Shaun Appleton
> Assignee: Bartosz Baranowski
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (JGRP-1553) TimeScheduler3
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1553?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1553:
--------------------------------
I actually ended up implementing TimeScheduler3. It uses a DelayQueue with tasks sorted according to execution time. TimeScheduler is much smaller (300 LOC) than TimeScheduler2 (650 LOC), much more elegant (no awkward referencing of runnables and wrapping done anymore) and much simpler.
I also added more tests to TimeSchedulerTest and TimeScheduler3 passes all.
I changed the default to use the new class (timer_type=new3 in TP).
> TimeScheduler3
> --------------
>
> Key: JGRP-1553
> URL: https://issues.jboss.org/browse/JGRP-1553
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> The current TimeScheduler2 class has a few deficiencies:
> - taskReady() should only set next-execution-time if its argument is less than next-execution-time
> - no_tasks: when setting this CAS, the result is only checked in 1 location, but not the other
> - Potential loss of task: when calling schedule() on an existing Entry (same execution time), and - before adding the task to Entry - Entry is removed by _run() as it was executed, then the newly added task will never get to run !
> - Simplification: instead of headMap(), just use firstEntry(), removeFirstEntry(). See pseudo code below.
> As a workaround, timer_type="old" will switch back to the previous default timer. The reason for TimeScheduler3 (versus changing TimeScheduler2) is that we can simply switch to the new impl by setting (a new) timer_type="new2". Should this have a bug, we can simply switch back to "new" or "old" (or "wheel".
> Over time, TimeScheduler2 will get removed.
> Pseudo code:
> * loop while has tasks
> ** get the first task
> ** if its time is less than the current time: execute it and remove it
> ** else block (on the next task or 10s) until an element is added
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years