[JBoss JIRA] (JGRP-1989) Bundlers: reuse send buffer when transport == sync.
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1989?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1989 at 12/3/15 4:51 AM:
---------------------------------------------------------
Another alternative is to always send the reusable buffer and copy at the {{TCP_NIO2}} level *if needed*. For example, if a write of 1000 bytes succeeds, then we know that 1000 bytes have been written and the buffer can get reused.
If the write returns rc=800, then we know that we still need to write the final 200 bytes. In this case, we could *copy* the bytes in range {{buf[801..1000]}}. I assume that a TCP write would succeed in most cases, so this would not do a lot of copying.
Downside: an NIO write is done deep inside JGroups NIO ({{NioConnection}}), so we'd have to let this class somehow know whether or not to copy data. For instance, if a user always provides copied data in the first place, there'd be no need o copy at all.
was (Author: belaban):
Another alternative is to always send the reusable buffer and copy at the {{TCP_NIO2}} level *if needed*. For example, if a write of 1000 bytes succeeds than we know that 1000 bytes have been written and the buffer can get reused.
If the write returns rc=800, then we know that we still need to write the final 200 bytes. In this case, we could *copy* the bytes in range {{buf[801..1000]}}. I assume that a TCP write would succeed in most cases, so this would not do a lot of copying.
Downside: an NIO write is done deep inside JGroups NIO ({{NioConnection}}), so we'd have to let this class somehow know whether or not to copy data. For instance, if a user always provides copied data in the first place, there'd be no need o copy at all.
> Bundlers: reuse send buffer when transport == sync.
> ---------------------------------------------------
>
> Key: JGRP-1989
> URL: https://issues.jboss.org/browse/JGRP-1989
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> With the addition of {{TCP_NIO2}}, all bundlers now create new send buffers for every message (or message list). This generates a lot of memory allocations, perhaps it is better to revert this change for *synchronous transports* such as {{UDP}} and {{TCP}}, and still create new buffers for *asynchronous transports* such as {{TCP_NIO2}}.
> Synchronous transports guarantee a message has been put on the wire when {{TP.send()}} returns, whereas asynchronous transports may only have completed a partial write (so we cannot reuse the buffer).
> The code in the bundler should check for this, and copy if async or not copy if sync.
> Whether or not a transport is sync is determined by a new abstract method that needs to be overridden by every transport.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (JGRP-1989) Bundlers: reuse send buffer when transport == sync.
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1989?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1989 at 12/3/15 4:50 AM:
---------------------------------------------------------
If we use TCP, for instance and have no max_bundle_size, then we can get real huge buffers. This doesn't normally happen though, so perhaps - as you mentioned - I'll go with a copy for buffers greater than some predefined max size.
was (Author: belaban):
If we use TCP, for instance and have no max_bundle_size, then we can get real huge buffers. This doesn't noramlly happen though, so perhaps - as you mentioned - I'll go with a copy for buffers greater than some predefined max size.
> Bundlers: reuse send buffer when transport == sync.
> ---------------------------------------------------
>
> Key: JGRP-1989
> URL: https://issues.jboss.org/browse/JGRP-1989
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> With the addition of {{TCP_NIO2}}, all bundlers now create new send buffers for every message (or message list). This generates a lot of memory allocations, perhaps it is better to revert this change for *synchronous transports* such as {{UDP}} and {{TCP}}, and still create new buffers for *asynchronous transports* such as {{TCP_NIO2}}.
> Synchronous transports guarantee a message has been put on the wire when {{TP.send()}} returns, whereas asynchronous transports may only have completed a partial write (so we cannot reuse the buffer).
> The code in the bundler should check for this, and copy if async or not copy if sync.
> Whether or not a transport is sync is determined by a new abstract method that needs to be overridden by every transport.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-5682) Can't define absolute path for object store location
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5682?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka commented on WFLY-5682:
----------------------------------------
Thanks for explanation [~bstansberry] and [~zhfeng] I do understand reasons and that I was wrong about understanding {{object-store-relative-to}} attribute.
To be honest what I do not understand is if the initial issue could be resolved for EAP7.
I mean could be possible to to give users ability to define transaction object store path by an absolute location? Even when model and compatibility would not be broken? Or all this have to be moved to let say EAP 7.1 and the JBEAP-1913 has to be marked as known issue for EAP7?
> Can't define absolute path for object store location
> ----------------------------------------------------
>
> Key: WFLY-5682
> URL: https://issues.jboss.org/browse/WFLY-5682
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 10.0.0.CR4
> Reporter: Ondřej Chaloupka
> Assignee: Amos Feng
> Fix For: 10.0.0.CR5
>
>
> As trying to set absolute path for location of transaction log store I've got to suspicion that's not possible.
> If I try to set `object-store-relative-to` to some absolute path or set `object-store-relative-to` to empty string and then `object-store-path` to some absolute path the server starts with exceptions [1][2].
> [1]
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.txn.ArjunaObjectStoreEnvironment: org.jboss.msc.service.StartException in service jboss.txn.ArjunaObjectStoreEnvironment: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) 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)Caused by: java.lang.IllegalArgumentException: WFLYCTL0256: Could not find a path called '/home/ochaloup/tmp/'
> at org.jboss.as.controller.services.path.PathManagerService.resolveRelativePathEntry(PathManagerService.java:87) at org.jboss.as.txn.service.ArjunaObjectStoreEnvironmentService.start(ArjunaObjectStoreEnvironmentService.java:76)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ...
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "transactions")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.txn.ArjunaObjectStoreEnvironment" => "org.jboss.msc.service.StartException in service jboss.txn.ArjunaObjectStoreEnvironment: Failed to start service
> Caused by: java.lang.IllegalArgumentException: WFLYCTL0256: Could not find a path called '/home/ochaloup/tmp/'"}}
> INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status reportWFLYCTL0186: Services which failed to start: service jboss.txn.ArjunaObjectStoreEnvironment: org.jboss.msc.service.StartException in service jboss.txn.ArjunaObjectStoreEnvironment: Failed to start service
> {code}
> [2]
> {code}
> ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
> at org.jboss.as.server.ServerService.boot(ServerService.java:356) at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[348,13]
> Message: "WFLYCTL0113: '' is an invalid value for parameter relative-to. Values must have a minimum length of 1 characters"
> at org.jboss.as.controller.SimpleAttributeDefinition.parse(SimpleAttributeDefinition.java:161) at org.jboss.as.controller.SimpleAttributeDefinition.parseAndSetParameter(SimpleAttributeDefinition.java:186)
> at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.parseObjectStoreEnvironmentElementAndEnrichOperation(TransactionSubsystem14Parser.java:205)
> at org.jboss.as.txn.subsystem.TransactionSubsystem30Parser.readElement(TransactionSubsystem30Parser.java:67) at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.readElement(TransactionSubsystem14Parser.java:111)
> at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.readElement(TransactionSubsystem14Parser.java:54) at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) at org.jboss.as.server.parsing.StandaloneXml_4.parseServerProfile(StandaloneXml_4.java:547)
> at org.jboss.as.server.parsing.StandaloneXml_4.readServerElement(StandaloneXml_4.java:244) at org.jboss.as.server.parsing.StandaloneXml_4.readElement(StandaloneXml_4.java:143)
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:69) at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:47) at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
> ... 3 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ELY-386) Unable to create HTTPS connection when some opnessl cipher suite with DHE are used
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-386?page=com.atlassian.jira.plugin.sy... ]
Martin Choma moved JBEAP-2126 to ELY-386:
-----------------------------------------
Project: WildFly Elytron (was: JBoss Enterprise Application Platform)
Key: ELY-386 (was: JBEAP-2126)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: SSL
(was: Security)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 1.0.2.Final
(was: 7.0.0.ER2 (Beta))
> Unable to create HTTPS connection when some opnessl cipher suite with DHE are used
> ----------------------------------------------------------------------------------
>
> Key: ELY-386
> URL: https://issues.jboss.org/browse/ELY-386
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Affects Versions: 1.0.2.Final
> Environment: Oracle java 1.8.0_66
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
>
> Can't configure OpenSSL cipher suites EXP-DHE-RSA-DES-CBC-SHA, DHE-RSA-DES-CBC-SHA, DHE-RSA-DES-CBC3-SHA, EXP-DHE-DSS-DES-CBC-SHA, DHE-DSS-CBC-SHA, DHE-DSS-DES-CBC3-SHA [1] for HTTPS connection. Seems like everlasting problem DHE vs. EDH [2] - these cipher suites don't work neither in EAP6. IMHO problem is in MechanismDatabase.properties, where these DHE cipher suite are mapped to openssl EDH cipher suite what contradict openssl documentation [1]:
> {code}
> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = alias:TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
> SSL_DHE_RSA_WITH_DES_CBC_SHA = alias:TLS_DHE_RSA_WITH_DES_CBC_SHA
> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA = alias:TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
> TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = EXP-EDH-RSA-DES-CBC-SHA,DHE,RSA,DES,SHA1,SSLv3,true,EXP40,false,40,56
> TLS_DHE_RSA_WITH_DES_CBC_SHA = EDH-RSA-DES-CBC-SHA,DHE,RSA,DES,SHA1,SSLv3,false,LOW,false,56,56
> TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = EDH-RSA-DES-CBC3-SHA,DHE,RSA,3DES,SHA1,SSLv3,false,HIGH,true,168,168
> SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = EXP-EDH-DSS-DES-CBC-SHA,DHE,DSS,DES,SHA1,SSLv3,true,EXP40,false,40,56
> SSL_DHE_DSS_WITH_DES_CBC_SHA = EDH-DSS-DES-CBC-SHA,DHE,DSS,DES,SHA1,SSLv3,false,LOW,false,56,56
> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA = EDH-DSS-DES-CBC3-SHA,DHE,DSS,3DES,SHA1,SSLv3,false,HIGH,true,168,168
> {code}
> Note that MechanismDatabase.properties is inconsistent in mapping DHE cipher suites to openssl cipher suites, as there also exist couple of them which map DHE to DHE, for example
> {code}
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = DHE-RSA-AES128-SHA256,DHE,RSA,AES128,SHA256,TLSv1.2,false,HIGH,true,128,128
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = DHE-RSA-AES256-SHA256,DHE,RSA,AES256,SHA256,TLSv1.2,false,HIGH,true,256,256
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = DHE-RSA-AES128-GCM-SHA256,DHE,RSA,AES128GCM,AEAD,TLSv1.2,false,HIGH,true,128,128
> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = DHE-RSA-AES256-GCM-SHA384,DHE,RSA,AES256GCM,AEAD,TLSv1.2,false,HIGH,true,256,256
> {code}
> In MechanismDatabase.properties is also said that
> ??Note that all EDH ciphers automatically get a DHE OpenSSL-style alias (and vice-versa)??
> I think this JIRA contradict this comment.
> Last thing, based on [1] shouldn't be SSL_DHE_DSS_WITH_DES_CBC_SHA defined as
> SSL_DHE_DSS_WITH_DES_CBC_SHA = DHE-DSS-CBC-SHA,DHE,DSS,DES,SHA1,SSLv3,false,LOW,false,56,56
> ?
> [1] https://www.openssl.org/docs/manmaster/apps/ciphers.html#CIPHER-SUITE-NAMES
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1123304
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-5766) ManagedExecutorService's max-threads attribute is not honored if an unbounded queue is used
by Jan Martiska (JIRA)
[ https://issues.jboss.org/browse/WFLY-5766?page=com.atlassian.jira.plugin.... ]
Jan Martiska moved JBEAP-2124 to WFLY-5766:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-5766 (was: JBEAP-2124)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: EE
(was: Concurrency Utilities)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 10.0.0.CR4
(was: 7.0.0.ER2 (Beta))
> ManagedExecutorService's max-threads attribute is not honored if an unbounded queue is used
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-5766
> URL: https://issues.jboss.org/browse/WFLY-5766
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 10.0.0.CR4
> Reporter: Jan Martiska
> Assignee: Eduardo Martins
>
> If you set a max-threads attribute to a managed-executor-service and the number is higher than core-threads, and its queue is unbounded (queue-length is undefined), it won't use any more threads than the number from core-threads.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-5765) Data source connection-properties is defined as an attribute and a sub-resource
by James Perkins (JIRA)
James Perkins created WFLY-5765:
-----------------------------------
Summary: Data source connection-properties is defined as an attribute and a sub-resource
Key: WFLY-5765
URL: https://issues.jboss.org/browse/WFLY-5765
Project: WildFly
Issue Type: Bug
Components: JCA
Reporter: James Perkins
Assignee: Jesper Pedersen
Priority: Critical
The {{subsystem=datasource/data-source=*}} resource has a {{connection-properties}} attribute and a {{connection-properties}} sub-resource. Since DMR is a tree structure each child must have a unique key. Since the parent resource has a {{connection-properties}} attribute and sub-resource with a {{read-resource}} operation you will only get one of the values.
Also writing to the {{connection-properties}} attribute fails to marshal the XML since marshaller expects the value to look something like
{code}
{ "key" => { "value" => "real-value" } }
{code}
But the resource definition expects
{code}
{ "key" => "real-value" }
{code}
The attribute does not appear to be in EAP 6.4. It is however in WildFly 8.x and 9.x. Some further research should be done, but the attribute could likely be removed. Not having the attribute would also be more consistent with XA data sources.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFCORE-889) Kerberos authentication for Management CLI should fallback when server principal is set incorrectly
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-889?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-889:
------------------------------------
Fix Version/s: 2.0.4.Final
(was: 2.0.3.Final)
> Kerberos authentication for Management CLI should fallback when server principal is set incorrectly
> ---------------------------------------------------------------------------------------------------
>
> Key: WFCORE-889
> URL: https://issues.jboss.org/browse/WFCORE-889
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Fix For: 2.0.4.Final
>
>
> In case when kerberos authentication is configured in security realm but principal attribute in keytab element is set incorrectly (e.g. remote/wrong_localhost(a)JBOSS.ORG, remote/localhost(a)WRONG_JBOSS.ORG or wrong_remote/localhost(a)JBOSS.ORG instead of remote/localhost(a)JBOSS.ORG) then authentication does not fallback into another authentication mechanism for user with valid kerberos ticket. In case when user does not have kerberos ticket then fallback is taken into account correctly.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months