[JBoss JIRA] (WFLY-11474) Make activemq dependency on cli module optional
by Jean-Francois Denise (Jira)
Jean-Francois Denise created WFLY-11474:
-------------------------------------------
Summary: Make activemq dependency on cli module optional
Key: WFLY-11474
URL: https://issues.jboss.org/browse/WFLY-11474
Project: WildFly
Issue Type: Task
Components: JMS
Reporter: Jean-Francois Denise
Assignee: Jeff Mesnil
Dependency on org.jboss.as.cli from org.wildfly.extension.messaging-activemq should be made optional.
At runtime, the commands are not loaded on the server side. They are loaded thanks to ServiceLoader from CLI, so if CLI is present, the commands are in use, otherwise they are un-used.
We would observe a gain of 2.3+MB in filesystem footprint when a server without CLI is provisioned.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (DROOLS-3402) Encoding set in constructor not taking effect
by Barnabás Kurucz (Jira)
[ https://issues.jboss.org/browse/DROOLS-3402?page=com.atlassian.jira.plugi... ]
Barnabás Kurucz updated DROOLS-3402:
------------------------------------
Issue Type: Bug (was: Feature Request)
> Encoding set in constructor not taking effect
> ---------------------------------------------
>
> Key: DROOLS-3402
> URL: https://issues.jboss.org/browse/DROOLS-3402
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.13.0.Final
> Reporter: Barnabás Kurucz
> Assignee: Mario Fusco
> Priority: Major
>
> In my drl file, I'm using German characters such as Umlauts or ß. Thus, I am setting the encoding to UTF-8 with the overloaded constructor when creating the Resource for the Kie File System. However, after firing the rules on the inserted Fact Drools does not seem to apply the specified encoding. I insert the fact, and if the condition is true to that fact it should modify the Action1 (String) attribute of the fact to "Rückfrage" and return the modified fact. However, when I look at the retrieved bean's Action1 attribute I am seeing "Rückfrage" instead of "Rückfrage". I tried both UTF-8 and ISO-8859-1 encoding. Any ideas what's wrong?
> Drools 7.13
> *KieSessionGenerator*:
> public KieSessionGenerator() {
> KieServices kieServices = KieServices.Factory.get();
> KieFileSystem kieFileSystem = kieServices.newKieFileSystem();
> kieFileSystem.write(ResourceFactory.newClassPathResource(drlFile, "UTF-8"));
> KieBuilder kieBuilder = kieServices.newKieBuilder(kieFileSystem);
> kieBuilder.buildAll();
> KieModule kieModule = kieBuilder.getKieModule();
> KieContainer kieContainer = kieServices.newKieContainer(kieModule.getReleaseId());
> kieSession = kieContainer.newKieSession();
> }
> *Snippet from DRL:*
> rule "813"
> when
> $bean : Bean(longDesc == "Infektion")
> then
> $bean.setAction1("Rückfrage");
> end
> *Inserting the fact:*
> public Bean lookupBean(Bean bean) {
> kieSessionGenerator.getKieSession().insert(bean);
> kieSessionGenerator.getKieSession().fireAllRules();
> return bean;
> }
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (DROOLS-3402) Encoding set in constructor not taking effect
by Barnabás Kurucz (Jira)
Barnabás Kurucz created DROOLS-3402:
---------------------------------------
Summary: Encoding set in constructor not taking effect
Key: DROOLS-3402
URL: https://issues.jboss.org/browse/DROOLS-3402
Project: Drools
Issue Type: Feature Request
Affects Versions: 7.13.0.Final
Reporter: Barnabás Kurucz
Assignee: Mario Fusco
In my drl file, I'm using German characters such as Umlauts or ß. Thus, I am setting the encoding to UTF-8 with the overloaded constructor when creating the Resource for the Kie File System. However, after firing the rules on the inserted Fact Drools does not seem to apply the specified encoding. I insert the fact, and if the condition is true to that fact it should modify the Action1 (String) attribute of the fact to "Rückfrage" and return the modified fact. However, when I look at the retrieved bean's Action1 attribute I am seeing "Rückfrage" instead of "Rückfrage". I tried both UTF-8 and ISO-8859-1 encoding. Any ideas what's wrong?
Drools 7.13
*KieSessionGenerator*:
public KieSessionGenerator() {
KieServices kieServices = KieServices.Factory.get();
KieFileSystem kieFileSystem = kieServices.newKieFileSystem();
kieFileSystem.write(ResourceFactory.newClassPathResource(drlFile, "UTF-8"));
KieBuilder kieBuilder = kieServices.newKieBuilder(kieFileSystem);
kieBuilder.buildAll();
KieModule kieModule = kieBuilder.getKieModule();
KieContainer kieContainer = kieServices.newKieContainer(kieModule.getReleaseId());
kieSession = kieContainer.newKieSession();
}
*Snippet from DRL:*
rule "813"
when
$bean : Bean(longDesc == "Infektion")
then
$bean.setAction1("Rückfrage");
end
*Inserting the fact:*
public Bean lookupBean(Bean bean) {
kieSessionGenerator.getKieSession().insert(bean);
kieSessionGenerator.getKieSession().fireAllRules();
return bean;
}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (JGRP-2316) DNS_PING is not using correct ports with SRV based service discovery
by Sebastian Łaskawiec (Jira)
[ https://issues.jboss.org/browse/JGRP-2316?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec commented on JGRP-2316:
-------------------------------------------
h2. Experiments
I did some tests with my [DNS_PING example repo|https://github.com/slaskawi/jgroups-dns-ping-example] and I managed to confirm a couple of things.
Kubernetes populates DNS entries based on Services. If we want to use DNS-based discovery, we need to specify a Service for our {{Deployment}} or {{DeploymentConfig}}. [~belaban] Please note, that with your Service definition, you specified a port - it's {{8888}}.
{code}
publishNotReadyAddresses: true
clusterIP: None
ports:
- name: ping
port: 8888
protocol: TCP
targetPort: 8888
selector:
deploymentConfig: jgrp
{code}
Kubernetes uses that port ({{8888}}) to populate {{SRV}} entries in DNS. I ran a similar example to yours but based on my repo. Here are the results:
*Dig for A Entries*
{code}
$ dig +search jgroups-dns-ping.myproject.svc.cluster.local
; <<>> DiG 9.9.4-RedHat-9.9.4-72.el7 <<>> +search jgroups-dns-ping.myproject.svc.cluster.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30214
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;jgroups-dns-ping.myproject.svc.cluster.local. IN A
;; ANSWER SECTION:
jgroups-dns-ping.myproject.svc.cluster.local. 30 IN A 172.17.0.11
jgroups-dns-ping.myproject.svc.cluster.local. 30 IN A 172.17.0.9
;; Query time: 0 msec
;; SERVER: 172.30.0.2#53(172.30.0.2)
;; WHEN: Tue Dec 04 09:58:17 UTC 2018
;; MSG SIZE rcvd: 94
{code}
*Dig for SRV Entries*
{code}
$ dig +search SRV _ping._tcp.jgroups-dns-ping.myproject.svc.cluster.local
; <<>> DiG 9.9.4-RedHat-9.9.4-72.el7 <<>> +search SRV _ping._tcp.jgroups-dns-ping.myproject.svc.cluster.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38422
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
;; QUESTION SECTION:
;_ping._tcp.jgroups-dns-ping.myproject.svc.cluster.local. IN SRV
;; ANSWER SECTION:
_ping._tcp.jgroups-dns-ping.myproject.svc.cluster.local. 30 IN SRV 10 50 8888 c1fc9dd.jgroups-dns-ping.myproject.svc.cluster.local.
_ping._tcp.jgroups-dns-ping.myproject.svc.cluster.local. 30 IN SRV 10 50 8888 8489e066.jgroups-dns-ping.myproject.svc.cluster.local.
;; ADDITIONAL SECTION:
c1fc9dd.jgroups-dns-ping.myproject.svc.cluster.local. 30 IN A 172.17.0.11
8489e066.jgroups-dns-ping.myproject.svc.cluster.local. 30 IN A 172.17.0.9
;; Query time: 1 msec
;; SERVER: 172.30.0.2#53(172.30.0.2)
;; WHEN: Tue Dec 04 09:58:53 UTC 2018
;; MSG SIZE rcvd: 250
{code}
Note, that SRV entries contain port {{8888}} (as I expected in my previous comment). So there's no dynamic remapping in Kubernetes (!!!).
h2. Answering comments
So based on experiment above, let me answer your comments:
{quote}
I do not want to define the ports in multiple locations; the authoritative location for JGroups ports is the JGroups config file. Having to define the same port in multiple files is error-prone and unmaintainable
{quote}
In Kubernetes, that's not doable. Note, that you need to specify a port in Service definition. However, it is possible to use a transport port on the service and then iterate over a well-known port range. That should work without any problems. But the bottom line is, that you need to put something into the Service definition. Perhaps, we should always put a transport port there?
{quote}
A lot of protocols (UDP/TCP, FD_SOCK, STATE_SOCK) do not define a static port; the default is 0, which means the OS picks an ephemeral port.
{quote}
That should be fine as long as you know how to discover this port and how to connect to it. In this use case, it's not really different from on-prem solutions.
h2. Conclusions
I think your concerns are valid to some extent, Bela. So far we've been usually using port {{8888}} in our examples but it hasn't been actively used in our implementation (it's ignored by DNS A records by definition, and due to the previous implementation, it was also ignored by DNS SRV records resolution). I think we should be using transport port in our Service definition and introduce a property to DNS_PING that would indicate, whether or not ports obtained from DNS shall be used or ignored.
> DNS_PING is not using correct ports with SRV based service discovery
> --------------------------------------------------------------------
>
> Key: JGRP-2316
> URL: https://issues.jboss.org/browse/JGRP-2316
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Reporter: dmcnair
> Assignee: Bela Ban
> Priority: Major
>
> This is a follow-up to JGRP-2296 - which changed `DefaultDNSResolver.java` to preserve the port for SRV records. While that change is working as desired, `DNS_PING.java` is not using the port when doing member discovery.
> Here are the log entries using *4.0.15*
> {noformat}
> 2018-11-29 21:37:41,561 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) Entries collected from DNS (in 5 ms): [172.29.11.50:27106, 172.29.11.50:27105]
> 2018-11-29 21:37:41,562 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) 982d38761cba: sending discovery requests to hosts [172.29.11.50:27106, 172.29.11.50:27105] on ports [7600 .. 7600]
> {noformat}
> Since the port was found via the SRV record, it should be used instead of the *transportPort* port.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months