Hi Stephen,
I was hoping to get some additional feedback regarding the pitch I made to
make the SimpleSocketServer available to all the GLV's. I agree with your
suggestion to create a new module gremlin-tools/gremlin-socket-server as it
seems like a good first step towards some sort of universal test server.
Unfortunately it doesn't immediately resolve any dependency issues.
TestWSGremlinInitializer which I would want to include in this new module
depends on several components of gremlin-driver including RequestMessage,
ResponseMessage, and some of the serializers. This is precisely the reason
that gremlin-server has a dependence on the driver as well and creates a
cyclic dependency problem between the driver and the new test server
module. After discussions with the BitQuill team we see 3 options:
1. Refactor gremlin-driver and extract all classes which are needed by the
server into gremlin-core or some other new module. By moving all of:
tinkerpop.gremlin.driver.message.*
tinkerpop.gremlin.driver.ser.*
tinkerpop.gremlin.driver.MessageSerializer
tinkerpop.gremlin.driver.Tokens
into a new package, the gremlin-tools/gremlin-socket-server will have
access to all of the classes it needs without a dependency on
gremlin-driver, resolving the cyclic dependency issue. Furthermore this
change would allow us to reduce gremlin-server's dependency on
gremlin-driver to a test scope which I believe is an improvement.
Pros: Most robust and long term solution. Allows the extraction of
SimpleSocketServer from gremlin-driver without losing and functionality or
ability for future extension. Allows all GLV's to depend on the test server
without a dependence on gremlin-driver. Provides a good foundation to build
a universal test server for all the GLV's.
Cons: Represents a huge structural change to gremlin-driver. Would need
a lot of consideration in how to handle this move to minimize user impact.
2. Create a docker image from the simple-socket-server as it currently
exists as part of the java driver. Publish this image to dockerhub, and
configure GLV’s to run tests against this image.
Pros: Allows the socket server to continue with all its current
features and be accessible to all GLV’s without creating a direct
dependency on the java driver. No significant changes required to java
driver.
Cons: Having a published test image represents a barrier to changing
and adding new functionality or testing behaviours to the socket-server.
3. Extract Simple-Socket-Server to a new module and remove all dependencies
on the java driver. Dependence on serializers and ResponseMessage classes
could be stripped out in favour of hardcoded response strings. As it stands
right now the socket server is only used to test for a small handful of
scenarios and it would be fairly straightforward to have a few hardcoded
responses to select from.
Pros: Completely removes dependency on java driver without any large or
breaking changes.
Cons: Limits the ability to grow and extend the current socket server.
Not a useful step towards the universal test server which Stephen has been
talking about.
Of all of these my preference is to go with number 1. I believe it would be
a good improvement to the structure of tinkerpop, but I'm not sure how best
to handle the migration. 2 and 3 both represent shorter term solutions to
get some use of SimpleSocketServer in the GLV's but don't make the same
progress towards standardizing the testing between all the GLV's. I suppose
a 4th option is to shelve all of this for now and proceed with maintaining
independent connection tests for all the GLV's but my preference would be
to try and improve on this where possible.
Thanks,
*Cole Greer*
On Mon, Oct 17, 2022 at 5:03 AM Stephen Mallette <[email protected]>
wrote:
> If you think it's helpful, I'd say that's fine. Are you suggesting it be
> moved from gremlin-driver/src/test to gremlin-server/src/main? maybe it
> would go best in a new /server/util/test package?
>
> The only problem with moving it is that you end up with a circular
> relationship. gremlin-server depends on gremlin-driver so if you move it
> the gremlin-driver tests that depend on it won't work anymore. It's a bit
> weird but maybe you keep it in gremlin-driver and just move it to
> gremlin-driver/.../util/test?
>
> Or I guess the driver tests could move to gremlin-server along with the
> SimpleSocketServer related classes? that's a bit weird too though.
>
> Or maybe a new module is on order? create
> gremlin-tools/gremlin-socket-server? i think you'd avoid dependency issues
> there between gremlin-driver and gremlin-server and the GLVs. Maybe this is
> the best way as it would allow the independent development of a really
> robust test server without muddying existing packages with test components.
>
> Sorry, I just sorta rambled my way to that last point which seems like it
> could be the best one.
>
>
>
>
> On Fri, Oct 14, 2022 at 4:27 PM Cole Greer <[email protected]
> .invalid>
> wrote:
>
> > Hi everyone,
> >
> > I have been working on TINKERPOP-2480 according to Ken's recent
> > proposal (
> https://lists.apache.org/thread/x8lt6mk04r7h0nsdy9q3pz1pbo1t28tj
> > ).
> > I have found that the SimpleSocketServer combined with
> > TestWSGremlinInitializer in Gremlin-Driver to be a very useful
> > resource for creating tests which require custom response behaviour
> > from the server. From what I have seen this is something which the
> > other GLV's are currently lacking. I believe having such a test server
> > accessible to the other GLV's would be a useful step towards
> > standardizing the testing between all the GLV's and bringing more
> > behavioural tests to the GLV's. In order to do this I would propose
> > moving the SimpleSocketServer from the tinkerpop.gremlin.driver
> > package to tinkerpop.gremlin.server and running it in the existing
> > gremlin-server-test docker container on a new port.
> >
> > I would greatly appreciate any feedback on this idea, whether you find
> > it to be useful or have any concerns.
> >
> > Thanks,
> >
> > Cole
> >
>
