[JBoss JIRA] (AS7-6657) Extending NotificationBroadcasterSupport plus methods to jmx notifications
by Kunjan Rathod (JIRA)
[ https://issues.jboss.org/browse/AS7-6657?page=com.atlassian.jira.plugin.s... ]
Kunjan Rathod updated AS7-6657:
-------------------------------
Description:
- Was able to take the changes from jboss-as/trunk + add some extra stuff related to jmx notifications (extends NotificationBroadcasterSupport + methods for next sequence number)
- Validate the extra functionality added (extends NotificationBroadcasterSupport + methods for next sequence number), because it is believed that is missing in the current code.
- Also see attachments.
was:
- Was able to take the changes from jboss-as/trunk + add some extra stuff related to jmx notifications (extends NotificationBroadcasterSupport + methods for next sequence number)
- Validate the extra functionality added (extends NotificationBroadcasterSupport + methods for next sequence number), because it is believed that is missing in the current code.
> Extending NotificationBroadcasterSupport plus methods to jmx notifications
> --------------------------------------------------------------------------
>
> Key: AS7-6657
> URL: https://issues.jboss.org/browse/AS7-6657
> Project: Application Server 7
> Issue Type: Enhancement
> Components: JMX
> Affects Versions: 7.1.3.Final (EAP)
> Environment: AS 7.1.3 Final(EAP)
> Reporter: Kunjan Rathod
> Assignee: Stuart Douglas
> Labels: eap6, new_and_noteworthy
> Fix For: 7.2.0.Alpha1
>
> Attachments: attachments.zip
>
> Original Estimate: 1 minute
> Remaining Estimate: 1 minute
>
> - Was able to take the changes from jboss-as/trunk + add some extra stuff related to jmx notifications (extends NotificationBroadcasterSupport + methods for next sequence number)
> - Validate the extra functionality added (extends NotificationBroadcasterSupport + methods for next sequence number), because it is believed that is missing in the current code.
> - Also see attachments.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (AS7-6657) Extending NotificationBroadcasterSupport plus methods to jmx notifications
by Kunjan Rathod (JIRA)
[ https://issues.jboss.org/browse/AS7-6657?page=com.atlassian.jira.plugin.s... ]
Kunjan Rathod updated AS7-6657:
-------------------------------
Attachment: attachments.zip
Contains :-
===========
1) Service.java
2) ServiceMBean.java
3) ServiceMBeanSupport.java
===========
> Extending NotificationBroadcasterSupport plus methods to jmx notifications
> --------------------------------------------------------------------------
>
> Key: AS7-6657
> URL: https://issues.jboss.org/browse/AS7-6657
> Project: Application Server 7
> Issue Type: Enhancement
> Components: JMX
> Affects Versions: 7.1.3.Final (EAP)
> Environment: AS 7.1.3 Final(EAP)
> Reporter: Kunjan Rathod
> Assignee: Stuart Douglas
> Labels: eap6, new_and_noteworthy
> Fix For: 7.2.0.Alpha1
>
> Attachments: attachments.zip
>
> Original Estimate: 1 minute
> Remaining Estimate: 1 minute
>
> - Was able to take the changes from jboss-as/trunk + add some extra stuff related to jmx notifications (extends NotificationBroadcasterSupport + methods for next sequence number)
> - Validate the extra functionality added (extends NotificationBroadcasterSupport + methods for next sequence number), because it is believed that is missing in the current code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (JGRP-1601) TP: message bundling based on count per dest rather than global count
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1601?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1601:
--------------------------------
If this change still makes sync RPCs fast enough, consider removing the DONT_BUNDLE flag
> TP: message bundling based on count per dest rather than global count
> ---------------------------------------------------------------------
>
> Key: JGRP-1601
> URL: https://issues.jboss.org/browse/JGRP-1601
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> Currently, the message bundlers in TP count accumulated message sizes based on a global 'count' variable. So both multicast messages, and messages to A, B and C increment count.
> If we only sent a message bundle to destination T if (1) there are no more messages in the queue or (2) the accumulated bytes for T would exceed max_bundle_size, then we might send more batches and fewer individual messages.
> Example:
> * We're sending 10K messages and max_bundle_size=55K
> * Different threads concurrently send
> ** T1: 6 multicast messages
> ** T2: 6 messages to A
> ** T3: 6 messages to B
> ** T4: 6 messages to C
> ** T5: 6 messages to D
> ** T6: 6 messages to E
> * If each of the threads gets 1 message in, we've reached the max_bundle_size and will send a message bundle for the multicast, 1 bundle for the unicast message to A, 1 for the message to B and so on, for a total of 5 bundles with *one* message only !
> * If we counted bytes per destination, we'd be able to send a bundle of 5 messages to the multicast dest, 5 to A, 5 to B and so on.
> ** This might lead to better performance, as message batches on the receivers tend to be filled better, especially if we have many messages being sent concurrently.
> With a counter per dest we'd ideally send 6 message batches (containing 6 messages each); whereas with 1 count variable we'd send 36 batches each containing only 1 message !
> Investigate whether it would make sense (perf-wise) to have count being associated with individual destinations rather than having a global count variable.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (AS7-6657) Extending NotificationBroadcasterSupport plus methods to jmx notifications
by Kunjan Rathod (JIRA)
Kunjan Rathod created AS7-6657:
----------------------------------
Summary: Extending NotificationBroadcasterSupport plus methods to jmx notifications
Key: AS7-6657
URL: https://issues.jboss.org/browse/AS7-6657
Project: Application Server 7
Issue Type: Enhancement
Components: JMX
Affects Versions: 7.1.3.Final (EAP)
Environment: AS 7.1.3 Final(EAP)
Reporter: Kunjan Rathod
Assignee: Stuart Douglas
Fix For: 7.2.0.Alpha1
- Was able to take the changes from jboss-as/trunk + add some extra stuff related to jmx notifications (extends NotificationBroadcasterSupport + methods for next sequence number)
- Validate the extra functionality added (extends NotificationBroadcasterSupport + methods for next sequence number), because it is believed that is missing in the current code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (AS7-4321) Provide management view for bundle wiring
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-4321?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler updated AS7-4321:
--------------------------------
Summary: Provide management view for bundle wiring (was: OSGi management console needs inspector of wiring)
> Provide management view for bundle wiring
> -----------------------------------------
>
> Key: AS7-4321
> URL: https://issues.jboss.org/browse/AS7-4321
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Console, OSGi
> Affects Versions: 7.1.1.Final
> Environment: Mac OS X 10.7.3
> Reporter: Tim Diekmann
> Labels: roadmap
>
> The OSGi management console for AS 7 needs a viewer of the current wiring. The console log showed the following error on start of the bundle and there is no way to inspect the wiring to see where the problem lies and how to solve it. There is some inconsistency in the deployment, but how to find out what?
> {code}
> 00:09:14,480 ERROR [org.mortbay.log] (HttpManagementService-threads - 3) Error starting handlers: java.lang.IncompatibleClassChangeError: Class org.eclipse.equinox.http.servlet.HttpServiceServlet does not implement the requested interface javax.servlet.Servlet
> at org.eclipse.equinox.http.jetty.internal.HttpServerManager$InternalHttpServiceServlet.init(HttpServerManager.java:294)
> at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:431)
> at org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263)
> at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:681)
> at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
> at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
> at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
> at org.mortbay.jetty.Server.doStart(Server.java:224)
> at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at org.eclipse.equinox.http.jetty.internal.HttpServerManager.updated(HttpServerManager.java:109)
> at org.eclipse.equinox.http.jetty.internal.Activator.start(Activator.java:60)
> at org.jboss.osgi.framework.internal.HostBundleState.transitionToActive(HostBundleState.java:300)
> at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:223)
> at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:488)
> at org.jboss.as.osgi.parser.BundleRuntimeHandler.handleOperation(BundleRuntimeHandler.java:132)
> at org.jboss.as.osgi.parser.BundleRuntimeHandler.executeRuntimeStep(BundleRuntimeHandler.java:89)
> at org.jboss.as.controller.AbstractRuntimeOnlyHandler$1.execute(AbstractRuntimeOnlyHandler.java:90)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:387)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:274)
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:202)
> at org.jboss.as.controller.ModelControllerImpl$DefaultPrepareStepHandler.execute(ModelControllerImpl.java:461)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:387)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:274)
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:202)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:121)
> at org.jboss.as.controller.ModelControllerImpl$1.execute(ModelControllerImpl.java:304)
> at org.jboss.as.controller.ModelControllerImpl$1.execute(ModelControllerImpl.java:294)
> at org.jboss.as.domain.http.server.DomainApiHandler.processRequest(DomainApiHandler.java:294)
> at org.jboss.as.domain.http.server.DomainApiHandler.doHandle(DomainApiHandler.java:201)
> at org.jboss.as.domain.http.server.DomainApiHandler.handle(DomainApiHandler.java:208)
> at org.jboss.as.domain.http.server.security.SubjectAssociationHandler.handle(SubjectAssociationHandler.java:51)
> at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
> at org.jboss.sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:69)
> at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
> at org.jboss.sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:710)
> at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
> at org.jboss.as.domain.http.server.RealmReadinessFilter.doFilter(RealmReadinessFilter.java:54)
> at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
> at org.jboss.sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:682)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [classes.jar:1.6.0_29]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [classes.jar:1.6.0_29]
> at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_29]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months