Eclipse Community Forums: EMF » [CDO/Net4j] Sound check if TCPAcceptor could have been activated

Home

Home » Modeling » EMF » [CDO/Net4j] Sound check if TCPAcceptor could have been activated

[CDO/Net4j] Sound check if TCPAcceptor could have been activated [message #1063471]

Thu, 13 June 2013 05:20

Eclipse User

Hi @all,

For using CDO I create a simple server using the following (TCP) acceptor:

// ...
IAcceptor acceptor = (IAcceptor) container.getElement(
					"org.eclipse.net4j.acceptors", "tcp",
					"0.0.0.0");

// check if ok...
if (LifecycleUtil.isActive(acceptor)) { /* ... */ } // <--- not meaningful, continue reading

Of course, the whole process fails, if I try to start two servers. Then, I get the followign exception:

ERROR [TCPSelector]: Address already in use: bind
java.net.BindException: Address already in use: bind
	at sun.nio.ch.Net.bind(Native Method)
	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:124)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:52)
	at org.eclipse.net4j.internal.tcp.TCPAcceptor.handleRegistration(TCPAcceptor.java:136)
	at org.eclipse.net4j.internal.tcp.TCPSelector.executeRegistration(TCPSelector.java:389)
	at org.eclipse.net4j.internal.tcp.TCPSelector.access$0(TCPSelector.java:380)
	at org.eclipse.net4j.internal.tcp.TCPSelector$1.run(TCPSelector.java:71)
	at org.eclipse.net4j.internal.tcp.TCPSelector.processOperations(TCPSelector.java:376)
	at org.eclipse.net4j.internal.tcp.TCPSelector.run(TCPSelector.java:158)
	at java.lang.Thread.run(Thread.java:662)

After this exception the acceptor will be deactivated (Net4j code)... asynchronously! Before this usually happens the acceptor is activated and seems to be fine (however, the server is obviously not running). This method is called on exception:

 protected void deactivateAsync()
  {
    // Cancel the selection immediately
    cancelSelectionKey();

    // Do the rest of the deactivation asynchronously
    getConfig().getReceiveExecutor().execute(new Runnable()
    {
      public void run()
      {
        deactivate();
      }
    });
  }

My question: how can I process all this asynchronous stuff before I do other stuff assuming that the server start is fine? Or: how can I determine that the server is actually running (ignoring the fact that the binding could collapse at any time)? Please see the comment in the first code.

Thanks in advance!

Re: [CDO/Net4j] Sound check if TCPAcceptor could have been activated [message #1063753 is a reply to message #1063471]

Fri, 14 June 2013 02:28

Eclipse User

Am 13.06.2013 11:20, schrieb Kirsten M. Z.:
> Hi @all,
>
> For using CDO I create a simple server using the following (TCP) acceptor:
>
>
> // ...
> IAcceptor acceptor = (IAcceptor) container.getElement(
> "org.eclipse.net4j.acceptors", "tcp",
> "0.0.0.0");
>
> // check if ok...
> if (LifecycleUtil.isActive(acceptor)) { /* ... */ } // <--- not meaningful, continue reading
>
>
> Of course, the whole process fails, if I try to start two servers. Then, I get the followign exception:
>
>
> ERROR [TCPSelector]: Address already in use: bind
> java.net.BindException: Address already in use: bind
Perhaps you should bind to different specific network addresses or different ports, e.g., 2036 and 2037.

> at sun.nio.ch.Net.bind(Native Method)
> at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:124)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:52)
> at org.eclipse.net4j.internal.tcp.TCPAcceptor.handleRegistration(TCPAcceptor.java:136)
> at org.eclipse.net4j.internal.tcp.TCPSelector.executeRegistration(TCPSelector.java:389)
> at org.eclipse.net4j.internal.tcp.TCPSelector.access$0(TCPSelector.java:380)
> at org.eclipse.net4j.internal.tcp.TCPSelector$1.run(TCPSelector.java:71)
> at org.eclipse.net4j.internal.tcp.TCPSelector.processOperations(TCPSelector.java:376)
> at org.eclipse.net4j.internal.tcp.TCPSelector.run(TCPSelector.java:158)
> at java.lang.Thread.run(Thread.java:662)
>
>
> After this exception the acceptor will be deactivated (Net4j code)... asynchronously! Before this usually happens the
> acceptor is activated and seems to be fine (however, the server is obviously not running). This method is called on
> exception:
>
>
> protected void deactivateAsync()
> {
> // Cancel the selection immediately
> cancelSelectionKey();
>
> // Do the rest of the deactivation asynchronously
> getConfig().getReceiveExecutor().execute(new Runnable()
> {
> public void run()
> {
> deactivate();
> }
> });
> }
>
>
> My question: how can I process all this asynchronous stuff before I do other stuff assuming that the server start is
> fine?
There's LifecycleUtil.waitForActive(Object, long) and LifecycleUtil.waitForInactive(Object, long).

