tracking receivers?
Hello Carl, Does it make sense to track receivers? For example, we probably do not want to create the same receiver multiple times upon reconfiguration. Is such tracking currently performed some place? If not I would propose a RECEIVER bag similar to the appenderBag. See use of ActionConst.APPENDER_BAG. Comments and/or other ideas welcome. -- Ceki 65% of statistics are made up on the spot
Does it make sense to track receivers? For example, we probably do not want to create the same receiver multiple times upon reconfiguration. Is such tracking currently performed some place? If not I would propose a RECEIVER bag similar to the appenderBag. See use of ActionConst.APPENDER_BAG.
Yes, it makes sense to track them. My understanding of both LoggerContext.stop and LoggerContext.reset was apparently a bit muddled. Seems like there are two possible approaches to dealing with receivers during (re-)configuration: 1. In LoggerContext.reset, we could stop() all of the receivers in the bag. Stopping the receiver closes all open connections, and in the case of a passive receiver also closes the listening ServerSocket. If the receiver were stopped during a reset, it would be okay to recreate it. It may be also be desirable to use ServerSocket.setReuseAddress to ensure that the local address for a passive receiver can be re-bound. 2. We could add a name attribute to the receiver and in ReceiverAction.begin, we could check the bag to see if a receiver of the same name has already been created. If a receiver with the same name has already been created, we would not create it again, and in ReceiverAction.end, we would not invoke the existing receiver's start method. In either case, in order for the receivers to be cleaned up properly, we will need to stop all of the receivers in the bag. If we choose option 2, we will still need to modify LoggerContext.stop so that it stops all receivers in the bag. Comments or alternatives? carl
On 4/22/2013 12:05 PM, Harris, Carl wrote:
Yes, it makes sense to track them.
My understanding of both LoggerContext.stop and LoggerContext.reset was apparently a bit muddled.
Seems like there are two possible approaches to dealing with receivers during (re-)configuration:
1. In LoggerContext.reset, we could stop() all of the receivers in the bag. Stopping the receiver closes all open connections, and in the case of a passive receiver also closes the listening ServerSocket. If the receiver were stopped during a reset, it would be okay to recreate it. It may be also be desirable to use ServerSocket.setReuseAddress to ensure that the local address for a passive receiver can be re-bound.
Stopping all receivers and related threads in response to Context.reset would clean the slate, assuming new receivers can be bound to the port about to be relinquished. Setting ServerSocket.setReuseAddress(true) gives us just that.
2. We could add a name attribute to the receiver and in ReceiverAction.begin, we could check the bag to see if a receiver of the same name has already been created. If a receiver with the same name has already been created, we would not create it again, and in ReceiverAction.end, we would not invoke the existing receiver's start method.
That would work fine if the parameters of the named receiver did not change in the new configuration. However, if those parameters were to change, then the 1st alternative would work better.
In either case, in order for the receivers to be cleaned up properly, we will need to stop all of the receivers in the bag. If we choose option 2, we will still need to modify LoggerContext.stop so that it stops all receivers in the bag.
Naming the receivers and placing them in a map by name would allow users to retrieve a receiver by name and set its properties programmatically. Considering the above, shall we go for option 1 and also place the receivers in in map by name? -- Ceki
participants (3)
-
ceki -
Ceki Gülcü
-
Harris, Carl