Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

suggestion: netty/example/objectecho inform about missing "implements Serializable" on client side #10777

Closed
oxplay2 opened this issue Nov 6, 2020 · 3 comments · Fixed by #10807
Milestone

Comments

@oxplay2
Copy link

oxplay2 commented Nov 6, 2020

Hello,

as new user i wanted to try Objectecho "Example", and was confused when i sent Serializable Object that were containing an "non-serializable" Object as some depth field(that i didnt notice earlier), it was not sent at all, and i received no information at all. It took me time to debug and notice that one of its fields was an object that didnt implement Serializable.

Thats why i just throw some suggestion to add into "Objectecho Example" some new user friendly code to inform about it like:

1) some "Objectecho Example" class extending ObjectEncoder:

@Override
public boolean acceptOutboundMessage(Object msg) throws Exception {
    if(!super.acceptOutboundMessage(msg)){
        // some information
    }
    return true;
}

OR

(i didnt try enable Asserts, so if you use some, this option might be better)
2) Just add comment about it, to let new users know they will receive NO information when trying to send complex Objects that in some depth contains non-serializable Object.

Please note this refer only to "Objectecho Example" and Encoder (so its client side).

Just thought it could be helpfull for new users having same problem.

Expected behavior

  • some warning/error/information for "Objectecho Example" if there is missing Serializable

Actual behavior

  • Demo give NO information if sent object do not match, client and server print no information/warning/error at all.

Steps to reproduce

  • in "Objectecho Example" try sent Serializable object with not serializable Object in it, it will not be sent and no information will be printed anywhere. Also comments do not mention anything about it.

Netty version

4.1.43

And ofc, hello to netty users/devs ;)

Please close it if "Objectecho Example" is not prepared for new users and its for testing purpose, or if you think its not needed, since its just suggestion.

@hyperxpro
Copy link
Contributor

Enable DEBUG log level.

@oxplay2
Copy link
Author

oxplay2 commented Nov 7, 2020

if you mean:

p.addLast(new LoggingHandler(LogLevel.DEBUG));

do not help. No information is printed. (using non-serialized object - that dont work)



BELOW IS WORKING CASE(when i use serialized object), BUT PROBABLY FOUND SOME new BUG:

Anyway im not sure if i found some BUG or what.
im having Client+Server in same application(just in 2 threads),

by default without logging i have:

lis 07, 2020 1:08:56 PM io.netty.handler.logging.LoggingHandler channelRegistered
INFO: [id: 0x70dbfa79] REGISTERED
lis 07, 2020 1:08:56 PM io.netty.handler.logging.LoggingHandler bind
INFO: [id: 0x70dbfa79] BIND: 0.0.0.0/0.0.0.0:6143
lis 07, 2020 1:08:56 PM io.netty.handler.logging.LoggingHandler channelActive
INFO: [id: 0x70dbfa79, L:/0:0:0:0:0:0:0:0:6143] ACTIVE
lis 07, 2020 1:08:56 PM io.netty.handler.logging.LoggingHandler channelRead
INFO: [id: 0x70dbfa79, L:/0:0:0:0:0:0:0:0:6143] READ: [id: 0x1ff7f916, L:/127.0.0.1:6143 - R:/127.0.0.1:59428]
lis 07, 2020 1:08:56 PM io.netty.handler.logging.LoggingHandler channelReadComplete
INFO: [id: 0x70dbfa79, L:/0:0:0:0:0:0:0:0:6143] READ COMPLETE
Server Channel Active
ByteBuf out size: 256

when i add for example

p.addLast(new LoggingHandler(LogLevel.WARN));

i have:

