[jira] [Updated] (FELIX-3317) Concurrency issue during Component Service registration
[ https://issues.apache.org/jira/browse/FELIX-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-3317: - Summary: Concurrency issue during Component Service registration (was: Potential concurrency issue during Component Service registration) > Concurrency issue during Component Service registration > --- > > Key: FELIX-3317 > URL: https://issues.apache.org/jira/browse/FELIX-3317 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.6.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.6.2 > > > In our Sling-based application we saw the following behavior: The Sling > ResourceResolverFactory is a component being activated. Yet every now and > then a field of that component seems to become null which is not expected for > an activated ResourceResolverFactory component and thus causes a > NullPointerException. > Upon inspection I saw, that for the same Declarative Services component two > Services have been registered where only one was actually expected. > Turns out that consumers of the ResoureResovlerFactory where all bound to the > same service. The component on the other hand has been cycled due to a > configuration update. So one service is backed by a deactivated component > (whose field has been reset to null already) and the other service is live. > The problem is that the service backed by the deactivated method has not been > unregistered and thus all consumers are hooked up to the deactivated instance > causing all sorts of problems ... > This is what most probably happens in the AbstractComponentManager: > * T1 Unsatisfied.activate has set the state to Active already > before calling registerService > * T1 registerService is called but the service registration field > field is not assigned yet > during registerService ServiceListeners are called > * T2 A Configuration update comes in and > Satisfied(Active).deactivate is called > * T2 calls unregisterComponentService; does nothing because the > service registration field is not assigned > * T2 destroys component > * T1 assigns field from service registration > As a result the deactivated object's service registration may be unregistered > later when the component is cycled again and the second service registration > will only be unregistered when the providing bundle is restarted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Weird problem with EventAdmin:blacklisting
Hi carsten thanks for the explanation I did not read the whole source codeunderstood The code works nice in equinox with the same eventadmin bundle deployed inside... I know this plugin and it s installed the event is on the correct topic and the servlet listens this topic but is never notified The event contains a pojo containing data necessary for the asynchronous reaction I will raise the log level to try to get more info Thanks a lot Jerome Envoyé avec BlackBerry® d'Orange -Original Message- From: Carsten Ziegeler Date: Wed, 25 Jan 2012 18:01:43 To: Reply-To: dev@felix.apache.org Subject: Re: Weird problem with EventAdmin:blacklisting Hi, for your previous question: the code is a little bit tricky. It's correct that just the sync handler gets the configuration. But the async handler does not deliver events by itself. It uses internally the async handler as well. Therefore timeout handling applies here as well. The blacklisting is there because according to the spec event handlers should not take too much time for processing (see OSGi Compendium 113.8.2). And you can turn it off :) Even with blacklisting turned on, your handler should be invoked at least once. If it doesn't get an event at all, there might be a problem with the topics or the event sending? The web console has also a plugin for the event admin, do you see your events listed there? For which topic is your handler subscribed? Regards Carsten 2012/1/25 jerome moliere : > My current problems are : > - why such blacklisting ? > - how this blacklisting may affect my communication because with the > webconsole and log service I can see my message present in the right > topic , but it's never dequeued ... it's stuck on the topic, > handleEvent() callback is never invoked in my servlet while it's > correctly set up (I've got the reference displayed as an Eventhandler > for my servlet bundle) > > Thanks for your help > Jerome > J.MOLIERE - Mentor/J > auteur Eyrolles > blog: http://romjethoughts.blogspot.com > > > > > 2012/1/25 jerome moliere : >> Hi once again, >> I just had a look to the source code and I'd like you to drop me a >> terrible confusion... >> In my code I am using the postEvent() method...This is the >> asynchronous sending of message isn't it ? >> But as far as I understand while reading the source ,timeouts are set >> for Synchronous delivery not asychronous one as stated in the next >> code excerpt: >> >> public EventAdminImpl(final HandlerTasks managers, >> final DefaultThreadPool syncPool, >> final DefaultThreadPool asyncPool, >> final int timeout, >> final String[] ignoreTimeout) >> { >> checkNull(managers, "Managers"); >> checkNull(syncPool, "syncPool"); >> checkNull(asyncPool, "asyncPool"); >> >> m_managers = managers; >> >> m_sendManager = new SyncDeliverTasks(syncPool, >> (timeout > 100 ? timeout : 0), >> ignoreTimeout); >> >> m_postManager = new AsyncDeliverTasks(asyncPool, m_sendManager); >> } >> >> So using these properties should have no impact in my case where I am >> using postEvent rather than sendEvent ... >> >> >> Kind regards >> J.MOLIERE - Mentor/J >> auteur Eyrolles >> blog: http://romjethoughts.blogspot.com >> >> >> >> >> 2012/1/25 jerome moliere : >>> Thanks for your help Carsten I'll do some tests >>> I must read the source code to figure out with accuracy what kind of >>> timeouts is used ... >>> I don't see any valuable reason for my servlet not respond in 5seconds!!! >>> It's present at startup with a runlevel 2 ... >>> let me know more about the mechanisms used >>> >>> thanks a lot >>> Jerome >>> J.MOLIERE - Mentor/J >>> auteur Eyrolles >>> blog: http://romjethoughts.blogspot.com >>> >>> >>> >>> >>> 2012/1/25 Carsten Ziegeler : Hi, the Felix event admin by default blacklists event handlers if they take more than 5 secs. With the setting you mentioned, you turn off the timeout for all event handlers. If you want a more fine grained setting, you can use the property org.apache.felix.eventadmin.IgnoreTimeout to disable timeout handling for specific handlers or java packages (see http://felix.apache.org/site/apache-felix-event-admin.html) I assume the Equinox implementation does no blacklisting by default Carsten 2012/1/25 jerome moliere : > I'll try a test with the following property setted to 0 : > org.apache.felix.eventadmin.Timeout > I'll let you know results of such experiments > > regards > J.MOLIERE - Mentor/J > auteur Eyrolles > blog: http://romjethoughts.blogspot.com > > > > > 2012/1/25 jerome moliere : >> Hi all, >> I 've one part of my application that used equinox to run with a >> Tomcat 6 and Spring-DM, it was really very clever so I dropped all >> this stuff and replaced all this spa
Re: Weird problem with EventAdmin:blacklisting
Hi, for your previous question: the code is a little bit tricky. It's correct that just the sync handler gets the configuration. But the async handler does not deliver events by itself. It uses internally the async handler as well. Therefore timeout handling applies here as well. The blacklisting is there because according to the spec event handlers should not take too much time for processing (see OSGi Compendium 113.8.2). And you can turn it off :) Even with blacklisting turned on, your handler should be invoked at least once. If it doesn't get an event at all, there might be a problem with the topics or the event sending? The web console has also a plugin for the event admin, do you see your events listed there? For which topic is your handler subscribed? Regards Carsten 2012/1/25 jerome moliere : > My current problems are : > - why such blacklisting ? > - how this blacklisting may affect my communication because with the > webconsole and log service I can see my message present in the right > topic , but it's never dequeued ... it's stuck on the topic, > handleEvent() callback is never invoked in my servlet while it's > correctly set up (I've got the reference displayed as an Eventhandler > for my servlet bundle) > > Thanks for your help > Jerome > J.MOLIERE - Mentor/J > auteur Eyrolles > blog: http://romjethoughts.blogspot.com > > > > > 2012/1/25 jerome moliere : >> Hi once again, >> I just had a look to the source code and I'd like you to drop me a >> terrible confusion... >> In my code I am using the postEvent() method...This is the >> asynchronous sending of message isn't it ? >> But as far as I understand while reading the source ,timeouts are set >> for Synchronous delivery not asychronous one as stated in the next >> code excerpt: >> >> public EventAdminImpl(final HandlerTasks managers, >> final DefaultThreadPool syncPool, >> final DefaultThreadPool asyncPool, >> final int timeout, >> final String[] ignoreTimeout) >> { >> checkNull(managers, "Managers"); >> checkNull(syncPool, "syncPool"); >> checkNull(asyncPool, "asyncPool"); >> >> m_managers = managers; >> >> m_sendManager = new SyncDeliverTasks(syncPool, >> (timeout > 100 ? timeout : 0), >> ignoreTimeout); >> >> m_postManager = new AsyncDeliverTasks(asyncPool, m_sendManager); >> } >> >> So using these properties should have no impact in my case where I am >> using postEvent rather than sendEvent ... >> >> >> Kind regards >> J.MOLIERE - Mentor/J >> auteur Eyrolles >> blog: http://romjethoughts.blogspot.com >> >> >> >> >> 2012/1/25 jerome moliere : >>> Thanks for your help Carsten I'll do some tests >>> I must read the source code to figure out with accuracy what kind of >>> timeouts is used ... >>> I don't see any valuable reason for my servlet not respond in 5seconds!!! >>> It's present at startup with a runlevel 2 ... >>> let me know more about the mechanisms used >>> >>> thanks a lot >>> Jerome >>> J.MOLIERE - Mentor/J >>> auteur Eyrolles >>> blog: http://romjethoughts.blogspot.com >>> >>> >>> >>> >>> 2012/1/25 Carsten Ziegeler : Hi, the Felix event admin by default blacklists event handlers if they take more than 5 secs. With the setting you mentioned, you turn off the timeout for all event handlers. If you want a more fine grained setting, you can use the property org.apache.felix.eventadmin.IgnoreTimeout to disable timeout handling for specific handlers or java packages (see http://felix.apache.org/site/apache-felix-event-admin.html) I assume the Equinox implementation does no blacklisting by default Carsten 2012/1/25 jerome moliere : > I'll try a test with the following property setted to 0 : > org.apache.felix.eventadmin.Timeout > I'll let you know results of such experiments > > regards > J.MOLIERE - Mentor/J > auteur Eyrolles > blog: http://romjethoughts.blogspot.com > > > > > 2012/1/25 jerome moliere : >> Hi all, >> I 've one part of my application that used equinox to run with a >> Tomcat 6 and Spring-DM, it was really very clever so I dropped all >> this stuff and replaced all this spaghetti plate with a simple felix >> with jetty http service. >> This works excepted that for the case where a servlet declaares itself >> (in one activator) as a consumer for events coming on a topic >> I 'm using eventadmin 1.2.14 version... >> It seems (I've got some logs) that emitter from the event is >> blacklisted by the EventAdmin service (due to timeout) >> I don't understand why this works at 100% cases with equinox and fails >> in 100% cases with Felix ? >> I watched the source code and I've seen the culprit with >> BlackListingHandlerTasks class ... >> What can I do to avoid this ? Can I use some magic config to shunt
[jira] [Commented] (FELIX-3317) Potential concurrency issue during Component Service registration
[ https://issues.apache.org/jira/browse/FELIX-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13193043#comment-13193043 ] Felix Meschberger commented on FELIX-3317: -- There are multiple approaches to this problem: (1) Try to delay the destruction of the component due to the configuration update if an "incomplete" satisified state is recognized (2) Check state consistency after registering the service with the framework: If the state after registration is still the same as before and the service registration field has not been set (by another thread for example), the field is set. Otherwise the field is left untouched and the service is unregistered again (the backing object is most probably destroyed anyway). The first solution must make sure to not create unsolvable deadlocks by for example employing a timout in the delay instead of just waiting. Also an indication of what "incomplete" means and is would be required. The second solution really is a workaround since an invalid (or partially invalid) service object is being distributed causing all sorts of log messages (and may be trouble). > Potential concurrency issue during Component Service registration > - > > Key: FELIX-3317 > URL: https://issues.apache.org/jira/browse/FELIX-3317 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.6.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.6.2 > > > In our Sling-based application we saw the following behavior: The Sling > ResourceResolverFactory is a component being activated. Yet every now and > then a field of that component seems to become null which is not expected for > an activated ResourceResolverFactory component and thus causes a > NullPointerException. > Upon inspection I saw, that for the same Declarative Services component two > Services have been registered where only one was actually expected. > Turns out that consumers of the ResoureResovlerFactory where all bound to the > same service. The component on the other hand has been cycled due to a > configuration update. So one service is backed by a deactivated component > (whose field has been reset to null already) and the other service is live. > The problem is that the service backed by the deactivated method has not been > unregistered and thus all consumers are hooked up to the deactivated instance > causing all sorts of problems ... > This is what most probably happens in the AbstractComponentManager: > * T1 Unsatisfied.activate has set the state to Active already > before calling registerService > * T1 registerService is called but the service registration field > field is not assigned yet > during registerService ServiceListeners are called > * T2 A Configuration update comes in and > Satisfied(Active).deactivate is called > * T2 calls unregisterComponentService; does nothing because the > service registration field is not assigned > * T2 destroys component > * T1 assigns field from service registration > As a result the deactivated object's service registration may be unregistered > later when the component is cycled again and the second service registration > will only be unregistered when the providing bundle is restarted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3311) Cookie handling seems not to work anymore
[ https://issues.apache.org/jira/browse/FELIX-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13193022#comment-13193022 ] Felix Meschberger commented on FELIX-3311: -- I recently (FELIX-3290) changed the cookie handling to create consistent cookie names and also to make the cookies more long-lived. Maybe this change didn't really work properly (it seems to have worked in my setup...) > Cookie handling seems not to work anymore > - > > Key: FELIX-3311 > URL: https://issues.apache.org/jira/browse/FELIX-3311 > Project: Felix > Issue Type: Bug > Components: Web Console >Reporter: Carsten Ziegeler > Fix For: webconsole-3.2.0 > > > Sorting the bundle list, switching to another tab and going back shows the > bundle list in the original sort order but not in the one previously picked > As this information is in a cookie I assume that cookie handling does now > work differently -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3317) Potential concurrency issue during Component Service registration
Potential concurrency issue during Component Service registration - Key: FELIX-3317 URL: https://issues.apache.org/jira/browse/FELIX-3317 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: scr-1.6.2 In our Sling-based application we saw the following behavior: The Sling ResourceResolverFactory is a component being activated. Yet every now and then a field of that component seems to become null which is not expected for an activated ResourceResolverFactory component and thus causes a NullPointerException. Upon inspection I saw, that for the same Declarative Services component two Services have been registered where only one was actually expected. Turns out that consumers of the ResoureResovlerFactory where all bound to the same service. The component on the other hand has been cycled due to a configuration update. So one service is backed by a deactivated component (whose field has been reset to null already) and the other service is live. The problem is that the service backed by the deactivated method has not been unregistered and thus all consumers are hooked up to the deactivated instance causing all sorts of problems ... This is what most probably happens in the AbstractComponentManager: * T1 Unsatisfied.activate has set the state to Active already before calling registerService * T1 registerService is called but the service registration field field is not assigned yet during registerService ServiceListeners are called * T2 A Configuration update comes in and Satisfied(Active).deactivate is called * T2 calls unregisterComponentService; does nothing because the service registration field is not assigned * T2 destroys component * T1 assigns field from service registration As a result the deactivated object's service registration may be unregistered later when the component is cycled again and the second service registration will only be unregistered when the providing bundle is restarted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3311) Cookie handling seems not to work anymore
[ https://issues.apache.org/jira/browse/FELIX-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13193009#comment-13193009 ] Valentin Valchev commented on FELIX-3311: - Changing the language also doesn't work for me. > Cookie handling seems not to work anymore > - > > Key: FELIX-3311 > URL: https://issues.apache.org/jira/browse/FELIX-3311 > Project: Felix > Issue Type: Bug > Components: Web Console >Reporter: Carsten Ziegeler > Fix For: webconsole-3.2.0 > > > Sorting the bundle list, switching to another tab and going back shows the > bundle list in the original sort order but not in the one previously picked > As this information is in a cookie I assume that cookie handling does now > work differently -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3316) Log plugin should provide more detailed exception column
[ https://issues.apache.org/jira/browse/FELIX-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Valchev updated FELIX-3316: Assignee: Felix Meschberger (was: Valentin Valchev) > Log plugin should provide more detailed exception column > > > Key: FELIX-3316 > URL: https://issues.apache.org/jira/browse/FELIX-3316 > Project: Felix > Issue Type: Improvement > Components: Web Console >Affects Versions: webconsole-3.1.8 >Reporter: Valentin Valchev >Assignee: Felix Meschberger > Fix For: webconsole-3.2.0 > > > Now in the Log plugin we have an "Exception" column, that shows only a brief > message description. We should add an option, to enable full stack-trace > display. This could be particularly useful for debugging. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3316) Log plugin should provide more detailed exception column
[ https://issues.apache.org/jira/browse/FELIX-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13193006#comment-13193006 ] Valentin Valchev commented on FELIX-3316: - Fixed in rev.1235728 We need to add localization for the following properties: log.traces=Exception details: log.traces.full=Full Trace log.traces.min=Message Only English and Bulgarian are done, missing German and Russions > Log plugin should provide more detailed exception column > > > Key: FELIX-3316 > URL: https://issues.apache.org/jira/browse/FELIX-3316 > Project: Felix > Issue Type: Improvement > Components: Web Console >Affects Versions: webconsole-3.1.8 >Reporter: Valentin Valchev >Assignee: Felix Meschberger > Fix For: webconsole-3.2.0 > > > Now in the Log plugin we have an "Exception" column, that shows only a brief > message description. We should add an option, to enable full stack-trace > display. This could be particularly useful for debugging. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3315) Log plugin does not show the bundle that has logged the event
[ https://issues.apache.org/jira/browse/FELIX-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Valchev resolved FELIX-3315. - Resolution: Fixed > Log plugin does not show the bundle that has logged the event > - > > Key: FELIX-3315 > URL: https://issues.apache.org/jira/browse/FELIX-3315 > Project: Felix > Issue Type: Improvement > Components: Web Console >Affects Versions: webconsole-3.1.8 >Reporter: Valentin Valchev >Assignee: Valentin Valchev >Priority: Minor > Fix For: webconsole-3.2.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3316) Log plugin should provide more detailed exception column
Log plugin should provide more detailed exception column Key: FELIX-3316 URL: https://issues.apache.org/jira/browse/FELIX-3316 Project: Felix Issue Type: Improvement Components: Web Console Affects Versions: webconsole-3.1.8 Reporter: Valentin Valchev Assignee: Valentin Valchev Fix For: webconsole-3.2.0 Now in the Log plugin we have an "Exception" column, that shows only a brief message description. We should add an option, to enable full stack-trace display. This could be particularly useful for debugging. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3315) Log plugin does not show the bundle that has logged the event
Log plugin does not show the bundle that has logged the event - Key: FELIX-3315 URL: https://issues.apache.org/jira/browse/FELIX-3315 Project: Felix Issue Type: Improvement Components: Web Console Affects Versions: webconsole-3.1.8 Reporter: Valentin Valchev Assignee: Valentin Valchev Priority: Minor Fix For: webconsole-3.2.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Weird problem with EventAdmin:blacklisting
My current problems are : - why such blacklisting ? - how this blacklisting may affect my communication because with the webconsole and log service I can see my message present in the right topic , but it's never dequeued ... it's stuck on the topic, handleEvent() callback is never invoked in my servlet while it's correctly set up (I've got the reference displayed as an Eventhandler for my servlet bundle) Thanks for your help Jerome J.MOLIERE - Mentor/J auteur Eyrolles blog: http://romjethoughts.blogspot.com 2012/1/25 jerome moliere : > Hi once again, > I just had a look to the source code and I'd like you to drop me a > terrible confusion... > In my code I am using the postEvent() method...This is the > asynchronous sending of message isn't it ? > But as far as I understand while reading the source ,timeouts are set > for Synchronous delivery not asychronous one as stated in the next > code excerpt: > > public EventAdminImpl(final HandlerTasks managers, > final DefaultThreadPool syncPool, > final DefaultThreadPool asyncPool, > final int timeout, > final String[] ignoreTimeout) > { > checkNull(managers, "Managers"); > checkNull(syncPool, "syncPool"); > checkNull(asyncPool, "asyncPool"); > > m_managers = managers; > > m_sendManager = new SyncDeliverTasks(syncPool, > (timeout > 100 ? timeout : 0), > ignoreTimeout); > > m_postManager = new AsyncDeliverTasks(asyncPool, m_sendManager); > } > > So using these properties should have no impact in my case where I am > using postEvent rather than sendEvent ... > > > Kind regards > J.MOLIERE - Mentor/J > auteur Eyrolles > blog: http://romjethoughts.blogspot.com > > > > > 2012/1/25 jerome moliere : >> Thanks for your help Carsten I'll do some tests >> I must read the source code to figure out with accuracy what kind of >> timeouts is used ... >> I don't see any valuable reason for my servlet not respond in 5seconds!!! >> It's present at startup with a runlevel 2 ... >> let me know more about the mechanisms used >> >> thanks a lot >> Jerome >> J.MOLIERE - Mentor/J >> auteur Eyrolles >> blog: http://romjethoughts.blogspot.com >> >> >> >> >> 2012/1/25 Carsten Ziegeler : >>> Hi, >>> >>> the Felix event admin by default blacklists event handlers if they >>> take more than 5 secs. With the setting you mentioned, you turn off >>> the timeout for all event handlers. >>> >>> If you want a more fine grained setting, you can use the property >>> org.apache.felix.eventadmin.IgnoreTimeout to disable timeout handling >>> for specific handlers or java packages (see >>> http://felix.apache.org/site/apache-felix-event-admin.html) >>> >>> I assume the Equinox implementation does no blacklisting by default >>> >>> Carsten >>> >>> 2012/1/25 jerome moliere : I'll try a test with the following property setted to 0 : org.apache.felix.eventadmin.Timeout I'll let you know results of such experiments regards J.MOLIERE - Mentor/J auteur Eyrolles blog: http://romjethoughts.blogspot.com 2012/1/25 jerome moliere : > Hi all, > I 've one part of my application that used equinox to run with a > Tomcat 6 and Spring-DM, it was really very clever so I dropped all > this stuff and replaced all this spaghetti plate with a simple felix > with jetty http service. > This works excepted that for the case where a servlet declaares itself > (in one activator) as a consumer for events coming on a topic > I 'm using eventadmin 1.2.14 version... > It seems (I've got some logs) that emitter from the event is > blacklisted by the EventAdmin service (due to timeout) > I don't understand why this works at 100% cases with equinox and fails > in 100% cases with Felix ? > I watched the source code and I've seen the culprit with > BlackListingHandlerTasks class ... > What can I do to avoid this ? Can I use some magic config to shunt > this mecanism ? Can I prevent this module to blacklist a bundle ? > > Thanks for your help > any tip is wlecome > J.MOLIERE - Mentor/J > auteur Eyrolles > blog: http://romjethoughts.blogspot.com >>> >>> >>> >>> -- >>> Carsten Ziegeler >>> cziege...@apache.org
Re: Weird problem with EventAdmin:blacklisting
Hi once again, I just had a look to the source code and I'd like you to drop me a terrible confusion... In my code I am using the postEvent() method...This is the asynchronous sending of message isn't it ? But as far as I understand while reading the source ,timeouts are set for Synchronous delivery not asychronous one as stated in the next code excerpt: public EventAdminImpl(final HandlerTasks managers, final DefaultThreadPool syncPool, final DefaultThreadPool asyncPool, final int timeout, final String[] ignoreTimeout) { checkNull(managers, "Managers"); checkNull(syncPool, "syncPool"); checkNull(asyncPool, "asyncPool"); m_managers = managers; m_sendManager = new SyncDeliverTasks(syncPool, (timeout > 100 ? timeout : 0), ignoreTimeout); m_postManager = new AsyncDeliverTasks(asyncPool, m_sendManager); } So using these properties should have no impact in my case where I am using postEvent rather than sendEvent ... Kind regards J.MOLIERE - Mentor/J auteur Eyrolles blog: http://romjethoughts.blogspot.com 2012/1/25 jerome moliere : > Thanks for your help Carsten I'll do some tests > I must read the source code to figure out with accuracy what kind of > timeouts is used ... > I don't see any valuable reason for my servlet not respond in 5seconds!!! > It's present at startup with a runlevel 2 ... > let me know more about the mechanisms used > > thanks a lot > Jerome > J.MOLIERE - Mentor/J > auteur Eyrolles > blog: http://romjethoughts.blogspot.com > > > > > 2012/1/25 Carsten Ziegeler : >> Hi, >> >> the Felix event admin by default blacklists event handlers if they >> take more than 5 secs. With the setting you mentioned, you turn off >> the timeout for all event handlers. >> >> If you want a more fine grained setting, you can use the property >> org.apache.felix.eventadmin.IgnoreTimeout to disable timeout handling >> for specific handlers or java packages (see >> http://felix.apache.org/site/apache-felix-event-admin.html) >> >> I assume the Equinox implementation does no blacklisting by default >> >> Carsten >> >> 2012/1/25 jerome moliere : >>> I'll try a test with the following property setted to 0 : >>> org.apache.felix.eventadmin.Timeout >>> I'll let you know results of such experiments >>> >>> regards >>> J.MOLIERE - Mentor/J >>> auteur Eyrolles >>> blog: http://romjethoughts.blogspot.com >>> >>> >>> >>> >>> 2012/1/25 jerome moliere : Hi all, I 've one part of my application that used equinox to run with a Tomcat 6 and Spring-DM, it was really very clever so I dropped all this stuff and replaced all this spaghetti plate with a simple felix with jetty http service. This works excepted that for the case where a servlet declaares itself (in one activator) as a consumer for events coming on a topic I 'm using eventadmin 1.2.14 version... It seems (I've got some logs) that emitter from the event is blacklisted by the EventAdmin service (due to timeout) I don't understand why this works at 100% cases with equinox and fails in 100% cases with Felix ? I watched the source code and I've seen the culprit with BlackListingHandlerTasks class ... What can I do to avoid this ? Can I use some magic config to shunt this mecanism ? Can I prevent this module to blacklist a bundle ? Thanks for your help any tip is wlecome J.MOLIERE - Mentor/J auteur Eyrolles blog: http://romjethoughts.blogspot.com >> >> >> >> -- >> Carsten Ziegeler >> cziege...@apache.org
Re: Weird problem with EventAdmin:blacklisting
Hi, by default the impl measures the time an event handler uses too handle this event. Once this is over the configured limit (in millisecs), this handler gets blacklisted - and stays there forever (unless you restart either the handler or the event admin). A usual trap here is debugging an event handler as one usually is slower than 5 secs with debugging ;) You could log in your event handler how long it takes to see where the problem is. Carsten 2012/1/25 jerome moliere : > Thanks for your help Carsten I'll do some tests > I must read the source code to figure out with accuracy what kind of > timeouts is used ... > I don't see any valuable reason for my servlet not respond in 5seconds!!! > It's present at startup with a runlevel 2 ... > let me know more about the mechanisms used > > thanks a lot > Jerome > J.MOLIERE - Mentor/J > auteur Eyrolles > blog: http://romjethoughts.blogspot.com > > > > > 2012/1/25 Carsten Ziegeler : >> Hi, >> >> the Felix event admin by default blacklists event handlers if they >> take more than 5 secs. With the setting you mentioned, you turn off >> the timeout for all event handlers. >> >> If you want a more fine grained setting, you can use the property >> org.apache.felix.eventadmin.IgnoreTimeout to disable timeout handling >> for specific handlers or java packages (see >> http://felix.apache.org/site/apache-felix-event-admin.html) >> >> I assume the Equinox implementation does no blacklisting by default >> >> Carsten >> >> 2012/1/25 jerome moliere : >>> I'll try a test with the following property setted to 0 : >>> org.apache.felix.eventadmin.Timeout >>> I'll let you know results of such experiments >>> >>> regards >>> J.MOLIERE - Mentor/J >>> auteur Eyrolles >>> blog: http://romjethoughts.blogspot.com >>> >>> >>> >>> >>> 2012/1/25 jerome moliere : Hi all, I 've one part of my application that used equinox to run with a Tomcat 6 and Spring-DM, it was really very clever so I dropped all this stuff and replaced all this spaghetti plate with a simple felix with jetty http service. This works excepted that for the case where a servlet declaares itself (in one activator) as a consumer for events coming on a topic I 'm using eventadmin 1.2.14 version... It seems (I've got some logs) that emitter from the event is blacklisted by the EventAdmin service (due to timeout) I don't understand why this works at 100% cases with equinox and fails in 100% cases with Felix ? I watched the source code and I've seen the culprit with BlackListingHandlerTasks class ... What can I do to avoid this ? Can I use some magic config to shunt this mecanism ? Can I prevent this module to blacklist a bundle ? Thanks for your help any tip is wlecome J.MOLIERE - Mentor/J auteur Eyrolles blog: http://romjethoughts.blogspot.com >> >> >> >> -- >> Carsten Ziegeler >> cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org
Re: Weird problem with EventAdmin:blacklisting
Thanks for your help Carsten I'll do some tests I must read the source code to figure out with accuracy what kind of timeouts is used ... I don't see any valuable reason for my servlet not respond in 5seconds!!! It's present at startup with a runlevel 2 ... let me know more about the mechanisms used thanks a lot Jerome J.MOLIERE - Mentor/J auteur Eyrolles blog: http://romjethoughts.blogspot.com 2012/1/25 Carsten Ziegeler : > Hi, > > the Felix event admin by default blacklists event handlers if they > take more than 5 secs. With the setting you mentioned, you turn off > the timeout for all event handlers. > > If you want a more fine grained setting, you can use the property > org.apache.felix.eventadmin.IgnoreTimeout to disable timeout handling > for specific handlers or java packages (see > http://felix.apache.org/site/apache-felix-event-admin.html) > > I assume the Equinox implementation does no blacklisting by default > > Carsten > > 2012/1/25 jerome moliere : >> I'll try a test with the following property setted to 0 : >> org.apache.felix.eventadmin.Timeout >> I'll let you know results of such experiments >> >> regards >> J.MOLIERE - Mentor/J >> auteur Eyrolles >> blog: http://romjethoughts.blogspot.com >> >> >> >> >> 2012/1/25 jerome moliere : >>> Hi all, >>> I 've one part of my application that used equinox to run with a >>> Tomcat 6 and Spring-DM, it was really very clever so I dropped all >>> this stuff and replaced all this spaghetti plate with a simple felix >>> with jetty http service. >>> This works excepted that for the case where a servlet declaares itself >>> (in one activator) as a consumer for events coming on a topic >>> I 'm using eventadmin 1.2.14 version... >>> It seems (I've got some logs) that emitter from the event is >>> blacklisted by the EventAdmin service (due to timeout) >>> I don't understand why this works at 100% cases with equinox and fails >>> in 100% cases with Felix ? >>> I watched the source code and I've seen the culprit with >>> BlackListingHandlerTasks class ... >>> What can I do to avoid this ? Can I use some magic config to shunt >>> this mecanism ? Can I prevent this module to blacklist a bundle ? >>> >>> Thanks for your help >>> any tip is wlecome >>> J.MOLIERE - Mentor/J >>> auteur Eyrolles >>> blog: http://romjethoughts.blogspot.com > > > > -- > Carsten Ziegeler > cziege...@apache.org
Re: Weird problem with EventAdmin:blacklisting
Hi, the Felix event admin by default blacklists event handlers if they take more than 5 secs. With the setting you mentioned, you turn off the timeout for all event handlers. If you want a more fine grained setting, you can use the property org.apache.felix.eventadmin.IgnoreTimeout to disable timeout handling for specific handlers or java packages (see http://felix.apache.org/site/apache-felix-event-admin.html) I assume the Equinox implementation does no blacklisting by default Carsten 2012/1/25 jerome moliere : > I'll try a test with the following property setted to 0 : > org.apache.felix.eventadmin.Timeout > I'll let you know results of such experiments > > regards > J.MOLIERE - Mentor/J > auteur Eyrolles > blog: http://romjethoughts.blogspot.com > > > > > 2012/1/25 jerome moliere : >> Hi all, >> I 've one part of my application that used equinox to run with a >> Tomcat 6 and Spring-DM, it was really very clever so I dropped all >> this stuff and replaced all this spaghetti plate with a simple felix >> with jetty http service. >> This works excepted that for the case where a servlet declaares itself >> (in one activator) as a consumer for events coming on a topic >> I 'm using eventadmin 1.2.14 version... >> It seems (I've got some logs) that emitter from the event is >> blacklisted by the EventAdmin service (due to timeout) >> I don't understand why this works at 100% cases with equinox and fails >> in 100% cases with Felix ? >> I watched the source code and I've seen the culprit with >> BlackListingHandlerTasks class ... >> What can I do to avoid this ? Can I use some magic config to shunt >> this mecanism ? Can I prevent this module to blacklist a bundle ? >> >> Thanks for your help >> any tip is wlecome >> J.MOLIERE - Mentor/J >> auteur Eyrolles >> blog: http://romjethoughts.blogspot.com -- Carsten Ziegeler cziege...@apache.org
Re: Weird problem with EventAdmin:blacklisting
I'll try a test with the following property setted to 0 : org.apache.felix.eventadmin.Timeout I'll let you know results of such experiments regards J.MOLIERE - Mentor/J auteur Eyrolles blog: http://romjethoughts.blogspot.com 2012/1/25 jerome moliere : > Hi all, > I 've one part of my application that used equinox to run with a > Tomcat 6 and Spring-DM, it was really very clever so I dropped all > this stuff and replaced all this spaghetti plate with a simple felix > with jetty http service. > This works excepted that for the case where a servlet declaares itself > (in one activator) as a consumer for events coming on a topic > I 'm using eventadmin 1.2.14 version... > It seems (I've got some logs) that emitter from the event is > blacklisted by the EventAdmin service (due to timeout) > I don't understand why this works at 100% cases with equinox and fails > in 100% cases with Felix ? > I watched the source code and I've seen the culprit with > BlackListingHandlerTasks class ... > What can I do to avoid this ? Can I use some magic config to shunt > this mecanism ? Can I prevent this module to blacklist a bundle ? > > Thanks for your help > any tip is wlecome > J.MOLIERE - Mentor/J > auteur Eyrolles > blog: http://romjethoughts.blogspot.com
[jira] [Resolved] (FELIX-3314) Sort UPnP devices in alphabetical order
[ https://issues.apache.org/jira/browse/FELIX-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Valchev resolved FELIX-3314. - Resolution: Fixed Fix Version/s: webconsole-upnp-plugin-1.0.2 fixed in SVN rev.1235702 > Sort UPnP devices in alphabetical order > --- > > Key: FELIX-3314 > URL: https://issues.apache.org/jira/browse/FELIX-3314 > Project: Felix > Issue Type: Improvement > Components: Web Console >Affects Versions: webconsole-upnp-plugin-1.0.0 >Reporter: Valentin Valchev >Assignee: Valentin Valchev >Priority: Minor > Fix For: webconsole-upnp-plugin-1.0.2 > > Original Estimate: 5m > Remaining Estimate: 5m > > The list of available UPnP devices shown in the UPnP tab of the Web Admin > Console is currently not sorted in alphabetical order. > Please, consider adding a sorting functionality, as it becomes inconvenient > for use when there are many devices registered in the network. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3314) Sort UPnP devices in alphabetical order
Sort UPnP devices in alphabetical order --- Key: FELIX-3314 URL: https://issues.apache.org/jira/browse/FELIX-3314 Project: Felix Issue Type: Improvement Components: Web Console Affects Versions: webconsole-upnp-plugin-1.0.0 Reporter: Valentin Valchev Assignee: Valentin Valchev Priority: Minor The list of available UPnP devices shown in the UPnP tab of the Web Admin Console is currently not sorted in alphabetical order. Please, consider adding a sorting functionality, as it becomes inconvenient for use when there are many devices registered in the network. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release Service Diagnostics Plugin version 0.1.1
+1 Carsten 2012/1/20 Arjun Panday : > Hi everyone, > > Second attempt at releasing the Service Diagnostics WebConsole Plugin. > I've simply refactored the POMs by moving the parent role out of the reactor > POM. The directory structure seems cleaner. Let me know. > > Here's the staging repository: > https://repository.apache.org/content/repositories/orgapachefelix-110/ > > > You can use this UNIX script to download the release and verify the > signatures: > http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh > > Usage: > sh check_staged_release.sh 010 /tmp/felix-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Veto the release (please provide specific comments) > > This vote will be open for 72 hours. > > Thanks, > -arjun > > > > > -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release Service Diagnostics Plugin version 0.1.1
2012/1/25 Arjun Panday : > Hi Carsten, > > Yes, I put it on hkp://pool.sks-keyservers.net, as recommended on this page: > https://docs.sonatype.org/display/Repository/How+To+Generate+PGP+Signatures+With+Maven > > gpg --keyserver hkp://pool.sks-keyservers.net --recv-keys 9196890A > gpg: requesting key 9196890A from hkp server pool.sks-keyservers.net > gpg: key 9196890A: "Arjun Panday (CODE SIGNING KEY) " > not changed > gpg: Total number processed: 1 > gpg: unchanged: 1 > > It is also posted on http://www.apache.org/dist/felix/KEYS Ah great :) Thanks Carsten > > Regards, > Arjun > > > > > On 01/25/2012 09:44 AM, Carsten Ziegeler wrote: >> >> Hi Arjun, >> >> is your key on a public key server? >> >> Regards >> Carsten >> >> 2012/1/20 Arjun Panday: >>> >>> Hi everyone, >>> >>> Second attempt at releasing the Service Diagnostics WebConsole Plugin. >>> I've simply refactored the POMs by moving the parent role out of the >>> reactor >>> POM. The directory structure seems cleaner. Let me know. >>> >>> Here's the staging repository: >>> https://repository.apache.org/content/repositories/orgapachefelix-110/ >>> >>> >>> You can use this UNIX script to download the release and verify the >>> signatures: >>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh >>> >>> Usage: >>> sh check_staged_release.sh 010 /tmp/felix-staging >>> >>> Please vote to approve this release: >>> >>> [ ] +1 Approve the release >>> [ ] -1 Veto the release (please provide specific comments) >>> >>> This vote will be open for 72 hours. >>> >>> Thanks, >>> -arjun >>> >>> >>> >>> >>> >> >> > -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release Service Diagnostics Plugin version 0.1.1
Hi Carsten, Yes, I put it on hkp://pool.sks-keyservers.net, as recommended on this page: https://docs.sonatype.org/display/Repository/How+To+Generate+PGP+Signatures+With+Maven gpg --keyserver hkp://pool.sks-keyservers.net --recv-keys 9196890A gpg: requesting key 9196890A from hkp server pool.sks-keyservers.net gpg: key 9196890A: "Arjun Panday (CODE SIGNING KEY) " not changed gpg: Total number processed: 1 gpg: unchanged: 1 It is also posted on http://www.apache.org/dist/felix/KEYS Regards, Arjun On 01/25/2012 09:44 AM, Carsten Ziegeler wrote: Hi Arjun, is your key on a public key server? Regards Carsten 2012/1/20 Arjun Panday: Hi everyone, Second attempt at releasing the Service Diagnostics WebConsole Plugin. I've simply refactored the POMs by moving the parent role out of the reactor POM. The directory structure seems cleaner. Let me know. Here's the staging repository: https://repository.apache.org/content/repositories/orgapachefelix-110/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 010 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. Thanks, -arjun
Re: [VOTE] Release Service Diagnostics Plugin version 0.1.1
Hi Arjun, is your key on a public key server? Regards Carsten 2012/1/20 Arjun Panday : > Hi everyone, > > Second attempt at releasing the Service Diagnostics WebConsole Plugin. > I've simply refactored the POMs by moving the parent role out of the reactor > POM. The directory structure seems cleaner. Let me know. > > Here's the staging repository: > https://repository.apache.org/content/repositories/orgapachefelix-110/ > > > You can use this UNIX script to download the release and verify the > signatures: > http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh > > Usage: > sh check_staged_release.sh 010 /tmp/felix-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Veto the release (please provide specific comments) > > This vote will be open for 72 hours. > > Thanks, > -arjun > > > > > -- Carsten Ziegeler cziege...@apache.org