[jira] [Created] (DISPATCH-753) Neither version of console is able to connect on Internet Explorer 10
Jiri Danek created DISPATCH-753:
---
Summary: Neither version of console is able to connect on Internet
Explorer 10
Key: DISPATCH-753
URL: https://issues.apache.org/jira/browse/DISPATCH-753
Project: Qpid Dispatch
Issue Type: Bug
Components: Console
Environment: Windows 7, Internet Explorer 10 (running in a virtual
machine provided at
https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/)
Reporter: Jiri Danek
This is a complete console output from Hawtio version on WIndows 7 and Internet
Explorer 10
{noformat}
SCRIPT1002: Syntax error
hawtio, line 955 character 19
[Window] Syntax error (:955:19)
[PluginLoader] Failed loading script: "Could not complete the operation due to
error 80020101." (/dispatch-hawtio-console/plugin/js/qdrOverview.js:undefined)
SCRIPT1006: Expected ')'
hawtio, line 492 character 45
[Window] Expected ')' (:492:45)
[PluginLoader] Failed loading script: "Could not complete the operation due to
error 80020101." (/dispatch-hawtio-console/plugin/js/qdrTopology.js:undefined)
[Themes] unknown theme name, using default theme
[QDR] *creating Dispatch Console
[QDR] curPath is /
[Core] hawtio started
[RBAC] Using mbean
hawtio:type=security,area=jmx,rank=0,name=HawtioDummyJMXSecurity for
client-side role based access control
XML5632: Only one root element is allowed.
, line 3 character 2
[QDR] okay to start
[QDR] [
"amqp:/_topo/0/Router.A/$management"
]
[QDR] {
"amqp:/_topo/0/Router.A/$management": {}
}
[QDR] saving page changed to /dispatch_hawtio_console/overview
Error: Error: Argument 'QDR.OverviewController' is not a function, got
undefined
Stack trace:
Error: Argument 'QDR.OverviewController' is not a function, got undefined
at _ (http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:13:8946)
at aa
(http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:13:9037)
at Anonymous function
(http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:13:28890)
at Anonymous function
(http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:13:24327)
at f (http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:13:3544)
at n
(http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:13:24131)
at f
(http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:13:22086)
at Anonymous function
(http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:13:21616)
at k
(http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:15:22785)
at $broadcast
(http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:14:17750)
{noformat}
This is complete output from stand-alone version on the same system Windows 7
and Internet Explorer 10
{noformat}
SCRIPT12008: WebSocket Error: Incorrect HTTP response. Status code 200,
[connection-1] error: [object Event]
[connection-1] disconnected
[connection-1] disconnected
QDR: routeChangeSuccess: path is now /
Error: [$controller:ctrlreg] The controller with the name
'QDR.OverviewController' is not registered.
http://errors.angularjs.org/1.6.2/$controller/ctrlreg?p0=QDR.OverviewController
at $controller
(https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:10690:11)
at setupControllers
(https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:9779:9)
at nodeLinkFn
(https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:9549:11)
at compositeLinkFn
(https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:8903:13)
at publicLinkFn
(https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:8768:30)
at link
(https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular-route.min.js:7:490)
at Anonymous function
(https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:1290:11)
at invokeLinkFn
(https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:10274:9)
at nodeLinkFn
(https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:9663:11)
at compositeLinkFn
(https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:8903:13)
QDR: failed to auto-connect to 10.0.2.2:8080
QDR: routeChangeSuccess: path is now /connect
$tooltip is now deprecated. Use $uibTooltip instead.
QDR: ** calling rhea.connect
QDR: rhea.connect was not passed an existing connection
QDR: testConnect called with reconnect true using ws protocol
QDR: exception caught on test connect SyntaxError
{noformat}
Personally, I do not care much about Internet Explorer 10. It should be
investigated if anyone using Dispatch (or productizing Dispatch) cares.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1381) Compiler errors: dereferencing pointer to incomplete type DH {aka struct dh_st}
[
https://issues.apache.org/jira/browse/PROTON-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986068#comment-15986068
]
Alexander Ellwein commented on PROTON-1381:
---
I confirm this bug still exists in 0.17, compiled on Arch Linux with OpenSSL
1.1.0 and got this:
{code}
gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -march=x86-64 -mtune=generic -O2 -pipe
-fstack-protector-strong -march=x86-64 -mtune=generic -O2 -pipe
-fstack-protector-strong -march=x86-64 -mtune=generic -O2 -pipe
-fstack-protector-strong -fPIC -Dqpid_proton_EXPORTS -DUSE_ATOLL
-DUSE_STRERROR_R -DUSE_CLOCK_GETTIME -Ibuild/include
-I/tmp/pip-build-c6gug2dg/python-qpid-proton/proton-c/include
-I/tmp/pip-build-c6gug2dg/python-qpid-proton/proton-c/src -c
/tmp/pip-build-c6gug2dg/python-qpid-proton/proton-c/src/ssl/openssl.c -o
build/temp.linux-x86_64-3.6/tmp/pip-build-c6gug2dg/python-qpid-proton/proton-c/src/ssl/openssl.o
-std=gnu99
/tmp/pip-build-c6gug2dg/python-qpid-proton/proton-c/src/ssl/openssl.c: In
function ‘get_dh2048’:
/tmp/pip-build-c6gug2dg/python-qpid-proton/proton-c/src/ssl/openssl.c:394:5:
error: dereferencing pointer to incomplete type ‘DH {aka struct dh_st}’
dh->p=BN_bin2bn(dh2048_p,sizeof(dh2048_p),NULL);
^~
/tmp/pip-build-c6gug2dg/python-qpid-proton/proton-c/src/ssl/openssl.c: In
function ‘ssn_cache_find’:
/tmp/pip-build-c6gug2dg/python-qpid-proton/proton-c/src/ssl/openssl.c:425:3:
warning: implicit declaration of function ‘lh_SSL_SESSION_doall_arg’
[-Wimplicit-function-declaration]
lh_SSL_SESSION_doall_arg(SSL_CTX_sessions(domain->ctx),
&SSL_SESSION_visit_caster, ssl_cache_visit_data, &visitor);
^~~~
/tmp/pip-build-c6gug2dg/python-qpid-proton/proton-c/src/ssl/openssl.c:425:86:
error: expected expression before ‘ssl_cache_visit_data’
lh_SSL_SESSION_doall_arg(SSL_CTX_sessions(domain->ctx),
&SSL_SESSION_visit_caster, ssl_cache_visit_data, &visitor);
^~~~
In file included from
/tmp/pip-build-c6gug2dg/python-qpid-proton/proton-c/src/ssl/openssl.c:45:0:
/tmp/pip-build-c6gug2dg/python-qpid-proton/proton-c/src/ssl/openssl.c: In
function ‘pn_ssl_domain’:
/tmp/pip-build-c6gug2dg/python-qpid-proton/proton-c/src/ssl/openssl.c:455:62:
warning: passing argument 4 of ‘CRYPTO_get_ex_new_index’ from incompatible
pointer type [-Wincompatible-pointer-types]
&ssl_session_ex_data_init, NULL, &ssl_session_ex_data_fini);
^
In file included from /usr/include/openssl/comp.h:16:0,
from /usr/include/openssl/ssl.h:47,
from
/tmp/pip-build-c6gug2dg/python-qpid-proton/proton-c/src/ssl/openssl.c:45:
/usr/include/openssl/crypto.h:178:12: note: expected ‘void (*)(void *, void
*, CRYPTO_EX_DATA *, int, long int, void *) {aka void (*)(void *, void *,
struct crypto_ex_data_st *, int, long int, void *)}’ but argument is of type
‘int (*)(void *, void *, CRYPTO_EX_DATA *, int, long int, void *) {aka int
(*)(void *, void *, struct crypto_ex_data_st *, int, long int, void *)}’
__owur int CRYPTO_get_ex_new_index(int class_index, long argl, void *argp,
^~~
error: command 'gcc' failed with exit status 1
{code}
> Compiler errors: dereferencing pointer to incomplete type DH {aka struct
> dh_st}
> ---
>
> Key: PROTON-1381
> URL: https://issues.apache.org/jira/browse/PROTON-1381
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.14.0, 0.16.0
> Environment: GCC 6.2.1, OpenSSL 1.1.0c
>Reporter: Volker Diels-Grabsch
>Assignee: Andrew Stitcher
>Priority: Blocker
> Labels: build, patch
> Attachments:
> qpid-proton-0.14.0-fix-dereferencing-pointer-to-incomplete-type.patch
>
>
> Proton-C doesn't build with GCC 6.2.1 and OpenSSL 1.1.0c. The error message
> is:
> {code:borderStyle=solid}
> [ 51%] Building C object
> proton-c/CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o
> /.../proton-c/src/ssl/openssl.c: In function ‘get_dh2048’:
> /.../proton-c/src/ssl/openssl.c:406:5: error: dereferencing pointer to
> incomplete type ‘DH {aka struct dh_st}’
>dh->p=BN_bin2bn(dh2048_p,sizeof(dh2048_p),NULL);
> ^~
> proton-c/CMakeFiles/qpid-proton.dir/build.make:1102: recipe for target
> 'proton-c/CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o' failed
> {code}
> The attached patch fixes this issue for 0.14.0 and also works for 0.16.0.
--
This me
[jira] [Commented] (PROTON-1470) proactor api - flexible, parse-free addressing
[ https://issues.apache.org/jira/browse/PROTON-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15985834#comment-15985834 ] Alan Conway commented on PROTON-1470: - Review request https://reviews.apache.org/r/58774 > proactor api - flexible, parse-free addressing > -- > > Key: PROTON-1470 > URL: https://issues.apache.org/jira/browse/PROTON-1470 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.17.0 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.18.0 > > > pn_proactor_connect and listen take a const char* string as the network > address. This creates ambiguity about what the string means. URLs are complex > to parse and construct and pn_url_t has been deprecated because it does not > follow the URL standards well. Ad-hoc string formats like "host:port" are > confusing since IPv6 host addresses can contains ":" characters. > Provide a simple pn_netaddr_t that can > - provide a unquoted, separate host and port strings to connect and listen > - inspect incoming addresses as standard struct sockaddr > - get a readable, but not parsable, string from any network address > - is extensible, in a binary compatible way, to support other address types > for connect/listen in future > Note it is not a requirement (yet) to be able to connect/listen using an > arbitrary sockaddr but it should be possible to add such support in future in > a source and binary compatible way. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Review Request 58774: WIP: netaddr passing libuv tests, need epoll
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/58774/ --- Review request for qpid, Andrew Stitcher, Cliff Jansen, and Justin Ross. Bugs: PROTON-1470 https://issues.apache.org/jira/browse/PROTON-1470 Repository: qpid-proton-git Description --- Add pn_netaddr_t to meet the following reqiurements: pn_proactor_connect and listen take a `const char*` string as the network address. This creates ambiguity about what the string means. URLs are complex to parse and construct and pn_url_t has been deprecated because it does not follow the URL standards well. Ad-hoc string formats like "host:port" are confusing since IPv6 host addresses can contains ":" characters. Provide a simple pn_netaddr_t that can - provide a unquoted, separate host and port strings to connect and listen - inspect incoming addresses as standard struct sockaddr - get a readable, but not parsable, string from any network address - is extensible, in a binary compatible way, to support other address types for connect/listen in future Note it is not a requirement (yet) to be able to connect/listen using an arbitrary sockaddr but it should be possible to add such support in future in a source and binary compatible way. Diffs - examples/c/proactor/broker.c 6501927115223f15b2a17330fa083422f3f2e4ee examples/c/proactor/direct.c f76895c4cdc331fb3ce1491d49dda21fc91447b6 examples/c/proactor/receive.c c8d3363fba4b96de16890673ed91a712f6d38723 examples/c/proactor/send.c c21ac68f0793a6d642788dd73025f91dc758bd49 examples/c/proactor/test.py 4950cef5b2a113e6e3197eb63465b4950bacdfa3 proton-c/CMakeLists.txt b1de95692fed82d14f89fa362a910060afe20053 proton-c/include/proton/netaddr.h PRE-CREATION proton-c/include/proton/proactor.h 901bc628ce0120191e79ef93a02b33d0376fbc6a proton-c/src/proactor/epoll.c b1175f4ccc45fb6e9293563ff815bff7dfad5573 proton-c/src/proactor/libuv.c 4992b4074111af43ce60f1e87114ae4d57e940fd proton-c/src/proactor/netaddr-internal.h PRE-CREATION proton-c/src/proactor/netaddr.c PRE-CREATION proton-c/src/tests/proactor.c 1365745432be5edff5460b801024c416d8a7c1d7 proton-c/src/tests/test_tools.h c5c8364612480156ab670c0bbf0a01a5f1a797d3 Diff: https://reviews.apache.org/r/58774/diff/1/ Testing --- Passes libuv proactor tests, epoll not updated yet. Thanks, Alan Conway
[jira] [Created] (PROTON-1470) proactor api - flexible, parse-free addressing
Alan Conway created PROTON-1470: --- Summary: proactor api - flexible, parse-free addressing Key: PROTON-1470 URL: https://issues.apache.org/jira/browse/PROTON-1470 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.17.0 Reporter: Alan Conway Assignee: Alan Conway Fix For: 0.18.0 pn_proactor_connect and listen take a const char* string as the network address. This creates ambiguity about what the string means. URLs are complex to parse and construct and pn_url_t has been deprecated because it does not follow the URL standards well. Ad-hoc string formats like "host:port" are confusing since IPv6 host addresses can contains ":" characters. Provide a simple pn_netaddr_t that can - provide a unquoted, separate host and port strings to connect and listen - inspect incoming addresses as standard struct sockaddr - get a readable, but not parsable, string from any network address - is extensible, in a binary compatible way, to support other address types for connect/listen in future Note it is not a requirement (yet) to be able to connect/listen using an arbitrary sockaddr but it should be possible to add such support in future in a source and binary compatible way. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-244) SASL library generates un-necessary DNS and LDAP requests
[
https://issues.apache.org/jira/browse/DISPATCH-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chuck Rolke updated DISPATCH-244:
-
Attachment: A-perf-flamegraph-3075-work.svg
A-perf-flamegraph-3075-work.svg - perf sampling of thread at 100% CPU while
qdstat times out.
> SASL library generates un-necessary DNS and LDAP requests
> -
>
> Key: DISPATCH-244
> URL: https://issues.apache.org/jira/browse/DISPATCH-244
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Affects Versions: 0.5
>Reporter: Alan Conway
>Assignee: Alan Conway
> Attachments: A-perf-flamegraph-3075-work.svg,
> dispatch-244-gdb-backtrace.txt
>
>
> The dispatch system tests (e.g. system_tests_management) run very slowly when
> connected to a VPN.
> - about 10x slower on VPN configured to use TCP connection
> - about 5x slower on VPN configured for UDP connection
> Wireshark shows unexpected LDAP and DNS queries on the VPN interface.
> `wallace` below is the local host name, but is not mentioned in any tests so
> must be picked up by proton or dispatch at runtime:
> {code}
> 1 0.0 10.3.113.10810.11.6.1 LDAP242
> searchRequest(11) "dc=redhat,dc=com" wholeSubtree
> 2 0.035161000 10.3.113.10810.5.30.160 DNS 72
> Standard query 0xd03f A wallace.lab.bos.redhat.com
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-244) SASL library generates un-necessary DNS and LDAP requests
[
https://issues.apache.org/jira/browse/DISPATCH-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chuck Rolke updated DISPATCH-244:
-
Attachment: dispatch-244-gdb-backtrace.txt
dispatch-244-gdb-backtrace.txt - thread at 100% CPU for five seconds while
qdstat times out.
> SASL library generates un-necessary DNS and LDAP requests
> -
>
> Key: DISPATCH-244
> URL: https://issues.apache.org/jira/browse/DISPATCH-244
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Affects Versions: 0.5
>Reporter: Alan Conway
>Assignee: Alan Conway
> Attachments: dispatch-244-gdb-backtrace.txt
>
>
> The dispatch system tests (e.g. system_tests_management) run very slowly when
> connected to a VPN.
> - about 10x slower on VPN configured to use TCP connection
> - about 5x slower on VPN configured for UDP connection
> Wireshark shows unexpected LDAP and DNS queries on the VPN interface.
> `wallace` below is the local host name, but is not mentioned in any tests so
> must be picked up by proton or dispatch at runtime:
> {code}
> 1 0.0 10.3.113.10810.11.6.1 LDAP242
> searchRequest(11) "dc=redhat,dc=com" wholeSubtree
> 2 0.035161000 10.3.113.10810.5.30.160 DNS 72
> Standard query 0xd03f A wallace.lab.bos.redhat.com
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-244) SASL library generates un-necessary DNS and LDAP requests
[
https://issues.apache.org/jira/browse/DISPATCH-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15985496#comment-15985496
]
Chuck Rolke commented on DISPATCH-244:
--
Another problem most likely related to this issue is that a simple command like
_qdstat -l_ times out upon occasion. This is annoying but there are unusual
things going on inside the router when qdstat times out:
* One thread goes to 100% CPU. See attached file dispatch-144-gdb-backtrace.txt
for information.
* A network trace shows DNS trying to resolve my laptop host name.
* Perf analysis shows the thread consumed by libc-2.24.so sys_poll and related
functions. See file A-perf-flamegraph-3075-work.svg for a picture of the perf
sampling.
Note that the gdb, net trace, and perf snapshot were taken on three separate
runs so they will not correlate with each other.
> SASL library generates un-necessary DNS and LDAP requests
> -
>
> Key: DISPATCH-244
> URL: https://issues.apache.org/jira/browse/DISPATCH-244
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Affects Versions: 0.5
>Reporter: Alan Conway
>Assignee: Alan Conway
>
> The dispatch system tests (e.g. system_tests_management) run very slowly when
> connected to a VPN.
> - about 10x slower on VPN configured to use TCP connection
> - about 5x slower on VPN configured for UDP connection
> Wireshark shows unexpected LDAP and DNS queries on the VPN interface.
> `wallace` below is the local host name, but is not mentioned in any tests so
> must be picked up by proton or dispatch at runtime:
> {code}
> 1 0.0 10.3.113.10810.11.6.1 LDAP242
> searchRequest(11) "dc=redhat,dc=com" wholeSubtree
> 2 0.035161000 10.3.113.10810.5.30.160 DNS 72
> Standard query 0xd03f A wallace.lab.bos.redhat.com
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-752) With more than one outbound SSL connections, failure in one affects all others
[ https://issues.apache.org/jira/browse/DISPATCH-752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reassigned DISPATCH-752: -- Assignee: Ted Ross > With more than one outbound SSL connections, failure in one affects all others > -- > > Key: DISPATCH-752 > URL: https://issues.apache.org/jira/browse/DISPATCH-752 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 0.7.0 >Reporter: Ganesh Murthy >Assignee: Ted Ross > Attachments: A.conf, B.conf, C.conf > > > 3 router config files are attached. Router A is configured with two > inter-router connectors to B and C respectively. These connectors are > configured to use SSL+EXTERNAL. > The routers are all started and connections between them are successfully > established and all is fine. > Kill router C. Router A's connection to C is lost (expected) but the > connection to B also fails (unexpected). > Each time router A retries the connection to router C, the newly > re-established connection to router B is lost. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-752) With more than one outbound SSL connections, failure in one affects all others
[ https://issues.apache.org/jira/browse/DISPATCH-752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated DISPATCH-752: --- Attachment: A.conf B.conf C.conf > With more than one outbound SSL connections, failure in one affects all others > -- > > Key: DISPATCH-752 > URL: https://issues.apache.org/jira/browse/DISPATCH-752 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 0.7.0 >Reporter: Ganesh Murthy > Attachments: A.conf, B.conf, C.conf > > > 3 router config files are attached. Router A is configured with two > inter-router connectors to B and C respectively. These connectors are > configured to use SSL+EXTERNAL. > The routers are all started and connections between them are successfully > established and all is fine. > Kill router C. Router A's connection to C is lost (expected) but the > connection to B also fails (unexpected). > Each time router A retries the connection to router C, the newly > re-established connection to router B is lost. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-752) With more than one outbound SSL connections, failure in one affects all others
Ganesh Murthy created DISPATCH-752: -- Summary: With more than one outbound SSL connections, failure in one affects all others Key: DISPATCH-752 URL: https://issues.apache.org/jira/browse/DISPATCH-752 Project: Qpid Dispatch Issue Type: Bug Components: Container Affects Versions: 0.7.0 Reporter: Ganesh Murthy 3 router config files are attached. Router A is configured with two inter-router connectors to B and C respectively. These connectors are configured to use SSL+EXTERNAL. The routers are all started and connections between them are successfully established and all is fine. Kill router C. Router A's connection to C is lost (expected) but the connection to B also fails (unexpected). Each time router A retries the connection to router C, the newly re-established connection to router B is lost. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-751) Clicking entities/connector in stand-alone console prints "Error: [ngModel:numfmt] Expected `1` to be a number"
[
https://issues.apache.org/jira/browse/DISPATCH-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Allen reassigned DISPATCH-751:
-
Assignee: Ernest Allen
> Clicking entities/connector in stand-alone console prints "Error:
> [ngModel:numfmt] Expected `1` to be a number"
> ---
>
> Key: DISPATCH-751
> URL: https://issues.apache.org/jira/browse/DISPATCH-751
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Console
>Affects Versions: 0.8.0
> Environment: The following log is from Firefox running stand-alone
> console from git at version from Latest commit 7a5b091. Same happens in
> Chrome.
>Reporter: Jiri Danek
>Assignee: Ernest Allen
> Fix For: 0.8.0
>
> Attachments: click_entities_connector.png
>
>
> Open stand-alone dispatch console, navigate to the Entities tab, click the
> connector node in the tree on the left. See errors in the browser debug
> console.
> !click_entities_connector.png|height=600!
> This does not affect hawtio console, there I see only
> {noformat}
> Empty string passed to getElementById(). app.js:1:23330
> {noformat}
> when clicking the entities/connector node in the tree.
> The firefox log
> {noformat}
> "Error: [ngModel:numfmt] Expected `1` to be a number
> http://errors.angularjs.org/1.6.2/ngModel/numfmt?p0=1
> minErr/<@https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:68:12
> numberFormatterParser/<@https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:24844:15
> ngModelWatch@https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:28740:21
> $RootScopeProvider/this.$gethttps://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:17847:34
> $RootScopeProvider/this.$gethttps://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:18125:13
> applyDetails@http://35.190.152.164:8080/stand-alone/plugin/js/qdrList.js:398:7
> " angular.js:14362:18
> consoleLog/<
> https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:14362:18
> $ExceptionHandlerProvider/this.$get https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:10859:7
> $RootScopeProvider/this.$get https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:17873:19
> $RootScopeProvider/this.$get https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:18125:13
> applyDetails
> http://35.190.152.164:8080/stand-alone/plugin/js/qdrList.js:398:7
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-751) Clicking entities/connector in stand-alone console prints "Error: [ngModel:numfmt] Expected `1` to be a number"
[
https://issues.apache.org/jira/browse/DISPATCH-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Allen resolved DISPATCH-751.
---
Resolution: Fixed
Fix Version/s: 0.8.0
> Clicking entities/connector in stand-alone console prints "Error:
> [ngModel:numfmt] Expected `1` to be a number"
> ---
>
> Key: DISPATCH-751
> URL: https://issues.apache.org/jira/browse/DISPATCH-751
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Console
>Affects Versions: 0.8.0
> Environment: The following log is from Firefox running stand-alone
> console from git at version from Latest commit 7a5b091. Same happens in
> Chrome.
>Reporter: Jiri Danek
>Assignee: Ernest Allen
> Fix For: 0.8.0
>
> Attachments: click_entities_connector.png
>
>
> Open stand-alone dispatch console, navigate to the Entities tab, click the
> connector node in the tree on the left. See errors in the browser debug
> console.
> !click_entities_connector.png|height=600!
> This does not affect hawtio console, there I see only
> {noformat}
> Empty string passed to getElementById(). app.js:1:23330
> {noformat}
> when clicking the entities/connector node in the tree.
> The firefox log
> {noformat}
> "Error: [ngModel:numfmt] Expected `1` to be a number
> http://errors.angularjs.org/1.6.2/ngModel/numfmt?p0=1
> minErr/<@https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:68:12
> numberFormatterParser/<@https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:24844:15
> ngModelWatch@https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:28740:21
> $RootScopeProvider/this.$gethttps://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:17847:34
> $RootScopeProvider/this.$gethttps://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:18125:13
> applyDetails@http://35.190.152.164:8080/stand-alone/plugin/js/qdrList.js:398:7
> " angular.js:14362:18
> consoleLog/<
> https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:14362:18
> $ExceptionHandlerProvider/this.$get https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:10859:7
> $RootScopeProvider/this.$get https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:17873:19
> $RootScopeProvider/this.$get https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:18125:13
> applyDetails
> http://35.190.152.164:8080/stand-alone/plugin/js/qdrList.js:398:7
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-751) Clicking entities/connector in stand-alone console prints "Error: [ngModel:numfmt] Expected `1` to be a number"
[
https://issues.apache.org/jira/browse/DISPATCH-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15985328#comment-15985328
]
ASF subversion and git services commented on DISPATCH-751:
--
Commit a0a17f4c8407e25045a5186fae1e5b8f1cbf00de in qpid-dispatch's branch
refs/heads/master from [~eallen]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=a0a17f4 ]
DISPATCH-751 Changed connector's cost attribute's default value
> Clicking entities/connector in stand-alone console prints "Error:
> [ngModel:numfmt] Expected `1` to be a number"
> ---
>
> Key: DISPATCH-751
> URL: https://issues.apache.org/jira/browse/DISPATCH-751
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Console
>Affects Versions: 0.8.0
> Environment: The following log is from Firefox running stand-alone
> console from git at version from Latest commit 7a5b091. Same happens in
> Chrome.
>Reporter: Jiri Danek
> Attachments: click_entities_connector.png
>
>
> Open stand-alone dispatch console, navigate to the Entities tab, click the
> connector node in the tree on the left. See errors in the browser debug
> console.
> !click_entities_connector.png|height=600!
> This does not affect hawtio console, there I see only
> {noformat}
> Empty string passed to getElementById(). app.js:1:23330
> {noformat}
> when clicking the entities/connector node in the tree.
> The firefox log
> {noformat}
> "Error: [ngModel:numfmt] Expected `1` to be a number
> http://errors.angularjs.org/1.6.2/ngModel/numfmt?p0=1
> minErr/<@https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:68:12
> numberFormatterParser/<@https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:24844:15
> ngModelWatch@https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:28740:21
> $RootScopeProvider/this.$gethttps://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:17847:34
> $RootScopeProvider/this.$gethttps://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:18125:13
> applyDetails@http://35.190.152.164:8080/stand-alone/plugin/js/qdrList.js:398:7
> " angular.js:14362:18
> consoleLog/<
> https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:14362:18
> $ExceptionHandlerProvider/this.$get https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:10859:7
> $RootScopeProvider/this.$get https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:17873:19
> $RootScopeProvider/this.$get https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:18125:13
> applyDetails
> http://35.190.152.164:8080/stand-alone/plugin/js/qdrList.js:398:7
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-288) Connection executor is not shutdown on connect failure
[ https://issues.apache.org/jira/browse/QPIDJMS-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-288. -- Resolution: Fixed > Connection executor is not shutdown on connect failure > -- > > Key: QPIDJMS-288 > URL: https://issues.apache.org/jira/browse/QPIDJMS-288 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.22.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.23.0 > > > During the initial connect phase of the Connection create process if an error > occurs such as a security exception the internal executor of the Connection > object is not properly shutdown. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7639) Implement large transaction guard restricting direct memory consumption by messages from uncommitted transactions on the connection
[ https://issues.apache.org/jira/browse/QPID-7639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15985114#comment-15985114 ] ASF subversion and git services commented on QPID-7639: --- Commit b7617e5f56bdfd5857af0bf4a190bb045ea8ac28 in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=b7617e5 ] QPID-7639: Implement large transaction guard restricting direct memory consumption by messages from uncommitted transactions on the connection > Implement large transaction guard restricting direct memory consumption by > messages from uncommitted transactions on the connection > > > Key: QPID-7639 > URL: https://issues.apache.org/jira/browse/QPID-7639 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Alex Rudyy > Fix For: qpid-java-broker-7.0.0 > > > The current implementation of AMQP 0-x layers restrict the memory consumption > by messages from uncommitted transactions on the session level. > We need to change the existing implementations to apply the limit per > connection and add implementation for AMQP 1.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7742) [Java Broker] [AMQP 1.0] Hostname should be taken from SNI or sasl-init if it is not present in open
[ https://issues.apache.org/jira/browse/QPID-7742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15984995#comment-15984995 ] ASF subversion and git services commented on QPID-7742: --- Commit 128cbb42b4b534007bd6bad531746217304168ca in qpid-broker-j's branch refs/heads/master from [~godfrer] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=128cbb4 ] QPID-7742 : Address review comments > [Java Broker] [AMQP 1.0] Hostname should be taken from SNI or sasl-init if it > is not present in open > > > Key: QPID-7742 > URL: https://issues.apache.org/jira/browse/QPID-7742 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > > As per [the AMQP > specification|http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#type-open] > when TLS and/or SASL are being used, the hostname provided by these layers > should be used if the hostname is not explicitly provided in the open > performative -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-7461) [Java Broker] Prevent Broker from running out of direct memory
[ https://issues.apache.org/jira/browse/QPID-7461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack closed QPID-7461. -- Resolution: Duplicate This was only a placeholder. The actual issue was tracked down and a separate JIRA (QPID-7465) was raised and fixed. > [Java Broker] Prevent Broker from running out of direct memory > -- > > Key: QPID-7461 > URL: https://issues.apache.org/jira/browse/QPID-7461 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.0.2 >Reporter: Lorenz Quack > > A [user described an > issue|http://qpid.2158936.n2.nabble.com/java-broker-6-0-2-OOM-td7651831.html] > where the broker is running out of direct memory. > This should not happen as flow to disk should return direct bytebuffers back > to the pool for reuse. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7752) [AMQP 1.0] producer message flow control should not be applied to transaction coordinator links
[ https://issues.apache.org/jira/browse/QPID-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall resolved QPID-7752. -- Resolution: Fixed > [AMQP 1.0] producer message flow control should not be applied to transaction > coordinator links > --- > > Key: QPID-7752 > URL: https://issues.apache.org/jira/browse/QPID-7752 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Alex Rudyy > Fix For: qpid-java-broker-7.0.0 > > > The implementation of produce flow control for AMQP 1.0 stops all receiving > links on broker side including transaction coordinator links. As result, the > affected transactions cannot be rolled back or committed. Transaction > coordinator links should not be stopped in response to a flow control > condition. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7752) [AMQP 1.0] producer message flow control should not be applied to transaction coordinator links
[ https://issues.apache.org/jira/browse/QPID-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15984803#comment-15984803 ] Keith Wall commented on QPID-7752: -- Looks reasonable to me. > [AMQP 1.0] producer message flow control should not be applied to transaction > coordinator links > --- > > Key: QPID-7752 > URL: https://issues.apache.org/jira/browse/QPID-7752 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Alex Rudyy > Fix For: qpid-java-broker-7.0.0 > > > The implementation of produce flow control for AMQP 1.0 stops all receiving > links on broker side including transaction coordinator links. As result, the > affected transactions cannot be rolled back or committed. Transaction > coordinator links should not be stopped in response to a flow control > condition. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7752) [AMQP 1.0] producer message flow control should not be applied to transaction coordinator links
[ https://issues.apache.org/jira/browse/QPID-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7752: - Summary: [AMQP 1.0] producer message flow control should not be applied to transaction coordinator links (was: [AMQP 1.0] producer message flow conttrol should not be applied to transaction coordinator links) > [AMQP 1.0] producer message flow control should not be applied to transaction > coordinator links > --- > > Key: QPID-7752 > URL: https://issues.apache.org/jira/browse/QPID-7752 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Alex Rudyy > Fix For: qpid-java-broker-7.0.0 > > > The implementation of produce flow control for AMQP 1.0 stops all receiving > links on broker side including transaction coordinator links. As result, the > affected transactions cannot be rolled back or committed. Transaction > coordinator links should not be stopped in response to a flow control > condition. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7719) [Java Broker] Set response code to 500 when unexpected error occurs during REST call
[
https://issues.apache.org/jira/browse/QPID-7719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall resolved QPID-7719.
--
Resolution: Fixed
> [Java Broker] Set response code to 500 when unexpected error occurs during
> REST call
> -
>
> Key: QPID-7719
> URL: https://issues.apache.org/jira/browse/QPID-7719
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Lorenz Quack
>Assignee: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> 0001-QPID-7719-Rethrow-fatal-exceptions-from-ExceptionHan.patch,
> TEST-org.apache.qpid.systest.rest.VirtualHostRestTest.testCreateProvidedVirtualHost.txt
>
>
> Currently if there is an unhandled exception in the REST layer we do not set
> a error response code. The servlet ends up returning 200 which is clearly
> incorrect.
> we should set the error code to 500 and ideally return a JSON error message.
> The code in question is the final {{else}} block in
> {{RestServlet#setResponseStatus}} (~line 960).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7719) [Java Broker] Set response code to 500 when unexpected error occurs during REST call
[
https://issues.apache.org/jira/browse/QPID-7719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15984759#comment-15984759
]
Keith Wall commented on QPID-7719:
--
Addition change looks reasonable to me.
> [Java Broker] Set response code to 500 when unexpected error occurs during
> REST call
> -
>
> Key: QPID-7719
> URL: https://issues.apache.org/jira/browse/QPID-7719
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Lorenz Quack
>Assignee: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> 0001-QPID-7719-Rethrow-fatal-exceptions-from-ExceptionHan.patch,
> TEST-org.apache.qpid.systest.rest.VirtualHostRestTest.testCreateProvidedVirtualHost.txt
>
>
> Currently if there is an unhandled exception in the REST layer we do not set
> a error response code. The servlet ends up returning 200 which is clearly
> incorrect.
> we should set the error code to 500 and ideally return a JSON error message.
> The code in question is the final {{else}} block in
> {{RestServlet#setResponseStatus}} (~line 960).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7639) Implement large transaction guard restricting direct memory consumption by messages from uncommitted transactions on the connection
[ https://issues.apache.org/jira/browse/QPID-7639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7639: - Description: The current implementation of AMQP 0-x layers restrict the memory consumption by messages from uncommitted transactions on the session level. We need to change the existing implementations to apply the limit per connection and add implementation for AMQP 1.0 was: The AMQP 1.0 layer does not have the ability to detect a large incoming transaction and warn and flow the messages to disk if limits are breached. We should add it as this an important safe guard, We are probably missing implementation here: org.apache.qpid.server.protocol.v1_0.NodeReceivingDestination#send > Implement large transaction guard restricting direct memory consumption by > messages from uncommitted transactions on the connection > > > Key: QPID-7639 > URL: https://issues.apache.org/jira/browse/QPID-7639 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Alex Rudyy > Fix For: qpid-java-broker-7.0.0 > > > The current implementation of AMQP 0-x layers restrict the memory consumption > by messages from uncommitted transactions on the session level. > We need to change the existing implementations to apply the limit per > connection and add implementation for AMQP 1.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7639) Implement large transaction guard restricting direct memory consumption by messages from uncommitted transactions on the connection
[
https://issues.apache.org/jira/browse/QPID-7639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15984725#comment-15984725
]
Alex Rudyy commented on QPID-7639:
--
Here is the transcript of IM conversation with discussion of the topic
{noformat}
(11:36:07) orudyy: rgodfrey: Hi Rob,
(11:36:07) orudyy: Re your comments for QPID-7639: I agree that method name
AbstractAMQPSession#getMaxUncommittedInMemorySize() gives an impression that it
is a limit per session and the correct name would be something like
#getMaxUncommittedInMemorySizePerTransaction(). Thus, the current name of the
method is indeed misleading. I will fix that. Is it what I meant in your
comment? I just would like to clarify that I correctly understood your comment.
Did you mean something else?
(11:38:42) rgodfrey: So the question is - what is the intent?
(11:38:59) rgodfrey: Is the intent that we have a limit per session / per
connection… or that we have a per transaction limit
(11:39:23) rgodfrey: if the limit is per transaction why is the limit held on
the session and not the connection (or at the vhost level)?
(11:40:14) rgodfrey: Basically the issue is that AMQP 1.0 works differently to
the other protocols… so either we need to redefine what the limit means, or the
implementation for 1.0 actually has to be per session, in which case the
accounting logic needs to be more complex
(11:46:40) rgodfrey: I actually feel like the 0-x implementations are wrong
too… they are implementing a maximum uncommitted size *per session* but the
context variable naming (and to a certain extent, common sense) would imply
that the limit should be per connection
(11:46:56) orudyy: Ah... I see you point. The original intent was just to have
the same functionality as in 0.x
(11:47:54) rgodfrey: yeah - which the current change doesn't give… but I think
we should probably first define what the desired functionality is, and then
work out how it should be implemented in 0-x and 1-0
(11:50:06) orudyy: I see. Do you think that for 1-0 the limit should apply per
connection?
(11:50:33) rgodfrey: I think all protocols should do the same thing :-)
(11:51:13) rgodfrey: per txn doesn't really make sense… per ssn was convenient
for 0-x but I think that per-connection is probably the most sensible thing to
do across all protools
(11:58:38) orudyy: I think it make sense to have limit per connection for all
protocols. Additionally, I would add another limit(s) for VH and Broker, in
order to protect the case when multiple connections accumulativly could
consume direct memory but messages on none of them would breach the connection
threshold. What do you think on introduction of VH and Broker limits?
(11:59:25) rgodfrey: I agree VH/Broker limits would make sense, but would
probably raise them as a separate JIRA to be separately prioritized
(12:00:08) k-wall: yeah - Alex correctly identifies an existing problme
(12:00:26) orudyy: Ok. I'll raise the JIRAs for VH and Broker limits and I will
repurpose the existing JIRA to implement connection limit
(12:00:53) k-wall: thanks Alex - so that would be a change to all protocols.
(12:01:01) orudyy: yeap
(12:01:11) rgodfrey: k-wall: yes - that would be a change to the undocumented
behaviour of all protocols :-)
(12:01:19) rgodfrey: (hint - we should probably document this :-) )
(12:02:12) k-wall: :)
(12:03:03) k-wall: I wouldn’t bother trying to retain the existing behaviour of
the existing context var. Few (noone) will be configuring this and we can
mention in the release notes
(12:03:41) rgodfrey: yeah - I agree - given that it was previously
undocumented, I think it is fine to just define the new behaviour and document
the new behaviour in release notes
{noformat}
> Implement large transaction guard restricting direct memory consumption by
> messages from uncommitted transactions on the connection
>
>
> Key: QPID-7639
> URL: https://issues.apache.org/jira/browse/QPID-7639
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Keith Wall
>Assignee: Alex Rudyy
> Fix For: qpid-java-broker-7.0.0
>
>
> The current implementation of AMQP 0-x layers restrict the memory consumption
> by messages from uncommitted transactions on the session level.
> We need to change the existing implementations to apply the limit per
> connection and add implementation for AMQP 1.0
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-5004) AMQP queue client functionality is not working behind a HTTP proxy.
[ https://issues.apache.org/jira/browse/QPID-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] venkata yerrapothu updated QPID-5004: - Hi Alex, As of today our team is using Microsoft SDK directly to interact with Azure queues. I will pass on the information to them about JMS client readiness. We never looked back after switching the logic to use SDK directly. Thanks Venkat > AMQP queue client functionality is not working behind a HTTP proxy. > --- > > Key: QPID-5004 > URL: https://issues.apache.org/jira/browse/QPID-5004 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.22 > Environment: SUN and IBM JVM's version 6 and 7 as well. >Reporter: venkata yerrapothu > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7639) Implement large transaction guard restricting direct memory consumption by messages from uncommitted transactions on the connection
[ https://issues.apache.org/jira/browse/QPID-7639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7639: - Summary: Implement large transaction guard restricting direct memory consumption by messages from uncommitted transactions on the connection (was: Implement large transaction guard restrict a direct memory consumption by messages from uncommitted transactions on the connection) > Implement large transaction guard restricting direct memory consumption by > messages from uncommitted transactions on the connection > > > Key: QPID-7639 > URL: https://issues.apache.org/jira/browse/QPID-7639 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Alex Rudyy > Fix For: qpid-java-broker-7.0.0 > > > The AMQP 1.0 layer does not have the ability to detect a large incoming > transaction and warn and flow the messages to disk if limits are breached. > We should add it as this an important safe guard, > We are probably missing implementation here: > org.apache.qpid.server.protocol.v1_0.NodeReceivingDestination#send -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7639) Implement large transaction guard restrict a direct memory consumption by messages from uncommitted transactions on the connection
[ https://issues.apache.org/jira/browse/QPID-7639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7639: - Summary: Implement large transaction guard restrict a direct memory consumption by messages from uncommitted transactions on the connection (was: [AMQP 1.0] Implement large transaction guard (i.e. honour connection.maxUncommittedInMemorySize)) > Implement large transaction guard restrict a direct memory consumption by > messages from uncommitted transactions on the connection > --- > > Key: QPID-7639 > URL: https://issues.apache.org/jira/browse/QPID-7639 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Alex Rudyy > Fix For: qpid-java-broker-7.0.0 > > > The AMQP 1.0 layer does not have the ability to detect a large incoming > transaction and warn and flow the messages to disk if limits are breached. > We should add it as this an important safe guard, > We are probably missing implementation here: > org.apache.qpid.server.protocol.v1_0.NodeReceivingDestination#send -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5004) AMQP queue client functionality is not working behind a HTTP proxy.
[ https://issues.apache.org/jira/browse/QPID-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15984711#comment-15984711 ] Alex Rudyy commented on QPID-5004: -- Hi venkata yerrapothu , Is there any reason why you cannot use new Qpid JMS Client: http://qpid.apache.org/components/jms/index.html The client you are using was deprecated and no longer supported. Can you switch to new JMS Client? Kind Regards, Alex > AMQP queue client functionality is not working behind a HTTP proxy. > --- > > Key: QPID-5004 > URL: https://issues.apache.org/jira/browse/QPID-5004 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.22 > Environment: SUN and IBM JVM's version 6 and 7 as well. >Reporter: venkata yerrapothu > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7759) [Java Broker] Add functionality restricting the usage of direct memory by messages from uncommitted large transactions on different connections per Virtual Host and Broker
[ https://issues.apache.org/jira/browse/QPID-7759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7759: - Component/s: (was: Java Documentation) > [Java Broker] Add functionality restricting the usage of direct memory by > messages from uncommitted large transactions on different connections per > Virtual Host and Broker > --- > > Key: QPID-7759 > URL: https://issues.apache.org/jira/browse/QPID-7759 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Alex Rudyy > > Multiple inflight large transactions running in parallel on different > connections can consume broker direct memory and potentially can cause > running out of memory without even breaching of the connection memory usage > limit (connection.maxUncommittedInMemorySize). The broker should have an > ability to restrict the usage of direct memory by messages from uncommitted > transactions on different connections per Virtual Host and Broker levels. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7759) [Java Broker] Add functionality restricting the usage of direct memory by messages from uncommitted large transactions on different connections per Virtual Host and Broker
[ https://issues.apache.org/jira/browse/QPID-7759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7759: - Component/s: Java Documentation Java Broker > [Java Broker] Add functionality restricting the usage of direct memory by > messages from uncommitted large transactions on different connections per > Virtual Host and Broker > --- > > Key: QPID-7759 > URL: https://issues.apache.org/jira/browse/QPID-7759 > Project: Qpid > Issue Type: Improvement > Components: Java Broker, Java Documentation >Reporter: Alex Rudyy > > Multiple inflight large transactions running in parallel on different > connections can consume broker direct memory and potentially can cause > running out of memory without even breaching of the connection memory usage > limit (connection.maxUncommittedInMemorySize). The broker should have an > ability to restrict the usage of direct memory by messages from uncommitted > transactions on different connections per Virtual Host and Broker levels. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7759) [Java Broker] Add functionality restricting the usage of direct memory by messages from uncommitted large transactions on different connections per Virtual Host and Broker
Alex Rudyy created QPID-7759: Summary: [Java Broker] Add functionality restricting the usage of direct memory by messages from uncommitted large transactions on different connections per Virtual Host and Broker Key: QPID-7759 URL: https://issues.apache.org/jira/browse/QPID-7759 Project: Qpid Issue Type: Improvement Reporter: Alex Rudyy Multiple inflight large transactions running in parallel on different connections can consume broker direct memory and potentially can cause running out of memory without even breaching of the connection memory usage limit (connection.maxUncommittedInMemorySize). The broker should have an ability to restrict the usage of direct memory by messages from uncommitted transactions on different connections per Virtual Host and Broker levels. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-5004) AMQP queue client functionality is not working behind a HTTP proxy.
[ https://issues.apache.org/jira/browse/QPID-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] venkata yerrapothu updated QPID-5004: - I had to modify the AMQP client code itself to send the proxy credentials. Later we moved away AMQP altogether as we started to see few random errors once in a while. Thanks > AMQP queue client functionality is not working behind a HTTP proxy. > --- > > Key: QPID-5004 > URL: https://issues.apache.org/jira/browse/QPID-5004 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.22 > Environment: SUN and IBM JVM's version 6 and 7 as well. >Reporter: venkata yerrapothu > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7758) [Java Broker] The global address prefixes should be respected by node auto creation policies should
Alex Rudyy created QPID-7758: Summary: [Java Broker] The global address prefixes should be respected by node auto creation policies should Key: QPID-7758 URL: https://issues.apache.org/jira/browse/QPID-7758 Project: Qpid Issue Type: Bug Components: Java Broker Reporter: Alex Rudyy The current implementation of automatic node creations using node auto creation policies does not take into consideration the global address prefixes. As result, the queue might not be created when its name matches the policy pattern but global address prefix does not. The greedy policy patterns might result in queue creation with a name including global domain prefix. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7758) [Java Broker] The global address prefixes should be respected by node auto creation policies
[ https://issues.apache.org/jira/browse/QPID-7758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7758: - Summary: [Java Broker] The global address prefixes should be respected by node auto creation policies (was: [Java Broker] The global address prefixes should be respected by node auto creation policies should) > [Java Broker] The global address prefixes should be respected by node auto > creation policies > > > Key: QPID-7758 > URL: https://issues.apache.org/jira/browse/QPID-7758 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Alex Rudyy > > The current implementation of automatic node creations using node auto > creation policies does not take into consideration the global address > prefixes. As result, the queue might not be created when its name matches the > policy pattern but global address prefix does not. The greedy policy patterns > might result in queue creation with a name including global domain prefix. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7742) [Java Broker] [AMQP 1.0] Hostname should be taken from SNI or sasl-init if it is not present in open
[
https://issues.apache.org/jira/browse/QPID-7742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15984616#comment-15984616
]
Rob Godfrey commented on QPID-7742:
---
{quote}
line 668 : if (first == 22 && third != 0x01). The condition checks that it is a
TLS handshake and protocol version is not TLS 1.0. I believe you meant to check
that TLS version is not SSL 3.0. Otherwise SSL 3.0 connection would try to
explore TLS extension defined for TLS 1.0, 1.1 and 1.2 and TLS 1.0 connection
would ignore server name when extension is present.
{quote}
Agreed - I will change this to exclude SSLv3
{quote}
Currently SSLUtil#getServerNameFromTLSClientHello silently returns null if
preconditions are not met. I think it should throw exception (for example
IllegalArgumentException) in order to notify caller that inappropriate buffer
is provided. The code in NonBlockingConnectionTLSDelegate checks that
conditions are met by calling SSLUtil#isSufficientToDetermineClientSNIHost.
Thus, it is not an issue as such, but for code correctness it make sense to
throw exception if the following preconditions are not met:
{quote}
Agreed - I will change the getServerNameFromTLSClientHello to first call
isSufficientToDetermineClientSNIHost, and if the return value from that is
false, I will throw an IllegalArgumentException
{quote}
Currently SSLUtil#getServerNameFromTLSClientHello silently returns null if
extension has invalid format or server name extension has invalid format. I
think that it is right thing to do but I would log it using debug or trace log
level in order to simplify the debugging.
{quote}
My decision here was originally that the underlying buffers are going to be fed
through an SSL decryption engine which will properly report on any SSL encoding
errors, and it would be better to simply ignore invalid SSL in this SNI code.
I think that is still the correct decision.
{quote}
Re WebSocket implementation. I think it make sense to do it after upgrade to
new version of jetty. I am not sure that it is even required for v7.
{quote}
Until it is done then we are not in compliance with the AMQP websocket binding
specification. I agree it should probably be raised as a separate JIRA and
prioritized on its own (and after the Jetty upgrade)
> [Java Broker] [AMQP 1.0] Hostname should be taken from SNI or sasl-init if it
> is not present in open
>
>
> Key: QPID-7742
> URL: https://issues.apache.org/jira/browse/QPID-7742
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
>
> As per [the AMQP
> specification|http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#type-open]
> when TLS and/or SASL are being used, the hostname provided by these layers
> should be used if the hostname is not explicitly provided in the open
> performative
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7757) [Java Broker Documentation] Improve Java Broker documentation about direct memory consumption by IO threads from port and virtual host pools
Alex Rudyy created QPID-7757: Summary: [Java Broker Documentation] Improve Java Broker documentation about direct memory consumption by IO threads from port and virtual host pools Key: QPID-7757 URL: https://issues.apache.org/jira/browse/QPID-7757 Project: Qpid Issue Type: Bug Components: Java Documentation Reporter: Alex Rudyy The current broker documentation does not provide any details about direct memory consumption by IO threads from Port and Virtual Host pools. The Memory section of documentation should be changed to include that. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7755) add release scripts for qpid-broker-j and qpid-jms-amqp-0-x
[ https://issues.apache.org/jira/browse/QPID-7755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15984583#comment-15984583 ] Justin Ross commented on QPID-7755: --- I added partial release scripts for these components in https://git-wip-us.apache.org/repos/asf?p=qpid-site.git;a=commit;h=32dce6b5abda356a9d4061692a09cf88329a2fb8 . Some notes: - There are still a few instances of java-broker that need to be cleaned up. - Some of the logic for doc generation remains to be ported from the old scripts (which I didn't delete yet). - I went with "Qpid Broker-J", with a hyphen, in titles and text. That's precedent from Proton-J. I personally like it better without the hyphen. That's your call, of course. > add release scripts for qpid-broker-j and qpid-jms-amqp-0-x > --- > > Key: QPID-7755 > URL: https://issues.apache.org/jira/browse/QPID-7755 > Project: Qpid > Issue Type: Task > Components: Website >Reporter: Lorenz Quack > Fix For: qpid-java-client-0-x-6.3.0, qpid-java-broker-7.0.0 > > > The qpid-site repository contains scripts for generating release pages. > After separation of java broker and client and the migration from svn to git > we need to create new scripts (or update the old ones). > This needs to happen before/as part of the next release. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7756) Website updates Q2 2017
Justin Ross created QPID-7756: - Summary: Website updates Q2 2017 Key: QPID-7756 URL: https://issues.apache.org/jira/browse/QPID-7756 Project: Qpid Issue Type: Task Components: Website Reporter: Justin Ross Assignee: Justin Ross -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-7697) Website updates Q1 2017
[ https://issues.apache.org/jira/browse/QPID-7697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross closed QPID-7697. - Resolution: Done > Website updates Q1 2017 > --- > > Key: QPID-7697 > URL: https://issues.apache.org/jira/browse/QPID-7697 > Project: Qpid > Issue Type: Task > Components: Website >Reporter: Justin Ross >Assignee: Justin Ross > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7742) [Java Broker] [AMQP 1.0] Hostname should be taken from SNI or sasl-init if it is not present in open
[
https://issues.apache.org/jira/browse/QPID-7742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15984541#comment-15984541
]
Alex Rudyy commented on QPID-7742:
--
Rob,
I reviewed your changes and here are my review comments:
* {{SSLUtil#getServerNameFromTLSClientHello}}
** line 668 : {{if (first == 22 && third != 0x01)}}. The condition checks that
it is a TLS handshake and protocol version is not TLS 1.0. I believe you meant
to check that TLS version is not SSL 3.0. Otherwise SSL 3.0 connection would
try to explore TLS extension defined for TLS 1.0, 1.1 and 1.2 and TLS 1.0
connection would ignore server name when extension is present.
** Currently {{SSLUtil#getServerNameFromTLSClientHello}} silently returns null
if preconditions are not met. I think it should throw exception (for example
{{IllegalArgumentException}}) in order to notify caller that inappropriate
buffer is provided. The code in {{NonBlockingConnectionTLSDelegate}} checks
that conditions are met by calling
{{SSLUtil#isSufficientToDetermineClientSNIHost}}. Thus, it is not an issue as
such, but for code correctness it make sense to throw exception if the
following preconditions are not meat:
*** the buffer#remaining is less than 5
*** first byte is not handshake
*** second byte is not 3 (major version)
*** third byte is 0 (minor version)
*** the record size exceeds buffer#remaining
*** sixth byte is not client_hello (0)
** Currently {{SSLUtil#getServerNameFromTLSClientHello}} silently returns null
if extension has invalid format or server name extension has invalid format. I
think that it is right thing to do but I would log it using debug or trace log
level in order to simplify the debugging.
* Re WebSocket implementation. I think it make sense to do it after upgrade to
new version of jetty. I am not sure that it is even required for v7.
> [Java Broker] [AMQP 1.0] Hostname should be taken from SNI or sasl-init if it
> is not present in open
>
>
> Key: QPID-7742
> URL: https://issues.apache.org/jira/browse/QPID-7742
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
>
> As per [the AMQP
> specification|http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#type-open]
> when TLS and/or SASL are being used, the hostname provided by these layers
> should be used if the hostname is not explicitly provided in the open
> performative
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7639) [AMQP 1.0] Implement large transaction guard (i.e. honour connection.maxUncommittedInMemorySize)
[ https://issues.apache.org/jira/browse/QPID-7639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15984470#comment-15984470 ] Rob Godfrey commented on QPID-7639: --- So, in AMQP 0-x you can have at most one open transaction per session (and transactional operations are restricted to the session that created the transaction), in AMQP 1.0 neither of these constraints apply. As such while the change here is creating some protection (limiting the size of uncommitted messages per transaction) the semantics are not actually the same as for the other protocols, and the use of the "session" limits is somewhat misleading > [AMQP 1.0] Implement large transaction guard (i.e. honour > connection.maxUncommittedInMemorySize) > > > Key: QPID-7639 > URL: https://issues.apache.org/jira/browse/QPID-7639 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Alex Rudyy > Fix For: qpid-java-broker-7.0.0 > > > The AMQP 1.0 layer does not have the ability to detect a large incoming > transaction and warn and flow the messages to disk if limits are breached. > We should add it as this an important safe guard, > We are probably missing implementation here: > org.apache.qpid.server.protocol.v1_0.NodeReceivingDestination#send -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5004) AMQP queue client functionality is not working behind a HTTP proxy.
[ https://issues.apache.org/jira/browse/QPID-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15984381#comment-15984381 ] Sharad Holani commented on QPID-5004: - [~sisivy][~yerrapothu] I am also running a proxy to use azure service bus as the amqp ports are blocked. But I havent got it to work till now. Could you please tell me what did you do to get it working ? > AMQP queue client functionality is not working behind a HTTP proxy. > --- > > Key: QPID-5004 > URL: https://issues.apache.org/jira/browse/QPID-5004 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.22 > Environment: SUN and IBM JVM's version 6 and 7 as well. >Reporter: venkata yerrapothu > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7639) [AMQP 1.0] Implement large transaction guard (i.e. honour connection.maxUncommittedInMemorySize)
[ https://issues.apache.org/jira/browse/QPID-7639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15984338#comment-15984338 ] ASF subversion and git services commented on QPID-7639: --- Commit 570392ef9bb3a06044c79f133db93032d2be6352 in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=570392e ] QPID-7639: Add missing license header > [AMQP 1.0] Implement large transaction guard (i.e. honour > connection.maxUncommittedInMemorySize) > > > Key: QPID-7639 > URL: https://issues.apache.org/jira/browse/QPID-7639 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Alex Rudyy > Fix For: qpid-java-broker-7.0.0 > > > The AMQP 1.0 layer does not have the ability to detect a large incoming > transaction and warn and flow the messages to disk if limits are breached. > We should add it as this an important safe guard, > We are probably missing implementation here: > org.apache.qpid.server.protocol.v1_0.NodeReceivingDestination#send -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