lis 07, 2020 1:05:02 PM io.netty.handler.logging.LoggingHandler channelRegistered
INFO: [id: 0x47da6a0b] REGISTERED
lis 07, 2020 1:05:02 PM io.netty.handler.logging.LoggingHandler channelRegistered
WARNING: [id: 0x107f76a8] REGISTERED
lis 07, 2020 1:05:02 PM io.netty.handler.logging.LoggingHandler connect
WARNING: [id: 0x107f76a8] CONNECT: localhost/127.0.0.1:6143
lis 07, 2020 1:05:02 PM io.netty.handler.logging.LoggingHandler bind
INFO: [id: 0x47da6a0b] BIND: 0.0.0.0/0.0.0.0:6143
lis 07, 2020 1:05:02 PM io.netty.handler.logging.LoggingHandler channelActive
INFO: [id: 0x47da6a0b, L:/0:0:0:0:0:0:0:0:6143] ACTIVE
lis 07, 2020 1:05:02 PM io.netty.handler.logging.LoggingHandler channelActive
WARNING: [id: 0x107f76a8, L:/127.0.0.1:59414 - R:localhost/127.0.0.1:6143] ACTIVE
lis 07, 2020 1:05:02 PM io.netty.handler.logging.LoggingHandler channelRead
INFO: [id: 0x47da6a0b, L:/0:0:0:0:0:0:0:0:6143] READ: [id: 0x1c26ccdb, L:/127.0.0.1:6143 - R:/127.0.0.1:59414]
lis 07, 2020 1:05:02 PM io.netty.handler.logging.LoggingHandler channelReadComplete
INFO: [id: 0x47da6a0b, L:/0:0:0:0:0:0:0:0:6143] READ COMPLETE
lis 07, 2020 1:05:02 PM io.netty.handler.logging.LoggingHandler channelRegistered
WARNING: [id: 0x1c26ccdb, L:/127.0.0.1:6143 - R:/127.0.0.1:59414] REGISTERED
lis 07, 2020 1:05:02 PM io.netty.handler.logging.LoggingHandler channelActive
WARNING: [id: 0x1c26ccdb, L:/127.0.0.1:6143 - R:/127.0.0.1:59414] ACTIVE
Server Channel Active
ByteBuf out size: 256
lis 07, 2020 1:05:02 PM io.netty.handler.logging.LoggingHandler write
WARNING: [id: 0x1c26ccdb, L:/127.0.0.1:6143 - R:/127.0.0.1:59414] WRITE: 98B
+-------------------------------------------------+
| 0 1 2 3 4 5 6 7 8 9 a b c d e f |
+--------+-------------------------------------------------+----------------+

and when i set

p.addLast(new LoggingHandler(LogLevel.ERROR));

i see:

lis 07, 2020 1:06:43 PM io.netty.handler.logging.LoggingHandler channelRegistered
INFO: [id: 0xc67da6c8] REGISTERED
lis 07, 2020 1:06:43 PM io.netty.handler.logging.LoggingHandler channelRegistered
SEVERE: [id: 0x80004f41] REGISTERED
lis 07, 2020 1:06:43 PM io.netty.handler.logging.LoggingHandler connect
SEVERE: [id: 0x80004f41] CONNECT: localhost/127.0.0.1:6143
lis 07, 2020 1:06:43 PM io.netty.handler.logging.LoggingHandler bind
INFO: [id: 0xc67da6c8] BIND: 0.0.0.0/0.0.0.0:6143
lis 07, 2020 1:06:43 PM io.netty.handler.logging.LoggingHandler channelActive
INFO: [id: 0xc67da6c8, L:/0:0:0:0:0:0:0:0:6143] ACTIVE
lis 07, 2020 1:06:43 PM io.netty.handler.logging.LoggingHandler channelActive
SEVERE: [id: 0x80004f41, L:/127.0.0.1:59420 - R:localhost/127.0.0.1:6143] ACTIVE
lis 07, 2020 1:06:43 PM io.netty.handler.logging.LoggingHandler channelRead
INFO: [id: 0xc67da6c8, L:/0:0:0:0:0:0:0:0:6143] READ: [id: 0x223834f5, L:/127.0.0.1:6143 - R:/127.0.0.1:59420]
lis 07, 2020 1:06:43 PM io.netty.handler.logging.LoggingHandler channelReadComplete
INFO: [id: 0xc67da6c8, L:/0:0:0:0:0:0:0:0:6143] READ COMPLETE
Server Channel Active
lis 07, 2020 1:06:43 PM io.netty.handler.logging.LoggingHandler channelRegistered
SEVERE: [id: 0x223834f5, L:/127.0.0.1:6143 - R:/127.0.0.1:59420] REGISTERED
lis 07, 2020 1:06:43 PM io.netty.handler.logging.LoggingHandler channelActive
SEVERE: [id: 0x223834f5, L:/127.0.0.1:6143 - R:/127.0.0.1:59420] ACTIVE
ByteBuf out size: 256
lis 07, 2020 1:06:43 PM io.netty.handler.logging.LoggingHandler write
SEVERE: [id: 0x223834f5, L:/127.0.0.1:6143 - R:/127.0.0.1:59420] WRITE: 98B
+-------------------------------------------------+
| 0 1 2 3 4 5 6 7 8 9 a b c d e f |
+--------+-------------------------------------------------+----------------+

