[JBoss JIRA] (DROOLS-49) Improve Drools project to support deployment on JBoss Fuse (Apache Karaf) platform
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-49?page=com.atlassian.jira.plugin.... ]
Geoffrey De Smet commented on DROOLS-49:
----------------------------------------
[~cmoulliard] Hi Charles
It's great that you're submitting pull requests, but because the pull requests reformat the all files (especially the XML indentation from 2 to 4 spaces), it's unrealistic for review these changes.
(More info on our indentation sizes etc here: https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/READ...)
> Improve Drools project to support deployment on JBoss Fuse (Apache Karaf) platform
> ----------------------------------------------------------------------------------
>
> Key: DROOLS-49
> URL: https://issues.jboss.org/browse/DROOLS-49
> Project: Drools
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5
> Reporter: Charles Moulliard
> Assignee: Mark Proctor
>
> Existing Drools project has already been modified to support OSGI but the work done is incomplete, buggy and cannot be deployed like that on Apache Karaf (JBoss Fuse).
> In order to allow Drools deployment on Karaf container, I suggest that first we prepare a uberjar bundle of Drools project (1) before to decide strategy to adopt to deploy Drools on OSGI platform and expose OSGI service (2)
> Description of work already done
> 1) Add maven-felix bundle, packaging = bundle & define package to be imported/exported for drools-spring, drools-camel, drools-persistence-jpa, drools-decision-tables
> 2) Create a provisioning feature file to deploy Drools project on Apache Karaf 2.3.0
> 3) Create a itest project validating approach on Karaf with pax-exam & drools example
--
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
13 years, 2 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:
--------------------------------
The downside is that if we a large stream of messages (so we're only terminating a bundle on reaching max_bundle_size for a given dest) and a large number of different destinations, then it will take longer to fill an individual destination, ie. to send the message bundle.
This might be OK for async calls, but would slow sync RPCs down.
Possibly create a subclass of TransferQueueBundler and measure perf with the 2 different bundler types. The goal, however, should be to only have 1 bundler.
> 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
13 years, 2 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 updated JGRP-1601:
---------------------------
Description:
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.
was:
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.
Investigate whether it would make sense (perf-wise) to have count being associated with individual destinations rather than having a global count variable.
> 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
13 years, 2 months
[JBoss JIRA] (DROOLS-49) Improve Drools project to support deployment on JBoss Fuse (Apache Karaf) platform
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-49?page=com.atlassian.jira.plugin.... ]
Geoffrey De Smet updated DROOLS-49:
-----------------------------------
Summary: Improve Drools project to support deployment on JBoss Fuse (Apache Karaf) platform (was: Improve Drools project to support deploymet on JBoss Fuse (Apache Karaf) platform)
> Improve Drools project to support deployment on JBoss Fuse (Apache Karaf) platform
> ----------------------------------------------------------------------------------
>
> Key: DROOLS-49
> URL: https://issues.jboss.org/browse/DROOLS-49
> Project: Drools
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5
> Reporter: Charles Moulliard
> Assignee: Mark Proctor
>
> Existing Drools project has already been modified to support OSGI but the work done is incomplete, buggy and cannot be deployed like that on Apache Karaf (JBoss Fuse).
> In order to allow Drools deployment on Karaf container, I suggest that first we prepare a uberjar bundle of Drools project (1) before to decide strategy to adopt to deploy Drools on OSGI platform and expose OSGI service (2)
> Description of work already done
> 1) Add maven-felix bundle, packaging = bundle & define package to be imported/exported for drools-spring, drools-camel, drools-persistence-jpa, drools-decision-tables
> 2) Create a provisioning feature file to deploy Drools project on Apache Karaf 2.3.0
> 3) Create a itest project validating approach on Karaf with pax-exam & drools example
--
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
13 years, 2 months
[JBoss JIRA] (JGRP-1601) TP: message bundling based on count per dest rather than global count
by Bela Ban (JIRA)
Bela Ban created JGRP-1601:
------------------------------
Summary: 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.
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
13 years, 2 months
[JBoss JIRA] (JBREM-1317) BisocketClientInvoker waits for failed clients
by Doug Grove (JIRA)
[ https://issues.jboss.org/browse/JBREM-1317?page=com.atlassian.jira.plugin... ]
Doug Grove commented on JBREM-1317:
-----------------------------------
In the case where the client has failed, and the server has received the broken pipe, it seems strange to wait for the control connection to timeout. Having said that, living with this behavior then becomes an eduction issue. Support needs to be aware that this can block indefinitely, or can block for an extended period. In the case of JBoss Messaging, this means that the post office will be completely locked and no messages will be delivered.
> BisocketClientInvoker waits for failed clients
> ----------------------------------------------
>
> Key: JBREM-1317
> URL: https://issues.jboss.org/browse/JBREM-1317
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: callbacks
> Affects Versions: 2.5.4.SP3
> Environment: JBoss EAP 5.1.2
> Reporter: Doug Grove
> Assignee: Ron Sigal
> Priority: Minor
>
> When a client dies or is killed, the failure is actually detected in org.jboss.remoting.transport.socket.MicroSocketClientInvoker:
> (NEW ClientSocketWrapper[Socket[addr=/10.0.0.212,port=36600,localport=4458].d3e837]) got Exception: java.io.IOException: Broken pipe
> The "Broken pipe" exception means that the client has disconnected and can not return. This exception is treated in the code a retry-able, however.
> The code carries on, finally calling BisocketClientInvoker.createSocket(). This code then waits for a socket to appear in a list. I can see no way for a new socket to ever appear in the list.
> This results in the code waiting for the full duration of the configured timeout.
--
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
13 years, 2 months
[JBoss JIRA] (AS7-6548) To add salve node dynamicaly
by hitesh yadav (JIRA)
[ https://issues.jboss.org/browse/AS7-6548?page=com.atlassian.jira.plugin.s... ]
hitesh yadav edited comment on AS7-6548 at 2/25/13 8:28 AM:
------------------------------------------------------------
I have check this issue in "jboss-as-7.1.0.Final" and found that it is solved.
But JBOSS Version "jboss-as-7.1.0.Final" required more memory , it require more resources .
In our application there is no requirement for EJB container .
We are just looking for container for (JSP/SERVLET) like "tomcat" and other JBOSS AS7.1 feature.
If it is possible please list me the "extension" and "subsystem" which are not required in my case.
Means how to remove EJB container related module from the "jboss-as-7.1.0.Final" .
was (Author: hitesysony87):
I have check this issue in "jboss-as-7.1.0.Final" and found that it is solved.
But JBOSS Version "jboss-as-7.1.0.Final" required more memory , it require more resources .
In our application there is no requirement for EJB container .
We are just looking for container for (JSP/SERVLET) like "tomcat" and other JBOSS AS7.1 feature.
If it is possible please list me the "extension" and "subsystem" which are not required in my case.
> To add salve node dynamicaly
> ----------------------------
>
> Key: AS7-6548
> URL: https://issues.jboss.org/browse/AS7-6548
> Project: Application Server 7
> Issue Type: Clarification
> Components: Clustering, ConfigAdmin, Domain Management, Server
> Affects Versions: 7.0.2.Final
> Environment: Linux , jboss-as-web-7.0.2.Final
> Reporter: hitesh yadav
> Assignee: Paul Ferraro
> Labels: jboss
>
> Once cluster(domain) is created and if we have deploy .war in cluster after that if we try to add new slave node cluster become unstable.
> We are not able to disable/remove .war from domain controller and also from slave .
--
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
13 years, 2 months
[JBoss JIRA] (AS7-6548) To add salve node dynamicaly
by hitesh yadav (JIRA)
[ https://issues.jboss.org/browse/AS7-6548?page=com.atlassian.jira.plugin.s... ]
hitesh yadav commented on AS7-6548:
-----------------------------------
I have check this issue in "jboss-as-7.1.0.Final" and found that it is solved.
But JBOSS Version "jboss-as-7.1.0.Final" required more memory , it require more resources .
In our application there is no requirement for EJB container .
We are just looking for container for (JSP/SERVLET) like "tomcat" and other JBOSS AS7.1 feature.
If it is possible please list me the "extension" and "subsystem" which are not required in my case.
> To add salve node dynamicaly
> ----------------------------
>
> Key: AS7-6548
> URL: https://issues.jboss.org/browse/AS7-6548
> Project: Application Server 7
> Issue Type: Clarification
> Components: Clustering, ConfigAdmin, Domain Management, Server
> Affects Versions: 7.0.2.Final
> Environment: Linux , jboss-as-web-7.0.2.Final
> Reporter: hitesh yadav
> Assignee: Paul Ferraro
> Labels: jboss
>
> Once cluster(domain) is created and if we have deploy .war in cluster after that if we try to add new slave node cluster become unstable.
> We are not able to disable/remove .war from domain controller and also from slave .
--
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
13 years, 2 months