January 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5942) Binding to <any-address/> will make mod_cluster advertise host as 0.0.0.0

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-5942: ------------------------------------ Summary: Binding to <any-address/> will make mod_cluster advertise host as 0.0.0.0 Key: WFLY-5942 URL: https://issues.jboss.org/browse/WFLY-5942 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.0.0.CR5 Reporter: Radoslav Husar Assignee: Radoslav Husar Needs to be handled in {{org.wildfly.mod_cluster.undertow.UndertowConnector#setAddress}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[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)

10 years, 3 months

1
0
0 / 0

[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)

10 years, 3 months

1
0
0 / 0

[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)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1982) RequestCorrelator: use IntHashMap / LongHashmap for request correlation

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1982?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1982: -------------------------------- Hmm, we could check whether we find a contiguous amount of free space, and do compaction, e.g. ||0||1||2||3||4||5||6||7|| |0|-|-|-|-|-|-|7| Here we have an array of capacity=8, with request IDs 0 (at index 0) and 7 (at index 7). We have 6 free array slots available for compaction. We could therefore compact the array to (say) 4 (or even 2): ||0||1||2||3|| |0|-|-|7| 0 mod 4 is index=0 and 7 mod 4 is index=3, so this works. The question is _when_ to check if the array can be compacted and determining the minimum number of free slots for compaction... > RequestCorrelator: use IntHashMap / LongHashmap for request correlation > ----------------------------------------------------------------------- > > Key: JGRP-1982 > URL: https://issues.jboss.org/browse/JGRP-1982 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.7 > > > In RequestCorrelator (and possibly other classes), use an IntHashMap or LongHashmap for the request table. Goal: use less space when we have a lot of requests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1982) RequestCorrelator: use IntHashMap / LongHashmap for request correlation

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1982?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1982: --------------------------- Comment: was deleted (was: Hmm, we could check whether we find a _contiguous amount of free space_, and do compaction, e.g. {noformat} || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || {noformat}) > RequestCorrelator: use IntHashMap / LongHashmap for request correlation > ----------------------------------------------------------------------- > > Key: JGRP-1982 > URL: https://issues.jboss.org/browse/JGRP-1982 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.7 > > > In RequestCorrelator (and possibly other classes), use an IntHashMap or LongHashmap for the request table. Goal: use less space when we have a lot of requests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1982) RequestCorrelator: use IntHashMap / LongHashmap for request correlation

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1982?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1982: -------------------------------- Hmm, we could check whether we find a _contiguous amount of free space_, and do compaction, e.g. {noformat} || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || {noformat} > RequestCorrelator: use IntHashMap / LongHashmap for request correlation > ----------------------------------------------------------------------- > > Key: JGRP-1982 > URL: https://issues.jboss.org/browse/JGRP-1982 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.7 > > > In RequestCorrelator (and possibly other classes), use an IntHashMap or LongHashmap for the request table. Goal: use less space when we have a lot of requests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1020) Add withVars query attribute to getProcessInstance operation for finished processes

by Ivo Bek (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1020?page=com.atlassian.jira.plugi... ] Ivo Bek updated DROOLS-1020: ---------------------------- Labels: reported-by-qe (was: ) > Add withVars query attribute to getProcessInstance operation for finished processes > ----------------------------------------------------------------------------------- > > Key: DROOLS-1020 > URL: https://issues.jboss.org/browse/DROOLS-1020 > Project: Drools > Issue Type: Enhancement > Components: kie server > Affects Versions: 6.3.0.Final > Reporter: Ivo Bek > Assignee: Ivo Bek > Priority: Minor > Labels: reported-by-qe > Original Estimate: 1 week > Remaining Estimate: 1 week > > KIE Server already provides getProcessInstance operation with query attribute withVars but only for an active process instance [1]. The enhancement will add this functionality to RuntimeDataResource to be able to query completed and aborted processes including their variables. > Additionally, the changes will require to change KIE Server client and it would be nice to add functionality to both REST and JMS. > [1] https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/kie-serv... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1262) Make the /host=* 'domain-controller' attribute writeable in the normal way

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1262?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet reassigned WFCORE-1262: ----------------------------------------- Assignee: ehsavoie Hugonnet > Make the /host=* 'domain-controller' attribute writeable in the normal way > -------------------------------------------------------------------------- > > Key: WFCORE-1262 > URL: https://issues.jboss.org/browse/WFCORE-1262 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: ehsavoie Hugonnet > Priority: Minor > > To change the 'domain-controller' attribute on a host you need to use the custom 'write-local-domain-controller' or 'write-remote-domain-controller' ops. This should also support a standard write-attribute. > It can probably just use a ReloadRequiredWriteAttributeHandler variant as after boot it just triggers a reload, and boot can continue to call the existing custom ops. So just the validation and model manipulation aspect needs to be handled by the write-attribute handler. There's already a proper AttributeDefinition for the attribute to assist in that. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1982) RequestCorrelator: use IntHashMap / LongHashmap for request correlation

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1982?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1982: -------------------------------- There is one big problem: if we have requests {noformat} | R1 | | R2 | R3 | R4 | ... | R999 | R1000 | {noformat} , and responses for {{R2}} - {{R999}} have been received, then the {{low}} pointer won't be advanced until {{R1}} has been received! This means that the table is going to grow, possibly infinitely... The problem occurred in UPerf where starting the benchmark on all cluster nodes involves an initial _blocking_ RPC (non-blocking RPCs don't use {{RequestTable}}), e.g. {{R1}} starts the test on all nodes and waits until it has results from all nodes. Although RequestTables can be compacted, this may use too much memory. E.g. one could come up with a case where an RPC sleeps for 30 minutes (unlikely, but we can't control this!), which prevents the {{low}} point from advancing until the RPC returned, and increase the size of the underlying array in {{RequestTable}}. h3. Solutions * Make users aware of this? Ie. don't use blocking RPCs that don't return for a long time? * Offer both the good old hashmap *and* a {{RequestTable}}? Configure {{RpcDispatcher}} / {{MessageDispatcher}} to switch between the impls? Using {{RequestTable}} reduces memory usage quite a bit and made {{UPerf}} faster, so I'd hate to trash this idea! :-) > RequestCorrelator: use IntHashMap / LongHashmap for request correlation > ----------------------------------------------------------------------- > > Key: JGRP-1982 > URL: https://issues.jboss.org/browse/JGRP-1982 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.7 > > > In RequestCorrelator (and possibly other classes), use an IntHashMap or LongHashmap for the request table. Goal: use less space when we have a lot of requests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2016