While EVERYTHING WORK FINE (since i use serialialized object in this example)

how can i know if this is SEVERE or WARN or INFO, while it just depends what level i set, it anyway print same info that is harmless...

or myabe i just dont understand what "LoggingHandler" is for

@chrisvest
Copy link
Contributor

This should help: #10807

chrisvest added a commit to chrisvest/netty that referenced this issue Nov 18, 2020
Motivation:
People may use the object serialisation example as a vehicle to test out sending their own objects across the wire.
If those objects are not actually serialisable for some reason, then we need to let the exception propagate so that this becomes obvious to people.

Modification:
Add a listener to the future that sends the first serialisable message, so that we ensure that any exceptions that shows up during serialisation becomes visible.
Without this, the state of the future that sent the first message was never checked or inspected anywhere.

Result:
Serialisation bugs in code derived from the Object Echo example are much easier to diagnose.

This fixes netty#10777
normanmaurer pushed a commit that referenced this issue Nov 19, 2020
…ple (#10807)

Motivation:
People may use the object serialisation example as a vehicle to test out sending their own objects across the wire.
If those objects are not actually serialisable for some reason, then we need to let the exception propagate so that this becomes obvious to people.

Modification:
Add a listener to the future that sends the first serialisable message, so that we ensure that any exceptions that shows up during serialisation becomes visible.
Without this, the state of the future that sent the first message was never checked or inspected anywhere.

Result:
Serialisation bugs in code derived from the Object Echo example are much easier to diagnose.

This fixes #10777
@normanmaurer normanmaurer added this to the 4.1.55.Final milestone Nov 19, 2020
normanmaurer pushed a commit that referenced this issue Nov 19, 2020
…ple (#10807)

Motivation:
People may use the object serialisation example as a vehicle to test out sending their own objects across the wire.
If those objects are not actually serialisable for some reason, then we need to let the exception propagate so that this becomes obvious to people.

Modification:
Add a listener to the future that sends the first serialisable message, so that we ensure that any exceptions that shows up during serialisation becomes visible.
Without this, the state of the future that sent the first message was never checked or inspected anywhere.

Result:
Serialisation bugs in code derived from the Object Echo example are much easier to diagnose.

This fixes #10777
raidyue pushed a commit to raidyue/netty that referenced this issue Jul 8, 2022
…ple (netty#10807)

Motivation:
People may use the object serialisation example as a vehicle to test out sending their own objects across the wire.
If those objects are not actually serialisable for some reason, then we need to let the exception propagate so that this becomes obvious to people.

Modification:
Add a listener to the future that sends the first serialisable message, so that we ensure that any exceptions that shows up during serialisation becomes visible.
Without this, the state of the future that sent the first message was never checked or inspected anywhere.

Result:
Serialisation bugs in code derived from the Object Echo example are much easier to diagnose.

This fixes netty#10777
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants