db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <kristian.waa...@oracle.com>
Subject Re: Derby client fails to connect to server every time after updating to 10.8.1.2
Date Fri, 02 Sep 2011 06:18:32 GMT
On 02.09.11 07:40, Trejkaz wrote:
> Hi all.
>
> We have tests (and apps, naturally) which start up the network server
> and then test that connecting to it works.  One test runs our wrapping
> around the server and uses bare JDBC code to verify that it's
> connectable.  The other test runs our wrapping around the client and
> uses bare NetworkServerControl calls to start the server.  Both of
> these tests fail after updating from 10.6.1.0 ->  10.8.1.2.

Hi,

The code below works for me with 10.8.1.2. I also added code to select 
from a system table - just to get some output.
I don't have to set the user either (I think a default will be used).

So why is it working for me, but not for you:
  o which Derby jars are you running off?
  o what are typical values of the scratch variable?
  o which platform are you running on?
  o which JVM is being used?
  o anything else in the test framework (or apps) that may cause this?
    (i.e., is configuration settings being picked up from somewhere?)


Regards,
-- 
Kristian

>
> The error I am getting:
>
> Fri Sep 02 15:21:40 EST 2011 : Execution failed because of a
> Distributed Protocol Error:  DRDA_Proto_SYNTAXRM; CODPNT arg  = 115a;
> Error Code Value = 9. Plaintext connection attempt from an SSL enabled
> client?
> org.apache.derby.impl.drda.DRDAProtocolException: Execution failed
> because of a Distributed Protocol Error:  DRDA_Proto_SYNTAXRM; CODPNT
> arg  = 115a; Error Code Value = 9. Plaintext connection attempt from
> an SSL enabled client?
> 	at org.apache.derby.impl.drda.DRDAConnThread.throwSyntaxrm(DRDAConnThread.java:517)
> 	at org.apache.derby.impl.drda.DRDAConnThread.tooBig(DRDAConnThread.java:8160)
> 	at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSAT(DRDAConnThread.java:1583)
> 	at org.apache.derby.impl.drda.DRDAConnThread.exchangeServerAttributes(DRDAConnThread.java:1148)
> 	at org.apache.derby.impl.drda.DRDAConnThread.sessionInitialState(DRDAConnThread.java:672)
> 	at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:283)
>
> I joined the unit tests to form one test which doesn't use any of our
> own code, and the same error occurs.  The test does require a
> 'scratch' field to be set up... which is unfortunately still part of
> our test framework. :/
>
>      @Test
>      public void test() throws Exception
>      {
>          File dbDir = new File(scratch, "db");
>
>          EmbeddedConnectionPoolDataSource ds1 = new
> EmbeddedConnectionPoolDataSource();
>          ds1.setDatabaseName(dbDir.getAbsolutePath());
>          ds1.setCreateDatabase("create");
>          ds1.getConnection().close();
>
>          NetworkServerControl server = new
> NetworkServerControl(InetAddress.getByName("127.0.0.1"), 27000);
>          try
>          {
>              server.start(null);
>
>              ClientConnectionPoolDataSource ds = new
> ClientConnectionPoolDataSource();
>              ds.setServerName("127.0.0.1");
>              ds.setPortNumber(27000);
>              ds.setDatabaseName(dbDir.getAbsolutePath());
>              ds.setUser("bob");
>
>              Connection connection = ds.getConnection();
>              connection.close();
>          }
>          finally
>          {
>              server.shutdown();
>
>              // clean up after ourselves
>              EmbeddedConnectionPoolDataSource ds2 = new
> EmbeddedConnectionPoolDataSource();
>              ds2.setDatabaseName(dbDir.getAbsolutePath());
>              ds2.setShutdownDatabase("shutdown");
>              try { ds2.getConnection(); } catch (SQLException e) { /*
> expected */ }
>          }
>      }
>
> The same code still works fine on 10.6.1.0.
>
> Additionally, on 10.6.1.0 I don't have to set the user.  I searched
> the changelog and couldn't see anything about a user now being
> mandatory, but I assume this has changed for security reasons?
>
> TX


Mime
View raw message