[JBoss JIRA] (WFLY-1925) Unclear error message about conflict
by Luca Bueti (JIRA)
[ https://issues.jboss.org/browse/WFLY-1925?page=com.atlassian.jira.plugin.... ]
Luca Bueti commented on WFLY-1925:
----------------------------------
After unsuccessfully trying to preserve module conflicts for the last 4 hours, I found an article on JBoss EAP documentation that explains that override and preserve commands work only for misc files. In my humble opinion, the error message
Use the --override-all, --override=[] or --preserve=[] arguments in order to resolve the conflict.
could be improved to add this useful information (which I couldn't find in wildfly Admin Docs).
> Unclear error message about conflict
> ------------------------------------
>
> Key: WFLY-1925
> URL: https://issues.jboss.org/browse/WFLY-1925
> Project: WildFly
> Issue Type: Bug
> Components: Patching
> Reporter: Jan Martiska
> Assignee: Emanuel Muckenhuber
> Priority: Minor
> Fix For: 8.0.0.CR1
>
>
> {noformat}
> [standalone@localhost:9990 /] patch apply /tmp/7e387d2d-a9de-4537-ad29-6f66ada17e53/77cc1914-21ea-4c9e-b023-d981b3cb80e0.zip
> Conflicts detected: jboss-modules.jar
> {noformat}
> That message doesn't say much. It should say something like 'the hash of xxx has changed, you have probably applied manual changes to xxx. Use --override or --preserve arguments to specify how the conflicts should be dealt with.'
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (JGRP-2110) Transport: revisit buffers and threading
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2110?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2110:
---------------------------
Description:
(Concerns only the receiver side)
h4. Parsing
Currently, parsing is done on the thread which received the message (or message batch) and then the message is passed on to the thread pool. One could argue that the parsing should be done on the thread from the thread pool, and the receiver thread should only fill the buffer and pass it to the thread pool immediately, without doing any parsing, as this might slow it down.
This actually used to be the model which JGroups used, but I abandoned it because (1) performance (IspnPerfTest and UPerf) was the same and (2) we could get rid of a buffer copy (more on this below).
h4. Buffers
* UDP has a fixed buffer of 65K. A datagram packet is read into this buffer and then parsed and passed to the thread pool, allowing the buffer to be reused for the next message.
* TCP: each connection has a buffer which grows according to the length sent in the header of a message. This buffer doesn't need to be copied when passed up the stack, until receive() returns
* TCP_NIO2: each connection also has a buffer which is reused after receive(), but if the read is not complete, is copied.
h4. Approaches
# The receiver thread parses the buffer into a message and passes the message to the thread pool for processing. This requires memory allocation (the new message and its payload buffer). This is the current approach. Parsing the buffer into a message might slow things down as message creation requires memory allocation.
# The receiver thread passes the buffer on to the thread pool where it is parsed. The advantage is that the receiver thread is immediately ready to receive new messages. The disadvantage is that this is 1x memory allocation for the message (as above), although done on a seperate thread, plus 1x memory allocation for copying of the buffer to reuse the original buffer (where necessary, depending on the transport). This was the old way of handling incoming messages.
# UDP: it is possible for the socket receive() method to be called by multiple threads. We could therefore create multiple receiver threads in UDP, to speed things up.
# To prevent memory allocation of the approaches above, we could create a buffer pool. The receiver thread grabs a buffer from the pool (the pool creates a new one when empty?) and fills it with the socket's receive() method, then passes the buffer to the thread pool for processing. If the message's payload buffer points to the original buffer (from the buffer pool), the thread from the thread pool returns the buffer to the buffer pool as soon as the {{receive()}} callback returns, otherwise it returns it as soon as the message has been parsed.
h4. Goals
Prototype approaches 2, 3 and 4 and benchmark them against each other, using UPerf and IspnPerfTest.
was:
(Concerns only the receiver side)
h4. Parsing
Currently, parsing is done on the thread which received the message (or message batch) and then the message is passed on to the thread pool. One could argue that the parsing should be done on the thread from the thread pool, and the receiver thread should only receive fill the buffer and pass it to the thread pool immediately, without doing any parsing, as this might slow it down.
This actually used to be the model which JGroups used, but I abandoned it because (1) performance (IspnPerfTest and UPerf) was the same and (2) we could get rid of a buffer copy (more on this below).
h4. Buffers
* UDP has a fixed buffer of 65K. A datagram packet is read into this buffer and then parsed and passed to the thread pool, allowing the buffer to be reused for the next message.
* TCP: each connection has a buffer which grows according to the length sent in the header of a message. This buffer doesn't need to be copied when passed up the stack, until receive() returns
* TCP_NIO2: each connection also has a buffer which is reused after receive(), but if the read is not complete, is copied.
h4. Approaches
# The receiver thread parses the buffer into a message and passes the message to the thread pool for processing. This requires memory allocation (the new message and its payload buffer). This is the current approach. Parsing the buffer into a message might slow things down as message creation requires memory allocation.
# The receiver thread passes the buffer on to the thread pool where it is parsed. The advantage is that the receiver thread is immediately ready to receive new messages. The disadvantage is that this is 1x memory allocation for the message (as above), although done on a seperate thread, plus 1x memory allocation for copying of the buffer to reuse the original buffer (where necessary, depending on the transport). This was the old way of handling incoming messages.
# UDP: it is possible for the socket receive() method to be called by multiple threads. We could therefore create multiple receiver threads in UDP, to speed things up.
# To prevent memory allocation of the approaches above, we could create a buffer pool. The receiver thread grabs a buffer from the pool (the pool creates a new one when empty?) and fills it with the socket's receive() method, then passes the buffer to the thread pool for processing. If the message's payload buffer points to the original buffer (from the buffer pool), the thread from the thread pool returns the buffer to the buffer pool as soon as the {{receive()}} callback returns, otherwise it returns it as soon as the message has been parsed.
h4. Goals
Prototype approaches 2, 3 and 4 and benchmark them against each other, using UPerf and IspnPerfTest.
> Transport: revisit buffers and threading
> ----------------------------------------
>
> Key: JGRP-2110
> URL: https://issues.jboss.org/browse/JGRP-2110
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> (Concerns only the receiver side)
> h4. Parsing
> Currently, parsing is done on the thread which received the message (or message batch) and then the message is passed on to the thread pool. One could argue that the parsing should be done on the thread from the thread pool, and the receiver thread should only fill the buffer and pass it to the thread pool immediately, without doing any parsing, as this might slow it down.
> This actually used to be the model which JGroups used, but I abandoned it because (1) performance (IspnPerfTest and UPerf) was the same and (2) we could get rid of a buffer copy (more on this below).
> h4. Buffers
> * UDP has a fixed buffer of 65K. A datagram packet is read into this buffer and then parsed and passed to the thread pool, allowing the buffer to be reused for the next message.
> * TCP: each connection has a buffer which grows according to the length sent in the header of a message. This buffer doesn't need to be copied when passed up the stack, until receive() returns
> * TCP_NIO2: each connection also has a buffer which is reused after receive(), but if the read is not complete, is copied.
> h4. Approaches
> # The receiver thread parses the buffer into a message and passes the message to the thread pool for processing. This requires memory allocation (the new message and its payload buffer). This is the current approach. Parsing the buffer into a message might slow things down as message creation requires memory allocation.
> # The receiver thread passes the buffer on to the thread pool where it is parsed. The advantage is that the receiver thread is immediately ready to receive new messages. The disadvantage is that this is 1x memory allocation for the message (as above), although done on a seperate thread, plus 1x memory allocation for copying of the buffer to reuse the original buffer (where necessary, depending on the transport). This was the old way of handling incoming messages.
> # UDP: it is possible for the socket receive() method to be called by multiple threads. We could therefore create multiple receiver threads in UDP, to speed things up.
> # To prevent memory allocation of the approaches above, we could create a buffer pool. The receiver thread grabs a buffer from the pool (the pool creates a new one when empty?) and fills it with the socket's receive() method, then passes the buffer to the thread pool for processing. If the message's payload buffer points to the original buffer (from the buffer pool), the thread from the thread pool returns the buffer to the buffer pool as soon as the {{receive()}} callback returns, otherwise it returns it as soon as the message has been parsed.
> h4. Goals
> Prototype approaches 2, 3 and 4 and benchmark them against each other, using UPerf and IspnPerfTest.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7281) IllegalStateException: DummyTransaction is not in a valid state to be invoking cache operations on
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-7281?page=com.atlassian.jira.plugin.... ]
Paul Ferraro moved JBEAP-6365 to WFLY-7281:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7281 (was: JBEAP-6365)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
(was: Clustering)
Affects Version/s: 10.1.0.Final
(was: 7.1.0.DR5)
> IllegalStateException: DummyTransaction is not in a valid state to be invoking cache operations on
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-7281
> URL: https://issues.jboss.org/browse/WFLY-7281
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> Occured on server during scenario eap-7x-failover-http-granular-shutdown-repl-sync.
> Server log stacktrace:
> {code}
> 23:04:41,857 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-97) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=19027}, status=1} is not in a valid state to be invoking cache operations on.
> [JBossINF] at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:395)
> [JBossINF] at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:351)
> [JBossINF] at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:345)
> [JBossINF] at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:331)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.visitReadCommand(StateTransferInterceptor.java:177)
> [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.visitGetKeyValueCommand(StateTransferInterceptor.java:154)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:114)
> [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:83)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335)
> [JBossINF] at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
> [JBossINF] at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:403)
> [JBossINF] at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.fine.FineImmutableSessionAttributes.getAttribute(FineImmutableSessionAttributes.java:59)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.lambda$findListeners$13(InfinispanSessionManager.java:406)
> [JBossINF] at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> [JBossINF] at java.util.concurrent.ConcurrentHashMap$KeySpliterator.forEachRemaining(ConcurrentHashMap.java:3527)
> [JBossINF] at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> [JBossINF] at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> [JBossINF] at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> [JBossINF] at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> [JBossINF] at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:406)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPrePassivationEvents(InfinispanSessionManager.java:389)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$SchedulableSession.close(InfinispanSessionManager.java:457)
> [JBossINF] at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:80)
> [JBossINF] at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:814)
> [JBossINF] at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:572)
> [JBossINF] at io.undertow.servlet.spec.HttpServletResponseImpl.doErrorDispatch(HttpServletResponseImpl.java:171)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:327)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> [JBossINF] at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> [JBossINF] at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> [JBossINF] at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> {code}
> Link to server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-http-...
> WARN occured on client at the same time:
> {code}
> 2016/09/21 23:04:41:857 EDT [WARN ][Runner - 1402] HOST dev220.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Invalid response code: 500 Content: <html><head><title>Error</title></head><body>Internal Server Error</body></html>>
> org.jboss.smartfrog.loaddriver.RequestProcessingException: Invalid response code: 500 Content: <html><head><title>Error</title></head><body>Internal Server Error</body></html>
> at org.jboss.smartfrog.loaddriver.http.HttpRequestProcessorFactoryImpl$HttpRequestProcessor.processRequest(HttpRequestProcessorFactoryImpl.java:163)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Link to client log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-http-...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7280) getSession() Always Creating HttpSession Problem
by kin zhu (JIRA)
kin zhu created WFLY-7280:
-----------------------------
Summary: getSession() Always Creating HttpSession Problem
Key: WFLY-7280
URL: https://issues.jboss.org/browse/WFLY-7280
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 10.1.0.Final
Environment: jdk8u102, win7x64, wildfly-servlet-10.1.0.Final.tar.gz
Reporter: kin zhu
Assignee: Stuart Douglas
I have a login application called cas.war. I store the captcha code in session. This application has been running smoothly in JBoss7 and Tomcat7. But when I tried to migrate to wildfly10, I found the captcha code will always be null. I dug a little deeper, and found out that the server is creating new session each time I post a request(the JSESSIONID cookie changes on every request). I traced the code and pinned down the problem on this location (as of undertow-servlet-1.4.0.Final-sources.jar ) :
{color:#f6c342}io.undertow.servlet.spec.ServletContextImpl.java, method getSession:{color}
{code:java}
public HttpSessionImpl getSession(final ServletContextImpl originalServletContext, final HttpServerExchange exchange, boolean create) {
SessionConfig c = originalServletContext.getSessionConfig();
HttpSessionImpl httpSession = exchange.getAttachment(sessionAttachmentKey);
{code}
while
sessionAttachmentKey = {color:#f6c342}io.undertow.util.SimpleAttachmentKey<io.undertow.servlet.spec.HttpSessionImpl>{color}
the exchange.attachments map will only contain one such key: {color:#f6c342}io.undertow.util.SimpleAttachmentKey<io.undertow.server.session.InMemorySessionManager$SessionImpl>{color}
thus the server will create new session once request.getSession() is called, regardless one session exist or not.
And please have a look at the relate class InMemorySessionManager too.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-5239) XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-5239?page=com.atlassian.jira.plugin.... ]
Petr Kremensky commented on WFLY-5239:
--------------------------------------
Yep, that's exactly what I was going to do, thanks for the assistance.
> XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5239
> URL: https://issues.jboss.org/browse/WFLY-5239
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.Beta2
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 11.0.0.Alpha1
>
>
> I have done some work to stabilize this test a little more by switching both stacks (default stack and the bridge stack) to tcp. This does not help the test completely, it still fails with the well known:
> {noformat}
> rhusar &#27;[0m&#27;[0m15:14:52,808 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0010: Deployed "xsite.war" (runtime-name : "xsite.war")
> &#27;[0mExecuting HTTP request: http://[::1]:8080/xsite/cache?operation=put&key=a&value=100
> &#27;[33m15:14:53,513 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:14:55,581 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:14:57,583 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:14:59,584 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:15:01,585 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:15:03,277 WARN [org.infinispan.xsite.BackupSenderImpl] (default task-1) ISPN000202: Problems backing up data for cache dist to site NYC: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from NYC (sync, timeout=10000)
> &#27;[0mExecuted HTTP request
> &#27;[33m15:15:03,586 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:15:05,591 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message 17:02
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFCORE-1860) Upgrade to jandex 2.0.3
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFCORE-1860:
-----------------------------------
Summary: Upgrade to jandex 2.0.3
Key: WFCORE-1860
URL: https://issues.jboss.org/browse/WFCORE-1860
Project: WildFly Core
Issue Type: Feature Request
Components: Server
Reporter: Tomaz Cerar
Assignee: Tomaz Cerar
Jandex 2.0.3 changes are used by Weld 2.4.0.Final and it complains a bit if they are not present.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months