[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 commented on JGRP-2298:
--------------------------------
Since even {{Length}} might be incorrect, we don;'t know how many bytes to discard. IMP, the safest solution would be to throw an exception, catch it in TCP (TcpConnection) and simply close the connection.
> 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
> Priority: Major
> 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.12.1#712002)
7 years, 6 months
[JBoss JIRA] (LOGMGR-210) Use the StackTraceFormatter to render the stack trace for structured formatters
by James Perkins (Jira)
James Perkins created LOGMGR-210:
------------------------------------
Summary: Use the StackTraceFormatter to render the stack trace for structured formatters
Key: LOGMGR-210
URL: https://issues.jboss.org/browse/LOGMGR-210
Project: JBoss Log Manager
Issue Type: Task
Reporter: James Perkins
Assignee: James Perkins
Currently the {{StructuredFormatter}} formats the stack trace by using {{Throwable.printStackTrace()}}. Some JVM vendors format stack traces differently and in the case of the IBM J9 JVM there is a bug that causes a {{StackOverflowError}} with duplicated suppressed exceptions. Using the {{StructuredFormatter}} will be more consistent with how the {{PatternFormatter}} formats exceptions.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (DROOLS-1942) [DMN Editor] InformationItem's "Name" is always the same as the containing node
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-1942?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-1942:
-----------------------------------
Story Points: 3
> [DMN Editor] InformationItem's "Name" is always the same as the containing node
> -------------------------------------------------------------------------------
>
> Key: DROOLS-1942
> URL: https://issues.jboss.org/browse/DROOLS-1942
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
>
> Whilst an {{InformationItem}} Node has a "Name" its value is always the same as the containing Node's "Name" (for {{InputData}}, {{Decision}} and {{BusinessKnowledgeModel}}). {{ContextEntry}}'s "Name" are not the same as outer most node's "Name" (as a {{ContextEntry}} is contained within a {{Context}} and not directly in a node itself).
> It is proposed that this synchronization should be handled in the "Stunner to (org.kie) DMN model" marshalling. Therefore we need to remove the "Name" {{@FormField}} from {{InformationItem}}.
> [~tari_manga] [~tirelli] Please confirm.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (DROOLS-3249) [DMN Designer] Add support for optional typeRefs
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3249?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-3249:
-----------------------------------
Story Points: 3 (was: 5)
> [DMN Designer] Add support for optional typeRefs
> ------------------------------------------------
>
> Key: DROOLS-3249
> URL: https://issues.jboss.org/browse/DROOLS-3249
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.14.0.Final
> Reporter: Michael Anstis
> Assignee: Daniel José dos Santos
> Priority: Critical
> Labels: drools-tools
>
> At the moment {{TypeRef}} is a mandatory field within the editor.
> This is a hard limitation of use of the Properties Panel bean-binding (it cannot bind to {{null}} values). However the DMN Specification states that {{TypeRef}} are optional (and we are working around by changing the _default_ to {{Any}} - see [DROOLS-3248|https://issues.jboss.org/browse/DROOLS-3248]).
> We need to change the UI and marshaller to be able to support _optional_ {{TypeRef}}. This would (probably) require adding a _magic_ value to {{BuiltInType}} representing a "null" selection. It would need to:
> - Appear at the top of the "Data Type selector" widget (with label "<None>" or similar)
> - Be the _selected_ option when the {{TypeRef}} is the new _magic_ value (this should happen automatically, but worth checking!)
> - The marshaller should set the {{TypeRef}} to the _magic_ {{BuiltInType}} if the DMN model (coming from XML->{{kie-dmn-model}}->workbench model) has a {{null}} {{TypeRef}} - the _magic_ value is only to be used _client-side_.
> - The marshaller should set the {{TypeRef}} to {{null}} when converting from the workbench model to {{kie-dmn-model}} and the workbench model {{TypeRef}} is the _magic_ value - again, the _magic_ value is only to be used _client-side_.
> - Check that creating new data-types does not show the _magic_ value (it uses a different widget, but population of the widget probably iterates all {{BuiltInType}}.
> [~tari_manga] [~karreiro] seem reasonable to you?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (DROOLS-3250) [DMN Designer] Information Item name is empty by default
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3250?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-3250:
-----------------------------------
Story Points: 3
> [DMN Designer] Information Item name is empty by default
> --------------------------------------------------------
>
> Key: DROOLS-3250
> URL: https://issues.jboss.org/browse/DROOLS-3250
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.14.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
>
> The properties of decision has two sections with *Name* property. One general *Decision Name* and one *Information Item Name*.
> The second *Information Item Name* reflects in <variable/> tag of the backing xml file. Its value important for the runtime.
> I think we should solve this issue doing two actions:
> - Make *Information Item Name* readonly
> - Set *Information Item Name* automatically according to *Decision Name*
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months