[JBoss JIRA] (DROOLS-3037) [DMN Designer] Added item definition has not icon of structure
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-3037?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3037:
--------------------------------
Description:
If user add custom item definition and define it as structure, the item definition misses the structure icon set the attached picture. There is new custom structure item definition *a* without icon. Compare it with other structure item definitions.
h2. Acceptance test
- Check added item definition has icon when it is top level
- Check added item definition has icon when used in nested level
- Check item definition has not structure icon when changed from structure to something else
- Check item definition has structure icon when changed from something else to structure
was:If user add custom item definition and define it as structure, the item definition misses the structure icon set the attached picture. There is new custom structure item definition *a* without icon. Compare it with other structure item definitions.
> [DMN Designer] Added item definition has not icon of structure
> --------------------------------------------------------------
>
> Key: DROOLS-3037
> URL: https://issues.jboss.org/browse/DROOLS-3037
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.12.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Carreiro
> Labels: drools-tools
> Attachments: Screenshot from 2018-09-26 12-33-28.png
>
>
> If user add custom item definition and define it as structure, the item definition misses the structure icon set the attached picture. There is new custom structure item definition *a* without icon. Compare it with other structure item definitions.
> h2. Acceptance test
> - Check added item definition has icon when it is top level
> - Check added item definition has icon when used in nested level
> - Check item definition has not structure icon when changed from structure to something else
> - Check item definition has structure icon when changed from something else to structure
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (DROOLS-2762) [DMN Editor] Custom data-types - "Add row" component - this component creates new lines (in the treegrid-table)
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2762?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2762:
--------------------------------
Description:
The "Add component" creates new lines (in the treegrid-table) representing nested fields (in ItemDefinition):
- This component must be disabled (or hidden) when an existing/primitive data type is selected.
h3. Acceptance test
- User not able to add and save lines that are filled just partially (this requirement will be addressed by the https://issues.jboss.org/browse/DROOLS-3022)
- Added top level item definition present in output data type select box immediately (x) DROOLS-2948
- Added item definition has structure icon if added as structure (x) DROOLS-3037
- Check added rows after reopening
- The "Add row" button must always appear to the user (e.q. a lot of item definitions present)
was:
The "Add component" creates new lines (in the treegrid-table) representing nested fields (in ItemDefinition):
- This component must be disabled (or hidden) when an existing/primitive data type is selected.
h3. Acceptance test
- User not able to add and save lines that are filled just partially (this requirement will be addressed by the https://issues.jboss.org/browse/DROOLS-3022)
- Added top level item definition present in output data type select box immediately (x) DROOLS-2948
- Added item definition has structure icon if added as structure (x)
- Check added rows after reopening
- The "Add row" button must always appear to the user (e.q. a lot of item definitions present)
> [DMN Editor] Custom data-types - "Add row" component - this component creates new lines (in the treegrid-table)
> ---------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-2762
> URL: https://issues.jboss.org/browse/DROOLS-2762
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Affects Versions: 7.9.0.Final
> Reporter: Guilherme Carreiro
> Assignee: Guilherme Carreiro
> Labels: drools-tools
> Attachments: DROOLS-2762.png
>
>
> The "Add component" creates new lines (in the treegrid-table) representing nested fields (in ItemDefinition):
> - This component must be disabled (or hidden) when an existing/primitive data type is selected.
> h3. Acceptance test
> - User not able to add and save lines that are filled just partially (this requirement will be addressed by the https://issues.jboss.org/browse/DROOLS-3022)
> - Added top level item definition present in output data type select box immediately (x) DROOLS-2948
> - Added item definition has structure icon if added as structure (x) DROOLS-3037
> - Check added rows after reopening
> - The "Add row" button must always appear to the user (e.q. a lot of item definitions present)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (JGRP-2297) Coordinator with ASYM_ENCRYPT in the stack does not leave gracefully
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2297?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2297:
---------------------------
Fix Version/s: 4.0.16
(was: 4.0.15)
> Coordinator with ASYM_ENCRYPT in the stack does not leave gracefully
> --------------------------------------------------------------------
>
> Key: JGRP-2297
> URL: https://issues.jboss.org/browse/JGRP-2297
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.14
> Reporter: Radoslav Husar
> Assignee: Bela Ban
> Priority: Blocker
> Fix For: 4.0.16
>
>
> The {{ASYM_ENCRYPT_LeaveTest}} is designed to test graceful leaving coordinator(s) with ASYM_ENCRYPT in the stack. However, the test currently passes due to presence of MERGE3 in the stack. While the intention of the test seems to be testing graceful leaving of coordinator(s), the cluster ends up with inconsistent views later resolved by MERGE3.
> Here is a run of the test with a modification of the test with a *single* coordinator leaving:
> https://gist.github.com/rhusar/89172882fae60a1f29327c33f2d124db
> The problem seems to be with coordinating of key exchange. In this run, roughly:
> 1. node 1 is leaving
> 2. node 2 becomes coordinator and key server
> {noformat}
> 10:55:18.286 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.pbcast.GMS - 2: installing view [2|10] (9) [2, 3, 4, 5, 6, 7, 8, 9, 10]
> ...
> 10:55:18.299 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 2: I'm the new key server
> 10:55:18.300 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 2: created new secret key (version: AB1E6F44DE947D792A7D05D2E957AC85)
> ...
> 10:55:18.300 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 2: created new secret key (version: AB1E6F44DE947D792A7D05D2E957AC85)
> {noformat}
> 3. node 9 receives {{FETCH_SECRET_KEY}} however receives stale key? looks like it still contacts the leaving coordinator node 1?
> {noformat}
> 10:55:18.319 [SSL_KEY_EXCHANGE-runner-12,ASYM_ENCRYPT_LeaveTest,1] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 1: accepted SSL connection from /127.0.0.1:51812; protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> ...
> 10:55:18.319 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: created SSL connection to 2 (/127.0.0.1:2157); protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> 10:55:18.321 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: sending up secret key (version: AF7916A9394F49B085D4F35C4F5A0A3E)
> 10:55:18.321 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 9: ignoring secret key received from key exchange protocol (version: AF7916A9394F49B085D4F35C4F5A0A3E), as it has already been installed
> {noformat}
> 4. new coordinator fails to collect all acks (since it cannot decipher stale key?)
> {noformat}
> 10:55:20.307 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] WARN org.jgroups.protocols.pbcast.GMS - 2: failed to collect all ACKs (expected=8) for view [2|10] after 2000ms, missing 1 ACKs from (1) 9
> {noformat}
> 5. node 9 eventually obtains the key but since it has stale view and still thinks node 1 is coordinator? and fails to contact it
> {noformat}
> 10:55:20.307 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 9: asking key exchange protocol to get secret key from 2
> 10:55:20.322 [SSL_KEY_EXCHANGE-runner-26,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 2: accepted SSL connection from /127.0.0.1:51829; protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> 10:55:20.322 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: created SSL connection to 2 (/127.0.0.1:2158); protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> 10:55:20.322 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: sending up secret key (version: AB1E6F44DE947D792A7D05D2E957AC85)
> 10:55:20.322 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 9: installing secret key received from key exchange protocol (version: AB1E6F44DE947D792A7D05D2E957AC85)
> 10:55:23.341 [TQ-Bundler-10,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.TCP - JGRP000034: 9: failure sending message to 1: java.net.ConnectException: Connection refused (Connection refused)
> {noformat}
> 6. cluster is later healed with MERGE3
> {noformat}
> 10:55:27.103 [jgroups-27,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.pbcast.GMS - 2: I will be the merge leader. Starting the merge task. Views: {2=[2|10] (9) [2, 3, 4, 5, 6, 7, 8, 9, 10], 9=[1|9] (10) [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]}
> {noformat}
> Another run with MERGE3 omitted from the stack is here:
> https://gist.github.com/rhusar/b51aeee03485a607041f9669bbc6e707
> Further investigation is ongoing, but this might be related to graceful leaving of coordinator JGRP-2293 exacerbating the problem with key exchange in ASYM_ENCRYPT.
> Scaling down is typical cloud workflow, especially with encryption since {{ASYM_ENCRYPT}} is the recommended setup making this problem critical.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (JGRP-2296) DNS_PING is dropping port values with SRV based service discovery
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2296?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2296:
---------------------------
Fix Version/s: 4.0.16
(was: 4.0.15)
> DNS_PING is dropping port values with SRV based service discovery
> -----------------------------------------------------------------
>
> Key: JGRP-2296
> URL: https://issues.jboss.org/browse/JGRP-2296
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.11
> Environment: JGroups version 4.0.11.Final
> Used in Keycloak 4.4.0
> Deployed as Jboss based Docker container from jboss/keycloak into AWS ECS
> Reporter: Eric Thompson
> Assignee: Bela Ban
> Priority: Blocker
> Fix For: 4.0.16
>
>
> Using DNS_PING in Jgroups 4.0.11 and SRV records the port from the SRV record is being dropped (set to zero) and the default is used instead (7600).
> I am using this Jgroups config:
> {code}
> <subsystem xmlns="urn:jboss:domain:jgroups:6.0">
> <channels default="ee">
> <channel name="ee" stack="tcp" cluster="ejb"/>
> </channels>
> <stacks>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp">
> <property name="external_addr">${env.EXTERNAL_ADDR}</property>
> </transport>
> <protocol type="dns.DNS_PING">
> <property name="dns_query">
> jgroups.${env.DNS_NAME}.svc.cluster.local
> </property>
> <property name="dns_record_type">
> SRV
> </property>
> </protocol>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG3"/>
> </stack>
> </stacks>
> </subsystem>
> {code}
> I have these service discovery DNS entries
> {code}
> $ dig jgroups.dev.auth.example.com.svc.cluster.local SRV
> ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.68.rc1.58.amzn1 <<>> jgroups.dev.auth.example.com.svc.cluster.local SRV
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16690
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
> ;; QUESTION SECTION:
> ;jgroups.dev.auth.example.com.svc.cluster.local. IN SRV
> ;; ANSWER SECTION:
> jgroups.dev.auth.example.com.svc.cluster.local. 10 IN SRV 1 1 32921 9ec82e3f-3a0e-4e30-b785-17879c63cd7d.jgroups.dev.auth.example.com.svc.cluster.local.
> jgroups.dev.auth.example.com.svc.cluster.local. 10 IN SRV 1 1 32923 60b5a820-9678-4bd2-84c6-00061a52bde0.jgroups.dev.auth.example.com.svc.cluster.local.
> jgroups.dev.auth.example.com.svc.cluster.local. 10 IN SRV 1 1 32915 9d9d78d0-8919-4b91-9df8-2e4e65afedae.jgroups.dev.auth.example.com.svc.cluster.local.
> jgroups.dev.auth.example.com.svc.cluster.local. 10 IN SRV 1 1 32917 161f3d66-f1e3-46f4-a44f-ebda925a25c6.jgroups.dev.auth.example.com.svc.cluster.local.
> ;; Query time: 2 msec
> ;; SERVER: 10.42.3.2#53(10.42.3.2)
> ;; WHEN: Fri Sep 21 01:45:44 2018
> ;; MSG SIZE rcvd: 481
> {code}
> But I get this in the logs when running Keycloak in standalone cluster:
> {code}
> 17:45:10,121 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-3,null,null) Performing initial discovery
> 17:45:10,154 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-3,null,null) Entries collected from DNS: [10.42.3.56:0, 10.42.3.56:0, 10.42.3.44:0, 10.42.3.44:0]
> 17:45:10,155 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-3,null,null) Discovered IP Address with port 0 (10.42.3.56:0). Replacing with default Transport port: 7600
> 17:45:10,159 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-3,null,null) Discovered IP Address with port 0 (10.42.3.56:0). Replacing with default Transport port: 7600
> 17:45:10,159 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-3,null,null) Discovered IP Address with port 0 (10.42.3.44:0). Replacing with default Transport port: 7600
> 17:45:10,159 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-3,null,null) Discovered IP Address with port 0 (10.42.3.44:0). Replacing with default Transport port: 7600
> 17:45:10,159 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-3,null,null) Performing discovery of the following hosts [10.42.3.56:7600, 10.42.3.44:7600, e200a617bf7a]
> 17:45:10,159 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-3,null,null) e200a617bf7a: sending discovery request to 10.42.3.56:7600
> 17:45:10,160 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-3,null,null) e200a617bf7a: sending discovery request to 10.42.3.44:7600
> 17:45:10,160 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-10,ejb,e200a617bf7a) Received discovery from: e200a617bf7a, IP: 10.42.3.44:7600
> 17:45:10,161 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-3,null,null) e200a617bf7a: sending discovery request to e200a617bf7a
> 17:45:10,162 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-11,ejb,e200a617bf7a) Received discovery from: e200a617bf7a, IP: 10.42.3.44:7600
> {code}
> As you can see it is resolving the DNS addresses, but discarding the ports.
> To be clear, in this example 32923 ids the port (eg:
> 1 1 32923 60b5a820-9678-4bd2-84c6-00061a52bde0.jgroups.dev.auth.example.com.svc.cluster.local).
> These are dynamic ports mapped to port 7600 in order to put more Keycloak containers on each instance.
> {code}
> $ docker ps
> CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
> f67e39f8f403 datadog/agent:latest-jmx "/init" 8 hours ago Up 8 hours (healthy) 8125/udp, 8126/tcp ecs-auth-service-dev-26-datadog-agent-a2b7f783ddd0ba9cf601
> bbb12f0c43a5 233747045000.dkr.ecr.us-east-2.amazonaws.com/ops/keycloak:latest "/opt/jboss/tools/do…" 8 hours ago Up 8 hours 0.0.0.0:32923->7600/tcp, 0.0.0.0:32922->8080/tcp ecs-auth-service-dev-26-keycloak-f4bd8f8dca9fd4cd4f00
> 932cad7c4fb9 datadog/agent:latest-jmx "/init" 8 hours ago Up 8 hours (healthy) 8125/udp, 8126/tcp ecs-auth-service-dev-26-datadog-agent-baa38a98ccaddea6f501
> e200a617bf7a 233747045000.dkr.ecr.us-east-2.amazonaws.com/ops/keycloak:latest "/opt/jboss/tools/do…" 8 hours ago Up 8 hours 0.0.0.0:32921->7600/tcp, 0.0.0.0:32920->8080/tcp ecs-auth-service-dev-26-keycloak-e6f398e6cc8db5b5f101
> 73bc0b863c73 amazon/amazon-ecs-agent:latest "/agent" 2 days ago Up 2 days ecs-agent
> {code}
> This seems like it might be where ports are getting lost:
> https://github.com/belaban/JGroups/blob/07060c3ba6e52ad4aad3ac799c2bc95ff...
> I don't see the port number being extracted from the SRV entry and appended to the IP returned from resolveAEntries.
> Let me know if I am missing any details. This is a major blocker for development.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (DROOLS-3037) [DMN Designer] Added item definition has not icon of structure
by Jozef Marko (JIRA)
Jozef Marko created DROOLS-3037:
-----------------------------------
Summary: [DMN Designer] Added item definition has not icon of structure
Key: DROOLS-3037
URL: https://issues.jboss.org/browse/DROOLS-3037
Project: Drools
Issue Type: Bug
Components: DMN Editor
Affects Versions: 7.12.0.Final
Reporter: Jozef Marko
Assignee: Guilherme Carreiro
Attachments: Screenshot from 2018-09-26 12-33-28.png
If user add custom item definition and define it as structure, the item definition misses the structure icon set the attached picture. There is new custom structure item definition *a* without icon. Compare it with other structure item definitions.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (JGRP-2298) InputStream is processed after the different version error
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2298?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2298:
---------------------------
Fix Version/s: 4.0.16
(was: 4.0.15)
> InputStream is processed after the different version error
> ----------------------------------------------------------
>
> Key: JGRP-2298
> URL: https://issues.jboss.org/browse/JGRP-2298
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.11, 4.0.13
> Environment: OS: Debian 8
> Reporter: Boris Kantor
> Assignee: Bela Ban
> Fix For: 4.0.16
>
>
> Occasionally JGroups shows up a warning when receiving a message with a different JGroups version:
> {{JGRP000010: packet from 10.10.10.130:7800 has different version (0.0.0) than ours (4.0.11); packet is discarded | (Log4J2LogImpl.java:91)}}
> Although the message is then discarded, the socket connection will be kept open. The input stream still contains data that will be processed and falsly interpreted as the next message.
> If you have bad luck, the next bytes will match the correct version number. This leads then to following errors:
> {code:java}
> 2018-07-17 10:15:34.052 [Connect | ] WARN TCP - JGRP000010: packet from 10.10.10.130:7800 has different version (0.0.0) than ours (4.0.11); packet is discarded | (Log4J2LogImpl.java:91)
> 2018-07-17 10:15:34.059 [Connect | ] ERROR TCP - JGRP000030: jgm113: failed handling incoming message | (Log4J2LogImpl.java:116)
> java.lang.ClassNotFoundException: Class for magic number 8237 cannot be found
> at org.jgroups.conf.ClassConfigurator.create(ClassConfigurator.java:118)
> at org.jgroups.Message.readHeader(Message.java:869)
> at org.jgroups.Message.readFrom(Message.java:742)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1346)
> at org.jgroups.protocols.TP.receive(TP.java:1323)
> at org.jgroups.blocks.cs.BaseServer.receive(BaseServer.java:171)
> at org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:290)
> at eu.application.nac.cluster.jgroups.JGroupsTask.execute(JGroupsTask.java:41)
> at eu.application.nac.engine.scheduling.Task.run(Task.java:339)
> at java.lang.Thread.run(Thread.java:745)
> 2018-07-17 10:15:34.065 [Connect | ] ERROR TCP - JGRP000030: jgm113: failed handling incoming message | (Log4J2LogImpl.java:116)
> java.lang.ClassNotFoundException: Class for magic number 8237 cannot be found
> at org.jgroups.conf.ClassConfigurator.create(ClassConfigurator.java:118)
> at org.jgroups.Message.readHeader(Message.java:869)
> at org.jgroups.Message.readFrom(Message.java:742)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1346)
> at org.jgroups.protocols.TP.receive(TP.java:1323)
> at org.jgroups.blocks.cs.BaseServer.receive(BaseServer.java:171)
> at org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:290)
> at eu.application.nac.cluster.jgroups.JGroupsTask.execute(JGroupsTask.java:41)
> at eu.application.nac.engine.scheduling.Task.run(Task.java:339)
> at java.lang.Thread.run(Thread.java:745)
> 2018-07-17 10:15:34.072 [Connect | ] ERROR TCP - JGRP000030: jgm113: failed handling incoming message | (Log4J2LogImpl.java:116)
> java.io.IOException: length has to be 4 or 16 bytes (was 47 bytes)
> at org.jgroups.stack.IpAddress.readFrom(IpAddress.java:171)
> at org.jgroups.util.Util.readAddress(Util.java:1379)
> at org.jgroups.Message.readFrom(Message.java:731)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1346)
> at org.jgroups.protocols.TP.receive(TP.java:1323)
> at org.jgroups.blocks.cs.BaseServer.receive(BaseServer.java:171)
> at org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:290)
> at eu.application.nac.cluster.jgroups.JGroupsTask.execute(JGroupsTask.java:41)
> at eu.application.nac.engine.scheduling.Task.run(Task.java:339)
> at java.lang.Thread.run(Thread.java:745)
> 2018-07-17 10:15:34.076 [Connect | ] ERROR TCP - JGRP000030: jgm113: failed handling incoming message | (Log4J2LogImpl.java:116)
> java.lang.ClassNotFoundException: Class for magic number 28789 cannot be found
> at org.jgroups.conf.ClassConfigurator.create(ClassConfigurator.java:118)
> at org.jgroups.Message.readHeader(Message.java:869)
> at org.jgroups.Message.readFrom(Message.java:742)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1346)
> at org.jgroups.protocols.TP.receive(TP.java:1323)
> at org.jgroups.blocks.cs.BaseServer.receive(BaseServer.java:171)
> at org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:290)
> at eu.application.nac.cluster.jgroups.JGroupsTask.execute(JGroupsTask.java:41)
> at eu.application.nac.engine.scheduling.Task.run(Task.java:339)
> at java.lang.Thread.run(Thread.java:745)
> 2018-07-17 10:15:34.077 [Connect | ] ERROR TCP - JGRP000030: jgm113: failed handling incoming message | (Log4J2LogImpl.java:116)
> java.lang.ClassNotFoundException: Class for magic number 8237 cannot be found
> at org.jgroups.conf.ClassConfigurator.create(ClassConfigurator.java:118)
> at org.jgroups.Message.readHeader(Message.java:869)
> at org.jgroups.Message.readFrom(Message.java:742)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1346)
> at org.jgroups.protocols.TP.receive(TP.java:1323)
> at org.jgroups.blocks.cs.BaseServer.receive(BaseServer.java:171)
> at org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:290)
> at eu.application.nac.cluster.jgroups.JGroupsTask.execute(JGroupsTask.java:41)
> at eu.application.nac.engine.scheduling.Task.run(Task.java:339)
> at java.lang.Thread.run(Thread.java:745)
> 2018-07-17 10:15:34.078 [Connect | ] ERROR TCP - JGRP000030: jgm113: failed handling incoming message | (Log4J2LogImpl.java:116)
> java.io.IOException: length has to be 4 or 16 bytes (was 47 bytes)
> at org.jgroups.stack.IpAddress.readFrom(IpAddress.java:171)
> at org.jgroups.util.Util.readAddress(Util.java:1379)
> at org.jgroups.Message.readFrom(Message.java:731)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1346)
> at org.jgroups.protocols.TP.receive(TP.java:1323)
> at org.jgroups.blocks.cs.BaseServer.receive(BaseServer.java:171)
> at org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:290)
> at eu.application.nac.cluster.jgroups.JGroupsTask.execute(JGroupsTask.java:41)
> at eu.application.nac.engine.scheduling.Task.run(Task.java:339)
> at java.lang.Thread.run(Thread.java:745)
> 2018-07-17 10:15:34.078 [Connect | ] ERROR TCP - JGRP000030: jgm113: failed handling incoming message | (Log4J2LogImpl.java:116)
> java.lang.ClassNotFoundException: Class for magic number 8237 cannot be found
> at org.jgroups.conf.ClassConfigurator.create(ClassConfigurator.java:118)
> at org.jgroups.Message.readHeader(Message.java:869)
> at org.jgroups.Message.readFrom(Message.java:742)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1346)
> at org.jgroups.protocols.TP.receive(TP.java:1323)
> at org.jgroups.blocks.cs.BaseServer.receive(BaseServer.java:171)
> at org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:290)
> at eu.application.nac.cluster.jgroups.JGroupsTask.execute(JGroupsTask.java:41)
> at eu.application.nac.engine.scheduling.Task.run(Task.java:339)
> at java.lang.Thread.run(Thread.java:745)
> 2018-07-17 10:15:34.079 [Connect | ] ERROR TCP - JGRP000030: jgm113: failed handling incoming message | (Log4J2LogImpl.java:116)
> java.io.IOException: length has to be 4 or 16 bytes (was 47 bytes)
> at org.jgroups.stack.IpAddress.readFrom(IpAddress.java:171)
> at org.jgroups.util.Util.readAddress(Util.java:1379)
> at org.jgroups.Message.readFrom(Message.java:731)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1346)
> at org.jgroups.protocols.TP.receive(TP.java:1323)
> at org.jgroups.blocks.cs.BaseServer.receive(BaseServer.java:171)
> at org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:290)
> at eu.application.nac.cluster.jgroups.JGroupsTask.execute(JGroupsTask.java:41)
> at eu.application.nac.engine.scheduling.Task.run(Task.java:339)
> at java.lang.Thread.run(Thread.java:745)
> 2018-07-17 10:15:34.080 [Connect | ] ERROR TCP - JGRP000030: jgm113: failed handling incoming message | (Log4J2LogImpl.java:116)
> java.lang.ClassNotFoundException: Class for magic number 12320 cannot be found
> at org.jgroups.conf.ClassConfigurator.create(ClassConfigurator.java:118)
> at org.jgroups.Message.readHeader(Message.java:869)
> at org.jgroups.Message.readFrom(Message.java:742)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1346)
> at org.jgroups.protocols.TP.receive(TP.java:1323)
> at org.jgroups.blocks.cs.BaseServer.receive(BaseServer.java:171)
> at org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:290)
> at eu.application.nac.cluster.jgroups.JGroupsTask.execute(JGroupsTask.java:41)
> at eu.application.nac.engine.scheduling.Task.run(Task.java:339)
> at java.lang.Thread.run(Thread.java:745)
> 2018-07-17 10:15:34.089 [Connect | ] ERROR TCP - JGRP000030: jgm113: failed handling incoming message | (Log4J2LogImpl.java:116)
> java.lang.ClassNotFoundException: Class for magic number 25193 cannot be found
> at org.jgroups.conf.ClassConfigurator.create(ClassConfigurator.java:118)
> at org.jgroups.Message.readHeader(Message.java:869)
> at org.jgroups.Message.readFrom(Message.java:742)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1346)
> at org.jgroups.protocols.TP.receive(TP.java:1323)
> at org.jgroups.blocks.cs.BaseServer.receive(BaseServer.java:171)
> at org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:290)
> at eu.application.nac.cluster.jgroups.JGroupsTask.execute(JGroupsTask.java:41)
> at eu.application.nac.engine.scheduling.Task.run(Task.java:339)
> at java.lang.Thread.run(Thread.java:745)
> 2018-07-17 10:15:34.107 [Connect | ] ERROR TCP - JGRP000030: jgm113: failed handling incoming message | (Log4J2LogImpl.java:116)
> java.lang.ClassNotFoundException: Class for magic number 25970 cannot be found
> at org.jgroups.conf.ClassConfigurator.create(ClassConfigurator.java:118)
> at org.jgroups.Message.readHeader(Message.java:869)
> at org.jgroups.Message.readFrom(Message.java:742)
> at org.jgroups.util.Util.readMessageBatch(Util.java:1193)
> at org.jgroups.protocols.TP.handleMessageBatch(TP.java:1329)
> at org.jgroups.protocols.TP.receive(TP.java:1321)
> at org.jgroups.blocks.cs.BaseServer.receive(BaseServer.java:171)
> at org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:290)
> at eu.application.nac.cluster.jgroups.JGroupsTask.execute(JGroupsTask.java:41)
> at eu.application.nac.engine.scheduling.Task.run(Task.java:339)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> When it comes to the payload of the message the size of the payload can be as big as 2GB ({{len=in.readInt();}}). On small machines this will lead to an OutOfMemoryError.
> There is a need for some handling of such misinterpreted messages. Like closing and reopening a socket connection or completely ignoring the following bytes until a new message begins or an other algorithm that would prevent the processing of the remaining bytes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months