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 arjun.pan...@alcatel-lucent.com: 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) apan...@apache.org 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 Pandayarjun.pan...@alcatel-lucent.com: 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
2012/1/25 Arjun Panday arjun.pan...@alcatel-lucent.com: 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) apan...@apache.org 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 Pandayarjun.pan...@alcatel-lucent.com: 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
+1 Carsten 2012/1/20 Arjun Panday arjun.pan...@alcatel-lucent.com: 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
[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: 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 jerome.moli...@gmail.com: 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
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 jerome.moli...@gmail.com: 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 jerome.moli...@gmail.com: 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
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 cziege...@apache.org: 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 jerome.moli...@gmail.com: 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 jerome.moli...@gmail.com: 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 jerome.moli...@gmail.com: 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 cziege...@apache.org: 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 jerome.moli...@gmail.com: 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 jerome.moli...@gmail.com: 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
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 jerome.moli...@gmail.com:
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 cziege...@apache.org:
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 jerome.moli...@gmail.com:
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 jerome.moli...@gmail.com:
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
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 jerome.moli...@gmail.com:
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 jerome.moli...@gmail.com:
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 cziege...@apache.org:
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 jerome.moli...@gmail.com:
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 jerome.moli...@gmail.com:
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
[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
[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] [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] [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-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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
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 jerome.moli...@gmail.com:
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 jerome.moli...@gmail.com:
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 jerome.moli...@gmail.com:
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 cziege...@apache.org:
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 jerome.moli...@gmail.com:
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 jerome.moli...@gmail.com:
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 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 cziege...@apache.org
Date: Wed, 25 Jan 2012 18:01:43
To: dev@felix.apache.org
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 jerome.moli...@gmail.com:
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 jerome.moli...@gmail.com:
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 jerome.moli...@gmail.com:
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 cziege...@apache.org:
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 jerome.moli...@gmail.com:
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 jerome.moli...@gmail.com:
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
[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
