[JBoss JIRA] (WFLY-7322) LDAP referrals does not work in Elytron ldap-realm
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7322?page=com.atlassian.jira.plugin.... ]
Jan Kalina commented on WFLY-7322:
----------------------------------
[~dlofthouse] Do we need *throw* mode of LDAP referrals support? If we will follow every referral, it will be equivalent of *follow* mode.
> LDAP referrals does not work in Elytron ldap-realm
> --------------------------------------------------
>
> Key: WFLY-7322
> URL: https://issues.jboss.org/browse/WFLY-7322
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
>
> LDAP referrals cannot be used in Elytron {{ldap-realm}}. Ldap Realm is currently not prepared to work with referrals at all:
> * {{ldap-realm}} does not include any options which enable working with LDAP referrals (PicketBox use {{baseFilter}} option which can be configured to return also referral object)
> * implementation of {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm}} does not include any logic which handles referrals
> Referrals are important feature of LDAP. It has to be covered by Elytron => requested blocker flag.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFCORE-1909) Tab completion causes NUL characters ('\0') to be injected...sometimes
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1909?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise moved WFLY-7398 to WFCORE-1909:
----------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1909 (was: WFLY-7398)
Component/s: CLI
(was: CLI)
> Tab completion causes NUL characters ('\0') to be injected...sometimes
> ----------------------------------------------------------------------
>
> Key: WFCORE-1909
> URL: https://issues.jboss.org/browse/WFCORE-1909
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: David Lloyd
> Assignee: Jean-Francois Denise
> Priority: Critical
>
> I noticed while testing my subsystem that sometimes using tab-complete on an attribute causes NUL ('\0') characters to be injected into the input. These characters are invisible on the screen but cause XML marshalling to fail as that character is forbidden.
> My "less" output of .jboss-cli-history looks something like this:
> {noformat}
> embed-server --std-out=echo
> cd subsystem=discovery
> ./static-provider=test:add(services=[{uri=^@^@"local", abstract-type="ejb", abstract-type-authority="jboss"}])
> ./static-provider=test4:add(services=[{uri="local", abstract-type="ejb", abstract-type-authority="jboss"}])
> {noformat}
> In the first "test:add" case I used tab-completion; in the second "test4:add" case I typed it out by hand. The "^@" are in inverse video in less, indicating a NUL character.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFCORE-1908) Tab completion suggest writing attribute which has access type metric and is not writable
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1908?page=com.atlassian.jira.plugi... ]
Chao Wang moved JBEAP-6715 to WFCORE-1908:
------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1908 (was: JBEAP-6715)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CLI
(was: CLI)
(was: User Experience)
Affects Version/s: 3.0.0.Alpha11
(was: 7.1.0.DR7)
> Tab completion suggest writing attribute which has access type metric and is not writable
> -----------------------------------------------------------------------------------------
>
> Key: WFCORE-1908
> URL: https://issues.jboss.org/browse/WFCORE-1908
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 3.0.0.Alpha11
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Minor
>
> CLI tab completion suggests attributes that are not writable and their access-type is {{metric}}
> Example {code}
> /subsystem=messaging-activemq/server=default/jms-queue=DLQ:write-attribute(name=<TAB>
> consumer-count delivering-count entries legacy-entries message-count messages-added scheduled-count
> {code}
> From executing {{:read-resource-description}} we can see, attributes consumer-count, delivering-count, message-count, messages-added, scheduled-count are of type metric.
> On attempt to write metric attribute, for example message-count, non writable error is printed {code}
> [standalone@localhost:9990 jms-queue=q] :write-attribute(name=message-count, value=5)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0048: Attribute message-count is not writable",
> "rolled-back" => true
> }
> {code}
> CLI should not suggest writing attributes that are not writable.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFLY-5029) Reintroduce EJB, JMS, JNDI over HTTP/HTTPS capability with HTTP Loadbalancer
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5029?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-5029:
------------------------------------
Assignee: Stuart Douglas (was: Jason Greene)
> Reintroduce EJB, JMS, JNDI over HTTP/HTTPS capability with HTTP Loadbalancer
> ----------------------------------------------------------------------------
>
> Key: WFLY-5029
> URL: https://issues.jboss.org/browse/WFLY-5029
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB, Server, Web (Undertow)
> Affects Versions: 11.0.0.Alpha1
> Reporter: Bilge Ozpeynirci
> Assignee: Stuart Douglas
>
> Ability to run EJB, JMS, JNDI over HTTP/HTTPS which was possible in earlier JBoss AS/EAP 5 & 4.
> User will be able to do 1:1 EJB invocation to HTTP request, so that HTTP requests (that carry EJB Load) can be load balanced at the request level instead of at the connection level.
> 1:1 mapping of EJB invocation to an HTTP request will be possible. This way, a hardware HTTP LB or Undertow Load Balancer or HTTPD Load Balancer can balance the requests according to a custom LB policy. In this case; the EJB clustering will not have to be configured.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFLY-7364) java.lang.IllegalArgumentException: UT000068: Servlet path match failed
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7364?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-7364.
----------------------------------
Resolution: Rejected
> java.lang.IllegalArgumentException: UT000068: Servlet path match failed
> -----------------------------------------------------------------------
>
> Key: WFLY-7364
> URL: https://issues.jboss.org/browse/WFLY-7364
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Reporter: william teskey
> Assignee: Stuart Douglas
> Priority: Minor
>
> [0m[31m16:24:45,861 ERROR [io.undertow.request] (default I/O-6) UT005071: Undertow request failed HttpServerExchange{ GET china2000fineart.com request {Accept=[*/*], User-Agent=[Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36], Referer=[http://china2000fineart.com], Host=[china2000fineart.com]} response {}}: java.lang.IllegalArgumentException: UT000068: Servlet path match failed
> at io.undertow.servlet.handlers.ServletPathMatchesData.getServletHandlerByPath(ServletPathMatchesData.java:83)
> at io.undertow.servlet.handlers.ServletPathMatches.getServletHandlerByPath(ServletPathMatches.java:83)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleRequest(ServletInitialHandler.java:151)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:39)
> at io.undertow.server.handlers.HttpContinueReadHandler.handleRequest(HttpContinueReadHandler.java:65)
> at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:94)
> at org.wildfly.extension.undertow.Host$OptionsHandler.handleRequest(Host.java:295)
> at io.undertow.server.handlers.HttpContinueReadHandler.handleRequest(HttpContinueReadHandler.java:65)
> at org.wildfly.extension.undertow.Host$HostRootHandler.handleRequest(Host.java:303)
> at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:54)
> at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78)
> at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
> at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:128)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFLY-7418) Batch deployments with a large number of executed jobs can lock up or slow down the web console
by Harald Pehl (JIRA)
[ https://issues.jboss.org/browse/WFLY-7418?page=com.atlassian.jira.plugin.... ]
Harald Pehl commented on WFLY-7418:
-----------------------------------
One workaround could be to open another tab, browser window or different browser to avoid blocking the rest of the management console. Not sure if that works out, though. Another option could be the use of web workers [1], but that would need more analysis and would be something to consider for HAL.next.
Apart from that I don't have other solutions atm.
[1] https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_we...
> Batch deployments with a large number of executed jobs can lock up or slow down the web console
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-7418
> URL: https://issues.jboss.org/browse/WFLY-7418
> Project: WildFly
> Issue Type: Enhancement
> Components: Batch, Web Console
> Reporter: James Perkins
> Assignee: James Perkins
>
> Batch deployments which contain a large number of executed jobs can be extremely slow to process as the {{/deployment=batch.war/subsystem=batch-jberet}} processes each job instance then each job execution of that job instance.
> One possibly helpful option for the web console would be to add a new description attribute to indicate the resource may be slow to process. The web console might be able to run a background task to populate data rather than locking up the UI. There would still be an issue with a large memory footprint here however.
> JBeret might want to consider having a way to archive jobs too rather than just purge them. Some users may want to keep all job execution data. Archiving this data could reduce the size of the current data being retrieved.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFLY-7374) WildFfly openssl requires glibc 2.14 resulting in failure when starting on RHEL 6
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7374?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-7374.
----------------------------------
Fix Version/s: 11.0.0.Alpha1
Resolution: Done
> WildFfly openssl requires glibc 2.14 resulting in failure when starting on RHEL 6
> ---------------------------------------------------------------------------------
>
> Key: WFLY-7374
> URL: https://issues.jboss.org/browse/WFLY-7374
> Project: WildFly
> Issue Type: Bug
> Components: Security, Server, Web (Undertow)
> Reporter: Radim Hatlapatka
> Assignee: Stuart Douglas
> Priority: Blocker
> Labels: wildfly-openssl
> Fix For: 11.0.0.Alpha1
>
>
> When starting EAP on RHEL 6 it shows ERROR messages when loading openssl \[1\]. This is caused by the wrapper requiring glibc 2.14 or newer but on RHEL 6 (RHEL 6.7) there is only glibc 2.12.
> As there should be no ERROR messages during EAP start with default configuration, marking as blocker.
> \[1\]
> {noformat}
> 11:20:42,474 ERROR [stderr] (MSC service thread 1-3) java.lang.reflect.InvocationTargetException
> 11:20:42,476 ERROR [stderr] (MSC service thread 1-3) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 11:20:42,479 ERROR [stderr] (MSC service thread 1-3) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 11:20:42,481 ERROR [stderr] (MSC service thread 1-3) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 11:20:42,494 ERROR [stderr] (MSC service thread 1-3) at java.lang.reflect.Method.invoke(Method.java:498)
> 11:20:42,495 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.openssl.SSL.init(SSL.java:73)
> 11:20:42,496 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.openssl.SSL.getInstance(SSL.java:49)
> 11:20:42,497 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.openssl.OpenSSLEngine.<clinit>(OpenSSLEngine.java:59)
> 11:20:42,497 ERROR [stderr] (MSC service thread 1-3) at java.lang.Class.forName0(Native Method)
> 11:20:42,498 ERROR [stderr] (MSC service thread 1-3) at java.lang.Class.forName(Class.java:348)
> 11:20:42,499 ERROR [stderr] (MSC service thread 1-3) at io.undertow.protocols.alpn.OpenSSLAlpnProvider$1.run(OpenSSLAlpnProvider.java:47)
> 11:20:42,505 ERROR [stderr] (MSC service thread 1-3) at io.undertow.protocols.alpn.OpenSSLAlpnProvider$1.run(OpenSSLAlpnProvider.java:43)
> 11:20:42,508 ERROR [stderr] (MSC service thread 1-3) at java.security.AccessController.doPrivileged(Native Method)
> 11:20:42,516 ERROR [stderr] (MSC service thread 1-3) at io.undertow.protocols.alpn.OpenSSLAlpnProvider.<clinit>(OpenSSLAlpnProvider.java:43)
> 11:20:42,517 ERROR [stderr] (MSC service thread 1-3) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:20:42,524 ERROR [stderr] (MSC service thread 1-3) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:20:42,525 ERROR [stderr] (MSC service thread 1-3) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:20:42,539 ERROR [stderr] (MSC service thread 1-3) at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> 11:20:42,540 ERROR [stderr] (MSC service thread 1-3) at java.lang.Class.newInstance(Class.java:442)
> 11:20:42,541 ERROR [stderr] (MSC service thread 1-3) at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380)
> 11:20:42,542 ERROR [stderr] (MSC service thread 1-3) at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
> 11:20:42,542 ERROR [stderr] (MSC service thread 1-3) at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
> 11:20:42,543 ERROR [stderr] (MSC service thread 1-3) at io.undertow.protocols.alpn.ALPNManager.<init>(ALPNManager.java:40)
> 11:20:42,548 ERROR [stderr] (MSC service thread 1-3) at io.undertow.protocols.alpn.ALPNManager.<clinit>(ALPNManager.java:35)
> 11:20:42,550 ERROR [stderr] (MSC service thread 1-3) at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:64)
> 11:20:42,551 ERROR [stderr] (MSC service thread 1-3) at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:83)
> 11:20:42,552 ERROR [stderr] (MSC service thread 1-3) at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:75)
> 11:20:42,553 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.extension.undertow.HttpsListenerService.createAlpnOpenListener(HttpsListenerService.java:101)
> 11:20:42,557 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.extension.undertow.HttpsListenerService.createOpenListener(HttpsListenerService.java:86)
> 11:20:42,572 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:158)
> 11:20:42,581 ERROR [stderr] (MSC service thread 1-3) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> 11:20:42,582 ERROR [stderr] (MSC service thread 1-3) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> 11:20:42,590 ERROR [stderr] (MSC service thread 1-3) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 11:20:42,591 ERROR [stderr] (MSC service thread 1-3) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 11:20:42,593 ERROR [stderr] (MSC service thread 1-3) at java.lang.Thread.run(Thread.java:745)
> 11:20:42,595 ERROR [stderr] (MSC service thread 1-3) Caused by: java.lang.UnsatisfiedLinkError: /tmp/tmp-2717760086872143296openssl/libwfssl.so: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /tmp/tmp-2717760086872143296openssl/libwfssl.so)
> 11:20:42,596 ERROR [stderr] (MSC service thread 1-3) at java.lang.ClassLoader$NativeLibrary.load(Native Method)
> 11:20:42,597 ERROR [stderr] (MSC service thread 1-3) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
> 11:20:42,598 ERROR [stderr] (MSC service thread 1-3) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1837)
> 11:20:42,610 ERROR [stderr] (MSC service thread 1-3) at java.lang.Runtime.loadLibrary0(Runtime.java:870)
> 11:20:42,611 ERROR [stderr] (MSC service thread 1-3) at java.lang.System.loadLibrary(System.java:1122)
> 11:20:42,619 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:180)
> 11:20:42,620 ERROR [stderr] (MSC service thread 1-3) ... 34 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFLY-7364) java.lang.IllegalArgumentException: UT000068: Servlet path match failed
by william teskey (JIRA)
[ https://issues.jboss.org/browse/WFLY-7364?page=com.atlassian.jira.plugin.... ]
william teskey commented on WFLY-7364:
--------------------------------------
It looks like I inadvertently removed the default servlet. I have restored what I believe to be it.
> java.lang.IllegalArgumentException: UT000068: Servlet path match failed
> -----------------------------------------------------------------------
>
> Key: WFLY-7364
> URL: https://issues.jboss.org/browse/WFLY-7364
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Reporter: william teskey
> Assignee: Stuart Douglas
> Priority: Minor
>
> [0m[31m16:24:45,861 ERROR [io.undertow.request] (default I/O-6) UT005071: Undertow request failed HttpServerExchange{ GET china2000fineart.com request {Accept=[*/*], User-Agent=[Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36], Referer=[http://china2000fineart.com], Host=[china2000fineart.com]} response {}}: java.lang.IllegalArgumentException: UT000068: Servlet path match failed
> at io.undertow.servlet.handlers.ServletPathMatchesData.getServletHandlerByPath(ServletPathMatchesData.java:83)
> at io.undertow.servlet.handlers.ServletPathMatches.getServletHandlerByPath(ServletPathMatches.java:83)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleRequest(ServletInitialHandler.java:151)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:39)
> at io.undertow.server.handlers.HttpContinueReadHandler.handleRequest(HttpContinueReadHandler.java:65)
> at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:94)
> at org.wildfly.extension.undertow.Host$OptionsHandler.handleRequest(Host.java:295)
> at io.undertow.server.handlers.HttpContinueReadHandler.handleRequest(HttpContinueReadHandler.java:65)
> at org.wildfly.extension.undertow.Host$HostRootHandler.handleRequest(Host.java:303)
> at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:54)
> at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78)
> at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
> at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:128)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months