> Or: how can I determine that the server is actually running (ignoring the fact that the binding could collapse at any
> time)? Please see the comment in the first code.
The term "server" is a little vague, but I would define it as the "set of repositories and acceptors" in it. There's
LifecycleUtil.isActive(Object.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Re: [CDO/Net4j] Sound check if TCPAcceptor could have been activated [message #1063803 is a reply to message #1063753]

Fri, 14 June 2013 06:08

Eclipse User

> > My question: how can I process all this asynchronous stuff before I do other stuff assuming that the server start is
> > fine?

> There's LifecycleUtil.waitForActive(Object, long) and LifecycleUtil.waitForInactive(Object, long).

This is exactly the problem... "waitForActive" doesn't work. It waits until the acceptor gets active. And it actually gets active! Unjustified in my opinion. Some milliseconds later it gets inactive, because of an async deactivation caused by the (basically) failed activation process.

Re: [CDO/Net4j] Sound check if TCPAcceptor could have been activated [message #1120214 is a reply to message #1063803]

Sun, 29 September 2013 05:57

Eclipse User

Hi again!

Sorry for digging out this "old" Topic. Right now, I want to update my CDO Version. However, I cannot update "that easily", because I modified "my" current version. And the modification is because of the issue posted above (I am not using the async deactivation in case of the error, just using a very dirty *hack*).

Then I also recognized that this discussion did not continue.

What do you think? Isn't this an issue which should be solved? If not, why? Did I miss a possiblity for a reliable check?

Re: [CDO/Net4j] Sound check if TCPAcceptor could have been activated [message #1121442 is a reply to message #1120214]

Mon, 30 September 2013 12:24

Eclipse User

Am 29.09.2013 11:57, schrieb Kirsten M. Z.:
> Hi again!
>
> Sorry for digging out this "old" Topic. Right now, I want to update my CDO Version. However, I cannot update "that
> easily", because I modified "my" current version. And the modification is because of the issue posted above (I am not
> using the async deactivation in case of the error, just using a very dirty *hack*).
> Then I also recognized that this discussion did not continue.
>
> What do you think? Isn't this an issue which should be solved?
Generally if there's a problem it should be solved. Please submit a bugzilla. My own priority to work on this is
probably not very high, as noone else has suffered from this problem during the last ten years and a workaround (check
if the port is available before activating the acceptor) seems trivial. Of course I'd appreciate if you can analyze the
problem and provide me with a patch to fix it. And of course I will try to answer your respective technical questions in
a timely manner ;-)

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

> If not, why? Did I miss a possiblity for a reliable check?

Re: [CDO/Net4j] Sound check if TCPAcceptor could have been activated [message #1121753 is a reply to message #1121442]

Mon, 30 September 2013 19:41

Eclipse User

> My own priority to work on this is probably not very high, as noone else has
> suffered from this problem during the last ten years and a workaround (check
> if the port is available before activating the acceptor) seems trivial.

Yes, for sure. Also using a delay is basically a workaround.

LifecycleUtil.waitForActive(acceptor, BASIC_TIME_OUT);
Thread.sleep(SOME_MS);
if (!LifecycleUtil.isActive(acceptor)) {
    // ok, it failed, I got it...
}

However, I always have a bad feeling using something like that. After "waitForActive" I really expect that the acceptor is active, e.g., there is no "exception pending synchronously", which sets it inactive again. I think, this was your expectation (giving me the first answer) as well.

I will raise a bugzilla, and I will try to explain the problem. I cannot provide a real fix, because I think it is a general problem in asynchronous error handling, so maybe a architectural fix is needed? As a quick hack, just wait until it is performed, use a delay etc.

Previous Topic:	TENEO JPA Annotation - create a view
Next Topic:	[Teneo] DB Keywords not always escapes

Goto Forum:

-=] Back to Top [=-

Current Time: Tue Jul 22 15:18:45 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter