[
https://issues.apache.org/jira/browse/DERBY-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12574826#action_12574826
]
V.Narayanan commented on DERBY-3454:
------------------------------------
Thank you for the comments Serge :)
>For the flow above:
> * If (3) is executed before (2), then I guess this would be a programmatic
> error
> and a RE should be called (like IllegalStateException)
I would try to correct the case when (3) is called before (2) (fix the
programming error)
than throw an IllegalStateException
> * If (2) fails, I do also consider executing (3) after that as a
> programmatic error,
> because in this case a transmitter/receiver hasn't been properly
> initialized.
> And there's an attempt to use a transmitter/receiver which has turned up
> to
> be in an illegal state.
>You're right that the transmitter/receiver is an abstraction above the
>connection.
>But I'm just trying to say that it might be wrong (from a programmatic point
>of view)
>to try to use them in an illegal state. And might be better to properly
>process a (2)
>failure and make it so sendMessage/readMessage methods won't be called
>afterwards, instead of relying on an IOException been reported to a user.
* If there is a programmatic error causing an Unchecked Exception to be thrown
(like an NPE)
I would not correct it by throwing another Unchecked Exception
(IllegalStateException)
* If there is a programmatic error that causes an Unchecked Exception to be
thrown,like, (3)
before (2) I would correct the programmatic error than throw an unchecked
exception
* I do not agree that Properly processing a (2) failure = throwing an unchecked
exception.
* I am properly processing (2) when I try to ensure that the underlying
connection is valid
before attempting a send or a receive.
* Now that all transmitter methods verify that the underlying connection is not
invalid using
the checkSocketConnection() method the there would be no danger of attempting
(3) with a
invalid connection.
> 'java.lang.NullPointerException' is thrown when starting a master db before a
> slave one
> ---------------------------------------------------------------------------------------
>
> Key: DERBY-3454
> URL: https://issues.apache.org/jira/browse/DERBY-3454
> Project: Derby
> Issue Type: Bug
> Components: Replication
> Affects Versions: 10.4.0.0
> Reporter: Serge Tsv
> Assignee: V.Narayanan
> Attachments: Derby3454.diff, Derby3454.stat
>
>
> The 'java.lang.NullPointerException' exception is thrown when a database is
> started in a master mode and is trying to establish a connection to an slave
> database socket, which is not available.
> The exception is by the MasterController#startMaster(). First, it tries to
> setup connection with a slave database using a transmitter:
> MasterController#setupConnection
> -> transmitter = new ReplicationMessageTransmit();
> transmitter.initConnection()
> -> new InetSocketAddress() -> createSocket() -> connect()
> The connect() method throws a ConnectException, and so fails to create a
> socketConn instance. The exception is then wrapped several times an
> propagated back to the MasterController#startMaster() method. It's caught
> there and then a MasterController#teardownNetwork() method is called, which
> tries to send a STOP message using the aforementioned transmitter, which
> hasn't been able to init a connection.
> A transmitter simply tries to call socketConn.writeMessage(message), which
> throws NPE because socketConn is null.
> Thanks!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
