[JBoss JIRA] (WFLY-5884) Support for multiple mod_cluster configurations (load-balancing on multiple ports)
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5884?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-5884:
---------------------------------
Summary: Support for multiple mod_cluster configurations (load-balancing on multiple ports) (was: wildfly-mod_cluster integration should load-balance requests on more than one ports)
> Support for multiple mod_cluster configurations (load-balancing on multiple ports)
> ----------------------------------------------------------------------------------
>
> Key: WFLY-5884
> URL: https://issues.jboss.org/browse/WFLY-5884
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Environment: httpd 2.2
> modcluster 1.3.0
> wildfly 8.2.0.Final
> Reporter: kostd kostd
> Assignee: Radoslav Husar
> Priority: Trivial
> Labels: connector, listener, load-balancing, mod_cluster, port, undertow
> Attachments: load-balancer-question-scheme.png
>
>
> Earlier I asked on forums https://developer.jboss.org/message/946476#946476
> {quote}
> on our wf8.2 server the web-app have two http endpoints: on port 8080 to regular http requests; and on port 37304 to "special" user requests in protected area.
>
> we want use mod_cluster as load-balancer that balances user requests on both ports. For example(see the pic), lets requests on balancer`s port 7801 will be balance between node1 and node2 on port 8080, and requests on balancer`s port 7802 will be balance on port 37304.
>
> In modcluster-subsystem configuration in standalone.xml we can set only one connector for mod-cluster config. And cannot set more than one mod-cluster-config section:
>
> {code:title=jboss-as-mod-cluster_1_2.xsd}
> <xs:element name="mod-cluster-config" type="mod-cluster-configType" minOccurs="0" maxOccurs="1"/>
> {code}
>
> alternatively, we can use mod_cluster + mod_proxy_balancer or mod_cluster + mod_jk so that mod_cluster balances on 8080 and other tech(mod_proxy_balancer or mod_jk) balances on other port 37304.
> But this decision obviously not good: reverse loopback from servers(mgmt info with loadfactor of server) to balancer will manage balancing only for one port, not for both.
>
> Seems that mod_cluster absolutely not supports more than one connector balancing:
>
> {code:title=http://docs.jboss.org/mod_cluster/1.3.0/pdf/Mod_cluster-UserGuide.pdf}
> Like mod_jk and mod_proxy_balancer, mod_cluster requires a connector in your server.xml to
> which to forward web requests. Unlike mod_jk and mod_proxy_balancer, mod_cluster is not
> confined to AJP, but can use HTTP as well. While AJP is generally faster, an HTTP connector
> can optionally be secured via SSL. If multiple possible connectors are defined in your server.xml,
> mod_cluster uses the following algorithm to choose between them:
> 1. If an native (APR) AJP connector is available, use it.
> 2. If an AJP connector is available, use it.
> 3. Otherwise, choose the HTTP connector with the highest max threads.
> {code}
>
> is this true?
>
> what is the best way to solve our problem?
> {quote}
> During more than 100 views no one answer :'(
> Now we have made a decision to use mod_proxy_balancer, but if it possible to refine mod_cluster subsystem, this will be greate. When it happens, we will jump to mod_cluster again :)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-5884) Support for multiple mod_cluster configurations (load-balancing on multiple ports)
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5884?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-5884:
---------------------------------
Priority: Major (was: Trivial)
> Support for multiple mod_cluster configurations (load-balancing on multiple ports)
> ----------------------------------------------------------------------------------
>
> Key: WFLY-5884
> URL: https://issues.jboss.org/browse/WFLY-5884
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Environment: httpd 2.2
> modcluster 1.3.0
> wildfly 8.2.0.Final
> Reporter: kostd kostd
> Assignee: Radoslav Husar
> Labels: connector, listener, load-balancing, mod_cluster, port, undertow
> Attachments: load-balancer-question-scheme.png
>
>
> Earlier I asked on forums https://developer.jboss.org/message/946476#946476
> {quote}
> on our wf8.2 server the web-app have two http endpoints: on port 8080 to regular http requests; and on port 37304 to "special" user requests in protected area.
>
> we want use mod_cluster as load-balancer that balances user requests on both ports. For example(see the pic), lets requests on balancer`s port 7801 will be balance between node1 and node2 on port 8080, and requests on balancer`s port 7802 will be balance on port 37304.
>
> In modcluster-subsystem configuration in standalone.xml we can set only one connector for mod-cluster config. And cannot set more than one mod-cluster-config section:
>
> {code:title=jboss-as-mod-cluster_1_2.xsd}
> <xs:element name="mod-cluster-config" type="mod-cluster-configType" minOccurs="0" maxOccurs="1"/>
> {code}
>
> alternatively, we can use mod_cluster + mod_proxy_balancer or mod_cluster + mod_jk so that mod_cluster balances on 8080 and other tech(mod_proxy_balancer or mod_jk) balances on other port 37304.
> But this decision obviously not good: reverse loopback from servers(mgmt info with loadfactor of server) to balancer will manage balancing only for one port, not for both.
>
> Seems that mod_cluster absolutely not supports more than one connector balancing:
>
> {code:title=http://docs.jboss.org/mod_cluster/1.3.0/pdf/Mod_cluster-UserGuide.pdf}
> Like mod_jk and mod_proxy_balancer, mod_cluster requires a connector in your server.xml to
> which to forward web requests. Unlike mod_jk and mod_proxy_balancer, mod_cluster is not
> confined to AJP, but can use HTTP as well. While AJP is generally faster, an HTTP connector
> can optionally be secured via SSL. If multiple possible connectors are defined in your server.xml,
> mod_cluster uses the following algorithm to choose between them:
> 1. If an native (APR) AJP connector is available, use it.
> 2. If an AJP connector is available, use it.
> 3. Otherwise, choose the HTTP connector with the highest max threads.
> {code}
>
> is this true?
>
> what is the best way to solve our problem?
> {quote}
> During more than 100 views no one answer :'(
> Now we have made a decision to use mod_proxy_balancer, but if it possible to refine mod_cluster subsystem, this will be greate. When it happens, we will jump to mod_cluster again :)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-5884) Support for multiple mod_cluster configurations (load-balancing on multiple ports)
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5884?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-5884:
---------------------------------
Affects Version/s: 10.0.0.Final
> Support for multiple mod_cluster configurations (load-balancing on multiple ports)
> ----------------------------------------------------------------------------------
>
> Key: WFLY-5884
> URL: https://issues.jboss.org/browse/WFLY-5884
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Environment: httpd 2.2
> modcluster 1.3.0
> wildfly 8.2.0.Final
> Reporter: kostd kostd
> Assignee: Radoslav Husar
> Labels: connector, listener, load-balancing, mod_cluster, port, undertow
> Attachments: load-balancer-question-scheme.png
>
>
> Earlier I asked on forums https://developer.jboss.org/message/946476#946476
> {quote}
> on our wf8.2 server the web-app have two http endpoints: on port 8080 to regular http requests; and on port 37304 to "special" user requests in protected area.
>
> we want use mod_cluster as load-balancer that balances user requests on both ports. For example(see the pic), lets requests on balancer`s port 7801 will be balance between node1 and node2 on port 8080, and requests on balancer`s port 7802 will be balance on port 37304.
>
> In modcluster-subsystem configuration in standalone.xml we can set only one connector for mod-cluster config. And cannot set more than one mod-cluster-config section:
>
> {code:title=jboss-as-mod-cluster_1_2.xsd}
> <xs:element name="mod-cluster-config" type="mod-cluster-configType" minOccurs="0" maxOccurs="1"/>
> {code}
>
> alternatively, we can use mod_cluster + mod_proxy_balancer or mod_cluster + mod_jk so that mod_cluster balances on 8080 and other tech(mod_proxy_balancer or mod_jk) balances on other port 37304.
> But this decision obviously not good: reverse loopback from servers(mgmt info with loadfactor of server) to balancer will manage balancing only for one port, not for both.
>
> Seems that mod_cluster absolutely not supports more than one connector balancing:
>
> {code:title=http://docs.jboss.org/mod_cluster/1.3.0/pdf/Mod_cluster-UserGuide.pdf}
> Like mod_jk and mod_proxy_balancer, mod_cluster requires a connector in your server.xml to
> which to forward web requests. Unlike mod_jk and mod_proxy_balancer, mod_cluster is not
> confined to AJP, but can use HTTP as well. While AJP is generally faster, an HTTP connector
> can optionally be secured via SSL. If multiple possible connectors are defined in your server.xml,
> mod_cluster uses the following algorithm to choose between them:
> 1. If an native (APR) AJP connector is available, use it.
> 2. If an AJP connector is available, use it.
> 3. Otherwise, choose the HTTP connector with the highest max threads.
> {code}
>
> is this true?
>
> what is the best way to solve our problem?
> {quote}
> During more than 100 views no one answer :'(
> Now we have made a decision to use mod_proxy_balancer, but if it possible to refine mod_cluster subsystem, this will be greate. When it happens, we will jump to mod_cluster again :)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-5884) Support for multiple mod_cluster configurations (load-balancing on multiple ports)
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5884?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-5884:
---------------------------------
Affects Version/s: 8.2.0.Final
> Support for multiple mod_cluster configurations (load-balancing on multiple ports)
> ----------------------------------------------------------------------------------
>
> Key: WFLY-5884
> URL: https://issues.jboss.org/browse/WFLY-5884
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Environment: httpd 2.2
> modcluster 1.3.0
> wildfly 8.2.0.Final
> Reporter: kostd kostd
> Assignee: Radoslav Husar
> Labels: connector, listener, load-balancing, mod_cluster, port, undertow
> Attachments: load-balancer-question-scheme.png
>
>
> Earlier I asked on forums https://developer.jboss.org/message/946476#946476
> {quote}
> on our wf8.2 server the web-app have two http endpoints: on port 8080 to regular http requests; and on port 37304 to "special" user requests in protected area.
>
> we want use mod_cluster as load-balancer that balances user requests on both ports. For example(see the pic), lets requests on balancer`s port 7801 will be balance between node1 and node2 on port 8080, and requests on balancer`s port 7802 will be balance on port 37304.
>
> In modcluster-subsystem configuration in standalone.xml we can set only one connector for mod-cluster config. And cannot set more than one mod-cluster-config section:
>
> {code:title=jboss-as-mod-cluster_1_2.xsd}
> <xs:element name="mod-cluster-config" type="mod-cluster-configType" minOccurs="0" maxOccurs="1"/>
> {code}
>
> alternatively, we can use mod_cluster + mod_proxy_balancer or mod_cluster + mod_jk so that mod_cluster balances on 8080 and other tech(mod_proxy_balancer or mod_jk) balances on other port 37304.
> But this decision obviously not good: reverse loopback from servers(mgmt info with loadfactor of server) to balancer will manage balancing only for one port, not for both.
>
> Seems that mod_cluster absolutely not supports more than one connector balancing:
>
> {code:title=http://docs.jboss.org/mod_cluster/1.3.0/pdf/Mod_cluster-UserGuide.pdf}
> Like mod_jk and mod_proxy_balancer, mod_cluster requires a connector in your server.xml to
> which to forward web requests. Unlike mod_jk and mod_proxy_balancer, mod_cluster is not
> confined to AJP, but can use HTTP as well. While AJP is generally faster, an HTTP connector
> can optionally be secured via SSL. If multiple possible connectors are defined in your server.xml,
> mod_cluster uses the following algorithm to choose between them:
> 1. If an native (APR) AJP connector is available, use it.
> 2. If an AJP connector is available, use it.
> 3. Otherwise, choose the HTTP connector with the highest max threads.
> {code}
>
> is this true?
>
> what is the best way to solve our problem?
> {quote}
> During more than 100 views no one answer :'(
> Now we have made a decision to use mod_proxy_balancer, but if it possible to refine mod_cluster subsystem, this will be greate. When it happens, we will jump to mod_cluster again :)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-5884) Support for multiple mod_cluster configurations (load-balancing on multiple ports)
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5884?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-5884:
---------------------------------
Labels: connector listener load-balancing mod_cluster port undertow (was: connector listener load-balancing mod_cluster port undertow wildfly)
> Support for multiple mod_cluster configurations (load-balancing on multiple ports)
> ----------------------------------------------------------------------------------
>
> Key: WFLY-5884
> URL: https://issues.jboss.org/browse/WFLY-5884
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Environment: httpd 2.2
> modcluster 1.3.0
> wildfly 8.2.0.Final
> Reporter: kostd kostd
> Assignee: Radoslav Husar
> Labels: connector, listener, load-balancing, mod_cluster, port, undertow
> Attachments: load-balancer-question-scheme.png
>
>
> Earlier I asked on forums https://developer.jboss.org/message/946476#946476
> {quote}
> on our wf8.2 server the web-app have two http endpoints: on port 8080 to regular http requests; and on port 37304 to "special" user requests in protected area.
>
> we want use mod_cluster as load-balancer that balances user requests on both ports. For example(see the pic), lets requests on balancer`s port 7801 will be balance between node1 and node2 on port 8080, and requests on balancer`s port 7802 will be balance on port 37304.
>
> In modcluster-subsystem configuration in standalone.xml we can set only one connector for mod-cluster config. And cannot set more than one mod-cluster-config section:
>
> {code:title=jboss-as-mod-cluster_1_2.xsd}
> <xs:element name="mod-cluster-config" type="mod-cluster-configType" minOccurs="0" maxOccurs="1"/>
> {code}
>
> alternatively, we can use mod_cluster + mod_proxy_balancer or mod_cluster + mod_jk so that mod_cluster balances on 8080 and other tech(mod_proxy_balancer or mod_jk) balances on other port 37304.
> But this decision obviously not good: reverse loopback from servers(mgmt info with loadfactor of server) to balancer will manage balancing only for one port, not for both.
>
> Seems that mod_cluster absolutely not supports more than one connector balancing:
>
> {code:title=http://docs.jboss.org/mod_cluster/1.3.0/pdf/Mod_cluster-UserGuide.pdf}
> Like mod_jk and mod_proxy_balancer, mod_cluster requires a connector in your server.xml to
> which to forward web requests. Unlike mod_jk and mod_proxy_balancer, mod_cluster is not
> confined to AJP, but can use HTTP as well. While AJP is generally faster, an HTTP connector
> can optionally be secured via SSL. If multiple possible connectors are defined in your server.xml,
> mod_cluster uses the following algorithm to choose between them:
> 1. If an native (APR) AJP connector is available, use it.
> 2. If an AJP connector is available, use it.
> 3. Otherwise, choose the HTTP connector with the highest max threads.
> {code}
>
> is this true?
>
> what is the best way to solve our problem?
> {quote}
> During more than 100 views no one answer :'(
> Now we have made a decision to use mod_proxy_balancer, but if it possible to refine mod_cluster subsystem, this will be greate. When it happens, we will jump to mod_cluster again :)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (DROOLS-1017) NPE deleting an expired event in equality mode
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1017?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on DROOLS-1017:
-------------------------------------------------
Edson Tirelli <etirelli(a)redhat.com> changed the Status of [bug 1295433|https://bugzilla.redhat.com/show_bug.cgi?id=1295433] from NEW to MODIFIED
> NPE deleting an expired event in equality mode
> ----------------------------------------------
>
> Key: DROOLS-1017
> URL: https://issues.jboss.org/browse/DROOLS-1017
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.4.x
>
>
> Trying to delete an already expired event in equality mode causes the following NPE in the TMS:
> {code}
> java.lang.NullPointerException
> at org.drools.core.common.NamedEntryPoint.delete(NamedEntryPoint.java:506)
> at org.drools.core.common.NamedEntryPoint.delete(NamedEntryPoint.java:442)
> at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1120)
> at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:121)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1003)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1346)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1284)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1303)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1293)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1274)
> at org.drools.compiler.integrationtests.CepEspTest.testDeleteExpiredEventWithTimestampAndEqualityKey(CepEspTest.java:5682)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-5480) SPEC JMS 2007 benchmark fails with AMQ214013: Failed to decode packet
by Ondřej Kalman (JIRA)
[ https://issues.jboss.org/browse/WFLY-5480?page=com.atlassian.jira.plugin.... ]
Ondřej Kalman commented on WFLY-5480:
-------------------------------------
Hi, is there any progress with this issue?
> SPEC JMS 2007 benchmark fails with AMQ214013: Failed to decode packet
> ---------------------------------------------------------------------
>
> Key: WFLY-5480
> URL: https://issues.jboss.org/browse/WFLY-5480
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Ondřej Kalman
> Assignee: Flavia Rainone
> Priority: Blocker
>
> But I have another problem, when I removed trace logs from config I'm not able to run benchmark on localhost to the end, because clients starts getting :
> AMQ214013: Failed to decode packet
> java.lang.IndexOutOfBoundsException: readerIndex: 2130706436 (expected: 0 <= readerIndex <= writerIndex(2943))
> at io.netty.buffer.AbstractByteBuf.readerIndex(AbstractByteBuf.java:73)
> at io.netty.buffer.WrappedByteBuf.readerIndex(WrappedByteBuf.java:99)
> at org.apache.activemq.artemis.core.buffers.impl.ChannelBufferWrapper.readerIndex(ChannelBufferWrapper.java:405)
> at org.apache.activemq.artemis.core.message.impl.MessageImpl.decode(MessageImpl.java:1052)
> at org.apache.activemq.artemis.core.message.impl.MessageImpl.decodeFromBuffer(MessageImpl.java:459)
> at org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionReceiveMessage.decode(SessionReceiveMessage.java:94)
> at org.apache.activemq.artemis.core.protocol.ClientPacketDecoder.decode(ClientPacketDecoder.java:42)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:371)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$DelegatingBufferHandler.bufferReceived(ClientSessionFactoryImpl.java:1374)
> at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:242)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:847)
> at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteCha
> nnel.java:131)
> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511)
> at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
> at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354)
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:111)
> at java.lang.Thread.run(Thread.java:745)
> and
> Thread-9 (ActiveMQ-client-global-threads-1266561810): Uncaught exception.
> java.lang.NumberFormatException: null
> at java.lang.Integer.parseInt(Integer.java:542)
> at java.lang.Integer.valueOf(Integer.java:766)
> at org.apache.activemq.artemis.utils.TypedProperties.getIntProperty(TypedProperties.java:280)
> at org.apache.activemq.artemis.core.message.impl.MessageImpl.getIntProperty(MessageImpl.java:811)
> at org.apache.activemq.artemis.jms.client.ActiveMQMessage.getIntProperty(ActiveMQMessage.java:578)
> at org.spec.jms.agents.SPECWorkerThread.receivedMessage(SPECWorkerThread.java:849)
> at org.spec.jms.agents.SPECWorkerThread.onMessage(SPECWorkerThread.java:820)
> at org.apache.activemq.artemis.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:100)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1089)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:47)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1224)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Thread-3 (ActiveMQ-client-global-threads-1266561810): Uncaught exception.
> javax.jms.IllegalStateException: AMQ119027: Could not find reference on consumer ID=0, messageId = 104,833 queue = 127\.0\.0\.1_VM1_SPAgent7_0.SP_CallForOffersEH_7_EHID_1PF0
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:410)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.sendACK(ActiveMQSessionContext.java:461)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.acknowledge(ClientSessionImpl.java:765)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.doAck(ClientConsumerImpl.java:1212)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.flushAcks(ClientConsumerImpl.java:830)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.flushAcks(ClientSessionImpl.java:1852)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.commit(ClientSessionImpl.java:501)
> at org.apache.activemq.artemis.core.client.impl.DelegatingSession.commit(DelegatingSession.java:159)
> at org.apache.activemq.artemis.jms.client.ActiveMQSession.commit(ActiveMQSession.java:218)
> at org.spec.jms.eventhandler.sp.SP_CallForOffersEH.handleMessage(SP_CallForOffersEH.java:306)
> at org.spec.jms.agents.SPECWorkerThread.onMessage(SPECWorkerThread.java:821)
> at org.apache.activemq.artemis.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:100)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1089)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:47)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1224)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecut
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (DROOLS-662) Autopublish drools-website, optaplanner-website and jbpm-website through travis
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-662?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet commented on DROOLS-662:
-----------------------------------------
Current state: the travis jobs exist, but they don't publish yet. We need them to publish too.
> Autopublish drools-website, optaplanner-website and jbpm-website through travis
> -------------------------------------------------------------------------------
>
> Key: DROOLS-662
> URL: https://issues.jboss.org/browse/DROOLS-662
> Project: Drools
> Issue Type: Task
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
>
> The jboss-tools guys already auto publish their awestruct website. xcoulon on irc #awestruct told me how they do this at Devoxx.
> Travis is like Jenkins, but works really well for ruby stuff (such as awestruct websites). It can publish our websites automatically if we push a commit. Here's how to set it up:
> - Add a .travis.yml file, look at this one for inspiration: https://github.com/jbosstools/jbosstools-website/blob/master/.travis.yml
> - Get a secret token to be able to publish a website on jboss.org filemanagement server. Then encrypt that secret token with Travis's public key (so only Travis can decrypt it). Write the encrypted secret token in the travis.yml file. Remove all knowledge of the actual secret token, so it can't leak.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1271) Description of worker attributes of IO subsystem contains escaped char sequences
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1271?page=com.atlassian.jira.plugi... ]
Tomaz Cerar moved JBEAP-2575 to WFCORE-1271:
--------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1271 (was: JBEAP-2575)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: Domain Management
(was: IO)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 2.0.5.Final
(was: 7.0.0.ER2 (Beta))
> Description of worker attributes of IO subsystem contains escaped char sequences
> --------------------------------------------------------------------------------
>
> Key: WFCORE-1271
> URL: https://issues.jboss.org/browse/WFCORE-1271
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.5.Final
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
> Priority: Minor
>
> Description of worker attributes of IO subsystem contains escaped char *\"* sequences.
> {noformat}[standalone@localhost:9990 /] cd subsystem=io/worker=default
> [standalone@localhost:9990 worker=default] :read-resource-description(recursive=true)
> {
> "outcome" => "success",
> "result" => {
> "description" => "Defines workers",
> "capabilities" => [{
> "name" => "org.wildfly.io.worker",
> "dynamic" => true
> }],
> "attributes" => {
> "io-threads" => {
> "type" => INT,
> "description" => "\"Specify the number of I/O threads to create for the worker. If not specified, a default will be chosen, which is calculated by cpuCount * 2\"",
> "expressions-allowed" => false,
> "nillable" => true,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> "stack-size" => {
> "type" => LONG,
> "description" => "The stack size (in bytes) to attempt to use for worker threads.",
> "expressions-allowed" => false,
> "nillable" => true,
> "default" => 0L,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> "task-keepalive" => {
> "type" => INT,
> "description" => "Specify the number of milliseconds to keep non-core task threads alive.",
> "expressions-allowed" => false,
> "nillable" => true,
> "default" => 60,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> "task-max-threads" => {
> "type" => INT,
> "description" => "\"Specify the maximum number of threads for the worker task thread pool.If not set, default value used which is calculated by formula cpuCount * 16\"",
> "expressions-allowed" => false,
> "nillable" => true,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> }
> },
> "operations" => undefined,
> "notifications" => undefined,
> "children" => {}
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months