[jira] [Commented] (SLING-3352) Expose OSGI configuration as JCR nodes
[ https://issues.apache.org/jira/browse/SLING-3352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13889309#comment-13889309 ] Marius Petria commented on SLING-3352: -- [~tripod], I am just restating your proposal to make sure I understand it correctly - have some kind of extension for jcr installer that can be configured with a factory and a path - enforce that objects of that factory can be installed only from that location (and also that from that location you can only install instances for that factory) - the advantage for that will be that we are reusing an already implemented syncing mechanism I see two small shortcomings of that: - the urls are not friendly, they have the fully qualified name of the factory and contain a lot of dots. We can probably fix that by designating another property to represent the name of the shadow node (for example property name). Implementing this might require some unexpected complications. - we are building this into the sling components directly, so we should first decide it is a valid use case in general. The custom syncronizer was targeted first at replication with the possibility of extending it. > Expose OSGI configuration as JCR nodes > -- > > Key: SLING-3352 > URL: https://issues.apache.org/jira/browse/SLING-3352 > Project: Sling > Issue Type: Improvement >Reporter: Marius Petria > Labels: replication > > We need a safe way to expose OSGI configuration via HTTP. > Requirements: > - all configs for a certain factory should be manageable > - they should have associated JCR nodes that contain the config properties > - only configs that are available through ConfigurationAdmin should be > available > - the HTTP urls should have friendly names > - (Optional) the implementation should be general enough to be used for other > configs other than replication if needed > For example: a configuration with name publish for > org.apache.sling.replication.agent.impl.ReplicationAgentServiceFactory > should be mapped to /etc/replication/agent/publish > Problems with current implementation of JCR nodes created by JCR installed: > - Configuration files are read and created from /apps/.../config or > /libs/.../config, and there is no easy way to determine which are active in > the ConfigurationAdmin > - There is no way to restrict a repository path to create only configuration > from a specified factory (making it unusable with relaxed ACLs) > - The url of a configuration is unfriendly (it contains the fully qualified > name of the factory) > - The node types are not homogenous making it hard to use in a client > application (some are nt:file, some are sling:OsgiConfig) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (SLING-3037) IllegalArgumentException in logback Logger
[ https://issues.apache.org/jira/browse/SLING-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-3037. Resolution: Fixed Updated the Logback version to 1.1.0 in http://svn.apache.org/r1563778. All test pass > IllegalArgumentException in logback Logger > -- > > Key: SLING-3037 > URL: https://issues.apache.org/jira/browse/SLING-3037 > Project: Sling > Issue Type: Bug > Components: Commons >Reporter: Bertrand Delacretaz >Assignee: Chetan Mehrotra > Fix For: Commons Log 4.0.0 > > Attachments: SLING-3037.patch > > > Since switching to logback in SLING-2024, a number of integration tests are > failing, typical stack trace: > java.lang.IllegalArgumentException: > For logger [apps.integration-test] child name > [apps.integration-test.srt$1378284549103 passed as parameter, may not include > '.' after index22 > at ch.qos.logback.classic.Logger.createChildByName(Logger.java:357) > at > ch.qos.logback.classic.LoggerContext.getLogger(LoggerContext.java:143) > at ch.qos.logback.classic.LoggerContext.getLogger(LoggerContext.java:45) > at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:253) > at > org.apache.sling.scripting.core.impl.DefaultSlingScript.verifySlingBindings(DefaultSlingScript.java:676) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (SLING-3341) [logback] Race condition in configuring Logback
[
https://issues.apache.org/jira/browse/SLING-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved SLING-3341.
Resolution: Fixed
issue has not surfaced/reported again post this fix. Current fixes looks
sufficient. Closing it for now
> [logback] Race condition in configuring Logback
> ---
>
> Key: SLING-3341
> URL: https://issues.apache.org/jira/browse/SLING-3341
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Affects Versions: Commons Log 4.0.0
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>
> Current way to configure Logback works like as below
> 1. Any change in config finally leads a call to
> org.apache.sling.commons.log.logback.internal.LogbackManager#configChanged
> 2. The config change is not done in concurrent way. A thread must acquire the
> {{resetLock}} to trigger Logback reset. If this lock cannot be acquired then
> it just sets a flag {{configChanged}} to true. The Logback reset job upon
> completion checks {{configChanged}} . if found to be true then it reschedules
> the job to load Logback again
> In current impl there is a small race condition where its possible that
> Logback reset job does not see the {{configChanged}} flag and hence Logback
> does not get reinitialized and is configured with stale config
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (SLING-3252) Remove checked in Logback related classes before 4.x release
[ https://issues.apache.org/jira/browse/SLING-3252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-3252. Resolution: Fixed All checked in Logback classes have been removed now. > Remove checked in Logback related classes before 4.x release > > > Key: SLING-3252 > URL: https://issues.apache.org/jira/browse/SLING-3252 > Project: Sling > Issue Type: Task > Components: Commons >Affects Versions: Commons Log 4.0.0 >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Blocker > Fix For: Commons Log 4.0.0 > > > Currently the Common Log bundle has checked in 2 Logback classes as a fix for > SLING-3037 and SLING-3049. These classes are under EPL and cannot be part of > released bundle > See http://sling.markmail.org/thread/ilixl3ebdd3hxxts -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[osgi] Using Inventory API in Commons Log
Hi, For SLING-3264 I was thinking to provide Inventory integration in Commons Logs. However the Commons Log bundle starts at level 1 while the Inventory bundle starts at Level 5. The log bundle would use the ServiceFactory approach to expose the Inventory service and would not have required dependency on Inventory API. So just wanted to confirm that would it be fine to depend on classes from a bundle which starts at later start level or not? Chetan Mehrotra
Re: [osgi] Using Inventory API in Commons Log
Hi Am 03.02.2014 um 09:41 schrieb Chetan Mehrotra : > Hi, > > For SLING-3264 I was thinking to provide Inventory integration in > Commons Logs. However the Commons Log bundle starts at level 1 while > the Inventory bundle starts at Level 5. The log bundle would use the > ServiceFactory approach to expose the Inventory service and would not > have required dependency on Inventory API. > > So just wanted to confirm that would it be fine to depend on classes > from a bundle which starts at later start level or not? Sure. This is what we are using ServiceFactory and dynamic/delayed import all over places. See for example the Configuration Admin binding the Apache Felix SCR bundle. So, what seems to boild down to kind of a best practice is to: * use ServiceFactory for optional services * use Import-Package with resolution:=optional to have static wiring if possible * use DynamicImport-Package to have dynamic wiring on-demand It is just very important to thouroughly test this to not get inadvertend ClassNotFoundExceptions, for example if the optional classes appear in the method signature of a required class (see the ResourceResolverActivator.getFeaures() method which returns Object to work around this issue). Regards Felix
Re: [osgi] Using Inventory API in Commons Log
Thanks for the clarification Felix! Just to confirm though ... if Inventory bundle is later patched/refreshed it would then lead to refresh of Commons Log bundle also. Would that mean framework would be bought down to level 1 and restarted again Chetan Mehrotra On Mon, Feb 3, 2014 at 2:21 PM, Felix Meschberger wrote: > Hi > > Am 03.02.2014 um 09:41 schrieb Chetan Mehrotra : > >> Hi, >> >> For SLING-3264 I was thinking to provide Inventory integration in >> Commons Logs. However the Commons Log bundle starts at level 1 while >> the Inventory bundle starts at Level 5. The log bundle would use the >> ServiceFactory approach to expose the Inventory service and would not >> have required dependency on Inventory API. >> >> So just wanted to confirm that would it be fine to depend on classes >> from a bundle which starts at later start level or not? > > Sure. This is what we are using ServiceFactory and dynamic/delayed import all > over places. See for example the Configuration Admin binding the Apache Felix > SCR bundle. > > So, what seems to boild down to kind of a best practice is to: > > * use ServiceFactory for optional services > * use Import-Package with resolution:=optional to have > static wiring if possible > * use DynamicImport-Package to have dynamic wiring > on-demand > > It is just very important to thouroughly test this to not get inadvertend > ClassNotFoundExceptions, for example if the optional classes appear in the > method signature of a required class (see the > ResourceResolverActivator.getFeaures() method which returns Object to work > around this issue). > > Regards > Felix
Re: [osgi] Using Inventory API in Commons Log
Hi Am 03.02.2014 um 10:03 schrieb Chetan Mehrotra : > Thanks for the clarification Felix! > > Just to confirm though ... if Inventory bundle is later > patched/refreshed it would then lead to refresh of Commons Log bundle > also. Yes > Would that mean framework would be bought down to level 1 and > restarted again no, but … all logging would be "disabled and would have to be reconfigured" if the commons log bundle is refreshed … So the question really is: what happens to the logger instances held by the bundles …. Regards Felix > Chetan Mehrotra > > > On Mon, Feb 3, 2014 at 2:21 PM, Felix Meschberger wrote: >> Hi >> >> Am 03.02.2014 um 09:41 schrieb Chetan Mehrotra : >> >>> Hi, >>> >>> For SLING-3264 I was thinking to provide Inventory integration in >>> Commons Logs. However the Commons Log bundle starts at level 1 while >>> the Inventory bundle starts at Level 5. The log bundle would use the >>> ServiceFactory approach to expose the Inventory service and would not >>> have required dependency on Inventory API. >>> >>> So just wanted to confirm that would it be fine to depend on classes >>> from a bundle which starts at later start level or not? >> >> Sure. This is what we are using ServiceFactory and dynamic/delayed import >> all over places. See for example the Configuration Admin binding the Apache >> Felix SCR bundle. >> >> So, what seems to boild down to kind of a best practice is to: >> >> * use ServiceFactory for optional services >> * use Import-Package with resolution:=optional to have >> static wiring if possible >> * use DynamicImport-Package to have dynamic wiring >> on-demand >> >> It is just very important to thouroughly test this to not get inadvertend >> ClassNotFoundExceptions, for example if the optional classes appear in the >> method signature of a required class (see the >> ResourceResolverActivator.getFeaures() method which returns Object to work >> around this issue). >> >> Regards >> Felix
Re: [osgi] Using Inventory API in Commons Log
On Mon, Feb 3, 2014 at 2:54 PM, Felix Meschberger wrote: > So the question really is: what happens to the logger instances held by the > bundles Before answering that I need to confirm would a new classloader be created for Commons Log upon package refresh? Probably yes then it that case existing Logger instances would be referring to old classloader. The other bundle would be bound to Sl4j API so they would not be refreshed but there logger instances would be referring to Logback provided classes. So one should probably avoid external dependency for a bundle like Commons Log? Chetan Mehrotra
Re: [osgi] Using Inventory API in Commons Log
Hi Am 03.02.2014 um 10:30 schrieb Chetan Mehrotra : > On Mon, Feb 3, 2014 at 2:54 PM, Felix Meschberger wrote: >> So the question really is: what happens to the logger instances held by the >> bundles > > Before answering that I need to confirm would a new classloader be > created for Commons Log upon package refresh? Probably yes then it > that case existing Logger instances would be referring to old > classloader. The other bundle would be bound to Sl4j API so they would > not be refreshed but there logger instances would be referring to > Logback provided classes. > > So one should probably avoid external dependency for a bundle like Commons > Log? Yes, that probably is the consequence and we should refrain from adding Inventory API binding — unless the commons log bundle exports the inventory API itself… On the other hand: considering both the Inventory and the Web Console API to be crucial, it might be conceivable to create API only bundles for these… Regards Felix > > Chetan Mehrotra
Re: [osgi] Using Inventory API in Commons Log
> Yes, that probably is the consequence and we should refrain from adding > Inventory API binding -- unless the commons log bundle exports the inventory > API itself Well I required Inventory API to expose the logback state in JSON format (not that strong requirement though). Currently WebConsole supports Configuration Printer which do not explicitly implement Inventory API i.e. it supports any class which provides a method like [1] with some service properties. However that mode looks like does not support json mode. If it can support that then there is no string need for using Inventory API public void printConfiguration(PrintWriter printWriter) Chetan Mehrotra On Mon, Feb 3, 2014 at 3:11 PM, Felix Meschberger wrote: > Hi > > Am 03.02.2014 um 10:30 schrieb Chetan Mehrotra : > >> On Mon, Feb 3, 2014 at 2:54 PM, Felix Meschberger wrote: >>> So the question really is: what happens to the logger instances held by the >>> bundles >> >> Before answering that I need to confirm would a new classloader be >> created for Commons Log upon package refresh? Probably yes then it >> that case existing Logger instances would be referring to old >> classloader. The other bundle would be bound to Sl4j API so they would >> not be refreshed but there logger instances would be referring to >> Logback provided classes. >> >> So one should probably avoid external dependency for a bundle like Commons >> Log? > > Yes, that probably is the consequence and we should refrain from adding > Inventory API binding -- unless the commons log bundle exports the inventory > API itself... > > On the other hand: considering both the Inventory and the Web Console API to > be crucial, it might be conceivable to create API only bundles for these... > > Regards > Felix > >> >> Chetan Mehrotra >
Re: buildbot failure in ASF Buildbot on sling-trunk
Hi, On Sat, Feb 1, 2014 at 1:13 PM, Amit.. Gupta. wrote: ... > org.apache.sling.models.it.RemoteIT Time elapsed: 60.52 sec <<< ERROR! > java.lang.AssertionError: Server not ready after 60 seconds, giving up ... I have increased that timeout in the build setup, details at SLING-3234 -Bertrand
[jira] [Commented] (SLING-3234) Sling buildbot continuous integration
[ https://issues.apache.org/jira/browse/SLING-3234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13889362#comment-13889362 ] Bertrand Delacretaz commented on SLING-3234: I have modified sling.conf (URL above) to set longer timeouts using -Dsling.testing.timeout.multiplier=4 for integration tests that use the Sling testing tools. That should fix the timeouts of the bundles/extensions/models/integration-tests module. > Sling buildbot continuous integration > - > > Key: SLING-3234 > URL: https://issues.apache.org/jira/browse/SLING-3234 > Project: Sling > Issue Type: Task > Components: Testing >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz > > Buildbot jobs have been setup for Sling in INFRA-6962; > * http://ci.apache.org/builders/sling-trunk (triggered by commits) > * http://ci.apache.org/builders/sling-trunk-oak (runs after sling-trunk) > We'll use this issue to keep track of changes related to this buildbot setup, > as we did with SLING-920 for our Jenkins builds. > I suggest marking issues that cause intermittent buildbot failures as > blockers for this issue, so that we can quickly check if failed builds are > due to known issues. > Builds can be started manually via IRC if needed, via #asftest. Talk to the > sling-bot there, start with "help force", "status" or "commands". > [1] > https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/projects/sling.conf -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (SLING-3363) Make Logback status part of Configuration Printer output
Chetan Mehrotra created SLING-3363: -- Summary: Make Logback status part of Configuration Printer output Key: SLING-3363 URL: https://issues.apache.org/jira/browse/SLING-3363 Project: Sling Issue Type: Improvement Components: Commons Affects Versions: Commons Log 4.0.0 Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Priority: Minor Sling Log Configuration Printer currently dump the content of various Log file as part of output. It would be good to have the Logback status also part of same output -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (SLING-3363) Make Logback status part of Configuration Printer output
[ https://issues.apache.org/jira/browse/SLING-3363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-3363. Resolution: Fixed Fix Version/s: Commons Log 4.0.0 Done with http://svn.apache.org/r1563820 > Make Logback status part of Configuration Printer output > > > Key: SLING-3363 > URL: https://issues.apache.org/jira/browse/SLING-3363 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: Commons Log 4.0.0 >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: Commons Log 4.0.0 > > > Sling Log Configuration Printer currently dump the content of various Log > file as part of output. It would be good to have the Logback status also part > of same output -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: [osgi] Using Inventory API in Commons Log
Hi Well, officially, ConfigurationPrinter does not support JSON, but you can write JSON as TXT output Regards Felix Am 03.02.2014 um 11:01 schrieb Chetan Mehrotra : >> Yes, that probably is the consequence and we should refrain from adding >> Inventory API binding -- unless the commons log bundle exports the inventory >> API itself > > Well I required Inventory API to expose the logback state in JSON > format (not that strong requirement though). Currently WebConsole > supports Configuration Printer which do not explicitly implement > Inventory API i.e. it supports any class which provides a method like > [1] with some service properties. However that mode looks like does > not support json mode. If it can support that then there is no string > need for using Inventory API > > public void printConfiguration(PrintWriter printWriter) > Chetan Mehrotra > > > On Mon, Feb 3, 2014 at 3:11 PM, Felix Meschberger wrote: >> Hi >> >> Am 03.02.2014 um 10:30 schrieb Chetan Mehrotra : >> >>> On Mon, Feb 3, 2014 at 2:54 PM, Felix Meschberger >>> wrote: So the question really is: what happens to the logger instances held by the bundles >>> >>> Before answering that I need to confirm would a new classloader be >>> created for Commons Log upon package refresh? Probably yes then it >>> that case existing Logger instances would be referring to old >>> classloader. The other bundle would be bound to Sl4j API so they would >>> not be refreshed but there logger instances would be referring to >>> Logback provided classes. >>> >>> So one should probably avoid external dependency for a bundle like Commons >>> Log? >> >> Yes, that probably is the consequence and we should refrain from adding >> Inventory API binding -- unless the commons log bundle exports the inventory >> API itself... >> >> On the other hand: considering both the Inventory and the Web Console API to >> be crucial, it might be conceivable to create API only bundles for these... >> >> Regards >> Felix >> >>> >>> Chetan Mehrotra >>
Re: [osgi] Using Inventory API in Commons Log
On Mon, Feb 3, 2014 at 3:50 PM, Felix Meschberger wrote: > Well, officially, ConfigurationPrinter does not support JSON, but you can > write JSON as TXT output I can ... but rendering JSON in TXT does not look pretty!!. Probably it can be officially made to support json. Chetan Mehrotra
[jira] [Created] (SLING-3364) All rotated log files are not made part of the zip provided through webconsole
Chetan Mehrotra created SLING-3364: -- Summary: All rotated log files are not made part of the zip provided through webconsole Key: SLING-3364 URL: https://issues.apache.org/jira/browse/SLING-3364 Project: Sling Issue Type: Bug Components: Commons Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Fix For: Commons Log 4.0.0 Sling Log bundle so far provided ability to dump all the rotated log files as part of zip generated via Felix WebConsole support. With shift to Logback its not straightforward to determine location of all rotated logs files e.g. one created via config xml Need to find a way to determine all such rotated log files and dump them. 1. Dump all files from log folder 2. Dump only the file created via OSGi configuration as we know the pattern used and then use a logic similar to earlier version to determine all such files. For files generated by other appenders (one configured via xml) its not possible to determine the pattern post initialization -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: [osgi] Using Inventory API in Commons Log
Hi Am 03.02.2014 um 11:24 schrieb Chetan Mehrotra : > On Mon, Feb 3, 2014 at 3:50 PM, Felix Meschberger wrote: >> Well, officially, ConfigurationPrinter does not support JSON, but you can >> write JSON as TXT output > > I can ... but rendering JSON in TXT does not look pretty!!. Probably > it can be officially made to support json. (Or semi-officially by just silently supporting it ?) Patches welcome. Regards Felix
Re: [osgi] Using Inventory API in Commons Log
On Mon, Feb 3, 2014 at 4:31 PM, Felix Meschberger wrote: > (Or semi-officially by just silently supporting it ?) > > Patches welcome. Sure. Added that to ToDo list!! Chetan Mehrotra
Re: [VOTE] Release Testing Resource Resolver Mock 0.2.0
Hi, On Thu, Jan 30, 2014 at 3:37 PM, Carsten Ziegeler wrote: > ...Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-1009 +1, checked signatures, build and the below archive matches the corresponding svn tag. MD5 (./org.apache.sling.testing.resourceresolver-mock/0.2.0/org.apache.sling.testing.resourceresolver-mock-0.2.0-source-release.zip) = d6f848e01cf81f1ba5f61dfb76965715 -Bertrand
[jira] [Created] (SLING-3365) HeartbeatHandler.deactivate() should not block
Stefan Egli created SLING-3365: -- Summary: HeartbeatHandler.deactivate() should not block Key: SLING-3365 URL: https://issues.apache.org/jira/browse/SLING-3365 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Discovery Impl 1.0.2 Reporter: Stefan Egli Assignee: Stefan Egli We've seen a case where the HeartbeatHandler.deactivate() method was blocked at the synchronized(lock): java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.deactivate(HeartbeatHandler.java:169) - waiting to lock <0x0006028bcfd8> (a java.lang.Object) This in turn prevented the bundle to be deactivated and blocked other felix code. The deactivate() method should succeed quickly and instruct any other (HeartbeatHandler) thread to stop immediately too. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (SLING-3365) HeartbeatHandler.deactivate() should not block
[
https://issues.apache.org/jira/browse/SLING-3365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated SLING-3365:
---
Description:
We've seen a case where the HeartbeatHandler.deactivate() method was blocked at
the synchronized(lock):
{code}
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.deactivate(HeartbeatHandler.java:169)
- waiting to lock <0x0006028bcfd8> (a java.lang.Object)
{code}
This in turn prevented the bundle to be deactivated and blocked other felix
code.
The deactivate() method should succeed quickly and instruct any other
(HeartbeatHandler) thread to stop immediately too.
was:
We've seen a case where the HeartbeatHandler.deactivate() method was blocked at
the synchronized(lock):
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.deactivate(HeartbeatHandler.java:169)
- waiting to lock <0x0006028bcfd8> (a java.lang.Object)
This in turn prevented the bundle to be deactivated and blocked other felix
code.
The deactivate() method should succeed quickly and instruct any other
(HeartbeatHandler) thread to stop immediately too.
> HeartbeatHandler.deactivate() should not block
> --
>
> Key: SLING-3365
> URL: https://issues.apache.org/jira/browse/SLING-3365
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Discovery Impl 1.0.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> We've seen a case where the HeartbeatHandler.deactivate() method was blocked
> at the synchronized(lock):
> {code}
>java.lang.Thread.State: BLOCKED (on object monitor)
> at
> org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.deactivate(HeartbeatHandler.java:169)
> - waiting to lock <0x0006028bcfd8> (a java.lang.Object)
> {code}
> This in turn prevented the bundle to be deactivated and blocked other felix
> code.
> The deactivate() method should succeed quickly and instruct any other
> (HeartbeatHandler) thread to stop immediately too.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (SLING-3365) HeartbeatHandler.deactivate() should not block
[
https://issues.apache.org/jira/browse/SLING-3365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli resolved SLING-3365.
Resolution: Fixed
fixed, will be shipped with discovery.impl 1.0.4
> HeartbeatHandler.deactivate() should not block
> --
>
> Key: SLING-3365
> URL: https://issues.apache.org/jira/browse/SLING-3365
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Discovery Impl 1.0.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> We've seen a case where the HeartbeatHandler.deactivate() method was blocked
> at the synchronized(lock):
> {code}
>java.lang.Thread.State: BLOCKED (on object monitor)
> at
> org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.deactivate(HeartbeatHandler.java:169)
> - waiting to lock <0x0006028bcfd8> (a java.lang.Object)
> {code}
> This in turn prevented the bundle to be deactivated and blocked other felix
> code.
> The deactivate() method should succeed quickly and instruct any other
> (HeartbeatHandler) thread to stop immediately too.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (SLING-3366) Allow to configure the heartbeat connection parameters
Timothee Maret created SLING-3366: - Summary: Allow to configure the heartbeat connection parameters Key: SLING-3366 URL: https://issues.apache.org/jira/browse/SLING-3366 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Discovery Impl 1.0.2 Reporter: Timothee Maret The HTTP connections used to send the heartbeats currently uses the default configuration and does not allow for configurations. There maybe extra long requests which take more time to establish the connection than the configured "heartbeatInterval". Thus, it would make sense to allow configuring the connection timeout [0] in an extra parameter such as "connectionTimeout" [0] https://hc.apache.org/httpclient-legacy/apidocs/org/apache/commons/httpclient/params/HttpConnectionParams.html#setConnectionTimeout(int) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (SLING-3367) gzip topology announcements
Stefan Egli created SLING-3367: -- Summary: gzip topology announcements Key: SLING-3367 URL: https://issues.apache.org/jira/browse/SLING-3367 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Discovery Impl 1.0.2 Reporter: Stefan Egli Assignee: Stefan Egli Currently topology announcements are sent as plain-text JSON. If used in a large setup, the announcements grow in size and it would make a lot of sense to gzip it. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (SLING-3368) Add toMap & iterable to resp. JSONObject and JSONArray
Nicolas Peltier created SLING-3368: -- Summary: Add toMap & iterable to resp. JSONObject and JSONArray Key: SLING-3368 URL: https://issues.apache.org/jira/browse/SLING-3368 Project: Sling Issue Type: Improvement Components: Commons Reporter: Nicolas Peltier Priority: Minor Map JSONObject.toMap and JSONArray implementing Iterable allows better usage of those classes. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (SLING-3368) Add toMap & iterable to resp. JSONObject and JSONArray
[ https://issues.apache.org/jira/browse/SLING-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Peltier updated SLING-3368: --- Attachment: [json]_add_other_ways_to_use_JSONArray_and_JSONObject.patch proposed patch > Add toMap & iterable to resp. JSONObject and JSONArray > -- > > Key: SLING-3368 > URL: https://issues.apache.org/jira/browse/SLING-3368 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Nicolas Peltier >Priority: Minor > Attachments: > [json]_add_other_ways_to_use_JSONArray_and_JSONObject.patch > > > Map JSONObject.toMap and JSONArray implementing Iterable allows better usage > of those classes. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[RESULT] [VOTE] Release Apache Sling Models API & Implementation 1.0.0
Hi, The vote has passed with the following result : +1 (binding): Justin Edelson, Ian Boston, Felix Meschberger, Carsten Ziegler +1 (non binding): Dan Klco I will copy this release to the Sling dist directory and promote the artifacts to the central Maven repository. Thanks for voting!
[jira] [Commented] (SLING-3368) Add toMap & iterable to resp. JSONObject and JSONArray
[ https://issues.apache.org/jira/browse/SLING-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13889982#comment-13889982 ] Justin Edelson commented on SLING-3368: --- Is there any reason to be concerned that the returned maps/iterator are mutable? > Add toMap & iterable to resp. JSONObject and JSONArray > -- > > Key: SLING-3368 > URL: https://issues.apache.org/jira/browse/SLING-3368 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Nicolas Peltier >Priority: Minor > Attachments: > [json]_add_other_ways_to_use_JSONArray_and_JSONObject.patch > > > Map JSONObject.toMap and JSONArray implementing Iterable allows better usage > of those classes. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
