From gunnar at hibernate.org  Wed Dec  5 03:44:49 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 5 Dec 2018 09:44:49 +0100
Subject: [infinispan-dev] Obtaining cache via CDI on WildFly
Message-ID: <CADGJaX-2dftdvmGMo8vsVHwQ40UGSpNj+P9do-ibT+vo3E_6Rg@mail.gmail.com>

Hey,

I was trying to configure and inject an Infinispan cache through CDI,
running on WildFly 14, using the Infinispan modules provided by the
server.

While I'm not sure whether that's something supported or recommended,
I found this preferable over adding Infinispan another time as part of
the deployment. I couldn't find any recent info on doing this (would
love any pointers, though), so here's my findings, in case it's
interesting for others:

* A jboss-deployment-structure.xml file is needed for adding the
dependencies to the modules org.infinispan and org.infinispan.commons
* Unlike the core module, org.infinispan:infinispan-cdi-embedded isn't
part of WF, so it must be added to the deployment
* The transitive dependency from infinispan-cdi-embedded to
org.infinispan:infinispan-commons must be excluded, otherwise linking
errors will occur

Perhaps a small example of this could be added to the Infinispan docs?

Btw. I also couldn't find an example for configuring a cache through
jboss-cli.sh, perhaps that's something to consider, too?

Cheers,

--Gunnar

From ttarrant at redhat.com  Wed Dec  5 06:08:37 2018
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Wed, 5 Dec 2018 12:08:37 +0100
Subject: [infinispan-dev] Obtaining cache via CDI on WildFly
In-Reply-To: <CADGJaX-2dftdvmGMo8vsVHwQ40UGSpNj+P9do-ibT+vo3E_6Rg@mail.gmail.com>
References: <CADGJaX-2dftdvmGMo8vsVHwQ40UGSpNj+P9do-ibT+vo3E_6Rg@mail.gmail.com>
Message-ID: <c313c761-b72b-50a6-2390-904203f0a7cf@redhat.com>

On 12/5/18 9:44 AM, Gunnar Morling wrote:
> Hey,
> 
> I was trying to configure and inject an Infinispan cache through CDI,
> running on WildFly 14, using the Infinispan modules provided by the
> server.
> 
> While I'm not sure whether that's something supported or recommended,
> I found this preferable over adding Infinispan another time as part of
> the deployment. I couldn't find any recent info on doing this (would
> love any pointers, though), so here's my findings, in case it's
> interesting for others:

You should not be using the Infinispan subsystem that comes with WildFly 
as its configuration capabilities are a bit limited, but the modules we 
supply:

http://infinispan.org/docs/stable/user_guide/user_guide.html#infinispan_modules_for_wildfly_eap

> Btw. I also couldn't find an example for configuring a cache through
> jboss-cli.sh, perhaps that's something to consider, too?

Yes, that should be added.

Tristan

From sanne at infinispan.org  Wed Dec  5 07:01:41 2018
From: sanne at infinispan.org (Sanne Grinovero)
Date: Wed, 5 Dec 2018 12:01:41 +0000
Subject: [infinispan-dev] Obtaining cache via CDI on WildFly
In-Reply-To: <c313c761-b72b-50a6-2390-904203f0a7cf@redhat.com>
References: <CADGJaX-2dftdvmGMo8vsVHwQ40UGSpNj+P9do-ibT+vo3E_6Rg@mail.gmail.com>
	<c313c761-b72b-50a6-2390-904203f0a7cf@redhat.com>
Message-ID: <CAFm4XO2NE3NmxPALxqj7iuHCoxjSsk58UuBWjUzzNSg_oKbasQ@mail.gmail.com>

On Wed, 5 Dec 2018 at 11:16, Tristan Tarrant <ttarrant at redhat.com> wrote:
>
> On 12/5/18 9:44 AM, Gunnar Morling wrote:
> > Hey,
> >
> > I was trying to configure and inject an Infinispan cache through CDI,
> > running on WildFly 14, using the Infinispan modules provided by the
> > server.
> >
> > While I'm not sure whether that's something supported or recommended,
> > I found this preferable over adding Infinispan another time as part of
> > the deployment. I couldn't find any recent info on doing this (would
> > love any pointers, though), so here's my findings, in case it's
> > interesting for others:
>
> You should not be using the Infinispan subsystem that comes with WildFly
> as its configuration capabilities are a bit limited, but the modules we
> supply:
>
> http://infinispan.org/docs/stable/user_guide/user_guide.html#infinispan_modules_for_wildfly_eap

Hi Gunnar,
to automate such things during integration testing, have a look at the
provisioning plugins for Maven.

 - https://github.com/infinispan/infinispan/tree/master/integrationtests/wildfly-modules
 - https://github.com/infinispan/infinispan/blob/master/integrationtests/wildfly-modules/pom.xml#L222-L249
 - https://github.com/infinispan/infinispan/blob/master/integrationtests/wildfly-modules/server-provisioning.xml

One the custom WildFly is built, you can use it "as usual" via Arquillian.

Don't use the Infinispan jars included within Wildfly as those are
"implementation detail": don't have all the bits necessary (e.g. CDI
integration) and are not tested nor supportable for such use case.

Hibernate OGM does something similar:
 - https://github.com/hibernate/hibernate-ogm/blob/master/integrationtest/server-provisioning.xml
It's not listing the Infinispan modules explicitly as some specific
OGM modules depend on them transitively, but you get the idea ;)

-- Sanne

>
> > Btw. I also couldn't find an example for configuring a cache through
> > jboss-cli.sh, perhaps that's something to consider, too?
>
> Yes, that should be added.
>
> Tristan
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

From wfink at redhat.com  Wed Dec  5 07:01:44 2018
From: wfink at redhat.com (Wolf Fink)
Date: Wed, 5 Dec 2018 13:01:44 +0100
Subject: [infinispan-dev] Obtaining cache via CDI on WildFly
In-Reply-To: <c313c761-b72b-50a6-2390-904203f0a7cf@redhat.com>
References: <CADGJaX-2dftdvmGMo8vsVHwQ40UGSpNj+P9do-ibT+vo3E_6Rg@mail.gmail.com>
	<c313c761-b72b-50a6-2390-904203f0a7cf@redhat.com>
Message-ID: <CAKwmrdMcRVDYKWpQv__kpxn9WYZZmRT_aas=OYqL-ZMK4-H4+w@mail.gmail.com>

As Tristan said, the infinispan bits shipped with WildFly and its
configuration will not have all ISPN features. It might change over the
time as there is no test which ensure that any feature beside those which
are used from the WF container.
The configuration for the subsystem is different and will not allow all
features.
Also if there is a plan to move to the supported products this is not
supported!

The best option is to use the infinispan modules and configure it in
server-mode, in this case the cache lifecycle is bound to the WF instance
and can be shared/injected to all deployed applications (sharing the cache
between application in embedded mode will not work)
Note that you might use the infinispan endpoints here, but if there is a
plan to use the products the use of endpoints is not supported (as it will
make WF a hybrid server for both)

Wolf

On Wed, Dec 5, 2018 at 12:17 PM Tristan Tarrant <ttarrant at redhat.com> wrote:

> On 12/5/18 9:44 AM, Gunnar Morling wrote:
> > Hey,
> >
> > I was trying to configure and inject an Infinispan cache through CDI,
> > running on WildFly 14, using the Infinispan modules provided by the
> > server.
> >
> > While I'm not sure whether that's something supported or recommended,
> > I found this preferable over adding Infinispan another time as part of
> > the deployment. I couldn't find any recent info on doing this (would
> > love any pointers, though), so here's my findings, in case it's
> > interesting for others:
>
> You should not be using the Infinispan subsystem that comes with WildFly
> as its configuration capabilities are a bit limited, but the modules we
> supply:
>
>
> http://infinispan.org/docs/stable/user_guide/user_guide.html#infinispan_modules_for_wildfly_eap
>
> > Btw. I also couldn't find an example for configuring a cache through
> > jboss-cli.sh, perhaps that's something to consider, too?
>
> Yes, that should be added.
>
> Tristan
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20181205/0bb556cc/attachment.html 

From paul.ferraro at redhat.com  Wed Dec  5 08:22:55 2018
From: paul.ferraro at redhat.com (Paul Ferraro)
Date: Wed, 5 Dec 2018 08:22:55 -0500
Subject: [infinispan-dev] Obtaining cache via CDI on WildFly
In-Reply-To: <CADGJaX-2dftdvmGMo8vsVHwQ40UGSpNj+P9do-ibT+vo3E_6Rg@mail.gmail.com>
References: <CADGJaX-2dftdvmGMo8vsVHwQ40UGSpNj+P9do-ibT+vo3E_6Rg@mail.gmail.com>
Message-ID: <CAF5qqoPK+xikkV-dKYzvdxD_gyEzSguiEGg7pY4u-_neYPL5yA@mail.gmail.com>

Gunnar,

While WF doesn't include infinispan-cdi integration, you can inject
Infinispan caches defined within the Infinispan subsystem as standard
EE resources via the their JNDI bindings.  This approach has the
advantage of container-managed lifecycle of the cache, even when
referenced by multiple deployments.

e.g.
@Resource(lookup = "java:jboss/infinispan/cache/foo/bar")
private Cache<?, ?> cache; // References the "bar" cache of the "foo"
cache container

or

@Resource(lookup = "java:jboss/infinispan/cache/foo/default")
private Cache<?, ?> cache; // References the default cache of the
"foo" cache container

Unfortunately, a long standing weld integration bug prevents @Resource
lookups from working correctly when the containing class is
instrumented by CDI.  To workaround this, move the JNDI lookup to a
<resource-ref/> or <resource-env-ref/> in your deployment descriptor
and reference your cache resource via its reference name.

e.g.
<resource-env-ref>
    <resource-env-ref-name>my-cache<resource-env-ref-name>
    <resource-env-ref-type>org.infinispan.Cache<resource-env-ref-type>
    <lookup-name>java:jboss/infinispan/cache/foo/bar</lookup-name>
</resource-env-ref>

@Resource(name = "my-cache")
private Cache<?, ?> cache;

Paul
On Wed, Dec 5, 2018 at 3:47 AM Gunnar Morling <gunnar at hibernate.org> wrote:
>
> Hey,
>
> I was trying to configure and inject an Infinispan cache through CDI,
> running on WildFly 14, using the Infinispan modules provided by the
> server.
>
> While I'm not sure whether that's something supported or recommended,
> I found this preferable over adding Infinispan another time as part of
> the deployment. I couldn't find any recent info on doing this (would
> love any pointers, though), so here's my findings, in case it's
> interesting for others:
>
> * A jboss-deployment-structure.xml file is needed for adding the
> dependencies to the modules org.infinispan and org.infinispan.commons
> * Unlike the core module, org.infinispan:infinispan-cdi-embedded isn't
> part of WF, so it must be added to the deployment
> * The transitive dependency from infinispan-cdi-embedded to
> org.infinispan:infinispan-commons must be excluded, otherwise linking
> errors will occur
>
> Perhaps a small example of this could be added to the Infinispan docs?
>
> Btw. I also couldn't find an example for configuring a cache through
> jboss-cli.sh, perhaps that's something to consider, too?
>
> Cheers,
>
> --Gunnar
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

From gunnar at hibernate.org  Wed Dec  5 09:21:45 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 5 Dec 2018 15:21:45 +0100
Subject: [infinispan-dev] Obtaining cache via CDI on WildFly
In-Reply-To: <CAKwmrdMcRVDYKWpQv__kpxn9WYZZmRT_aas=OYqL-ZMK4-H4+w@mail.gmail.com>
References: <CADGJaX-2dftdvmGMo8vsVHwQ40UGSpNj+P9do-ibT+vo3E_6Rg@mail.gmail.com>
	<c313c761-b72b-50a6-2390-904203f0a7cf@redhat.com>
	<CAKwmrdMcRVDYKWpQv__kpxn9WYZZmRT_aas=OYqL-ZMK4-H4+w@mail.gmail.com>
Message-ID: <CADGJaX9qh61FL-uJBPa=tu_DDTkyXTmfLQRpRGk3O-8tscY4Jw@mail.gmail.com>

Hey all,

Thanks a lot for the quick replies!

To give some background on what I was trying to do: my intention was
to use a simple cache within my app for a demo + blog post I'm
creating on invalidating the JPA 2nd-level cache after external data
changes (i.e. bypassing the app) via Debezium:

    https://github.com/debezium/debezium-examples/tree/master/cache-invalidation
    https://github.com/debezium/debezium.github.io/pull/230

For that I need a simple in-app cache to keep track of all
transactions run by the app itself, so to keep them apart from
transactions run by external clients (as I need to invalidate the 2L
cache items only for the latter).

So the questions around support are not too much of a concern for my
purpose. Using the modules coming with the server seemed so easy in
comparison to putting the modules in place :) I'll try and have a look
at how this could be done in my Dockerfile (this btw. could be an
interesting example for you to have, too). Regarding CDI, I gave up on
this and just obtained a cache via the API. Seemed simpler in the end.

Thanks again,

--Gunnar


Am Mi., 5. Dez. 2018 um 13:02 Uhr schrieb Wolf Fink <wfink at redhat.com>:
>
> As Tristan said, the infinispan bits shipped with WildFly and its configuration will not have all ISPN features. It might change over the time as there is no test which ensure that any feature beside those which are used from the WF container.
> The configuration for the subsystem is different and will not allow all features.
> Also if there is a plan to move to the supported products this is not supported!
>
> The best option is to use the infinispan modules and configure it in server-mode, in this case the cache lifecycle is bound to the WF instance and can be shared/injected to all deployed applications (sharing the cache between application in embedded mode will not work)
> Note that you might use the infinispan endpoints here, but if there is a plan to use the products the use of endpoints is not supported (as it will make WF a hybrid server for both)
>
> Wolf
>
> On Wed, Dec 5, 2018 at 12:17 PM Tristan Tarrant <ttarrant at redhat.com> wrote:
>>
>> On 12/5/18 9:44 AM, Gunnar Morling wrote:
>> > Hey,
>> >
>> > I was trying to configure and inject an Infinispan cache through CDI,
>> > running on WildFly 14, using the Infinispan modules provided by the
>> > server.
>> >
>> > While I'm not sure whether that's something supported or recommended,
>> > I found this preferable over adding Infinispan another time as part of
>> > the deployment. I couldn't find any recent info on doing this (would
>> > love any pointers, though), so here's my findings, in case it's
>> > interesting for others:
>>
>> You should not be using the Infinispan subsystem that comes with WildFly
>> as its configuration capabilities are a bit limited, but the modules we
>> supply:
>>
>> http://infinispan.org/docs/stable/user_guide/user_guide.html#infinispan_modules_for_wildfly_eap
>>
>> > Btw. I also couldn't find an example for configuring a cache through
>> > jboss-cli.sh, perhaps that's something to consider, too?
>>
>> Yes, that should be added.
>>
>> Tristan
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev


From sanne at infinispan.org  Wed Dec  5 10:40:38 2018
From: sanne at infinispan.org (Sanne Grinovero)
Date: Wed, 5 Dec 2018 15:40:38 +0000
Subject: [infinispan-dev] Obtaining cache via CDI on WildFly
In-Reply-To: <CADGJaX9qh61FL-uJBPa=tu_DDTkyXTmfLQRpRGk3O-8tscY4Jw@mail.gmail.com>
References: <CADGJaX-2dftdvmGMo8vsVHwQ40UGSpNj+P9do-ibT+vo3E_6Rg@mail.gmail.com>
	<c313c761-b72b-50a6-2390-904203f0a7cf@redhat.com>
	<CAKwmrdMcRVDYKWpQv__kpxn9WYZZmRT_aas=OYqL-ZMK4-H4+w@mail.gmail.com>
	<CADGJaX9qh61FL-uJBPa=tu_DDTkyXTmfLQRpRGk3O-8tscY4Jw@mail.gmail.com>
Message-ID: <CAFm4XO2mZ3ibFUK7-VNhPnoLLJ4X2eegYbP5iBadPyAPTYDZtQ@mail.gmail.com>

Hi Gunnar,

if all you want is to invalidate Hibernate ORM's 2LC caches, Hibernate
exposes a specific API to do just that.

Sanne

On Wed, 5 Dec 2018 at 14:30, Gunnar Morling <gunnar at hibernate.org> wrote:
>
> Hey all,
>
> Thanks a lot for the quick replies!
>
> To give some background on what I was trying to do: my intention was
> to use a simple cache within my app for a demo + blog post I'm
> creating on invalidating the JPA 2nd-level cache after external data
> changes (i.e. bypassing the app) via Debezium:
>
>     https://github.com/debezium/debezium-examples/tree/master/cache-invalidation
>     https://github.com/debezium/debezium.github.io/pull/230
>
> For that I need a simple in-app cache to keep track of all
> transactions run by the app itself, so to keep them apart from
> transactions run by external clients (as I need to invalidate the 2L
> cache items only for the latter).
>
> So the questions around support are not too much of a concern for my
> purpose. Using the modules coming with the server seemed so easy in
> comparison to putting the modules in place :) I'll try and have a look
> at how this could be done in my Dockerfile (this btw. could be an
> interesting example for you to have, too). Regarding CDI, I gave up on
> this and just obtained a cache via the API. Seemed simpler in the end.
>
> Thanks again,
>
> --Gunnar
>
>
> Am Mi., 5. Dez. 2018 um 13:02 Uhr schrieb Wolf Fink <wfink at redhat.com>:
> >
> > As Tristan said, the infinispan bits shipped with WildFly and its configuration will not have all ISPN features. It might change over the time as there is no test which ensure that any feature beside those which are used from the WF container.
> > The configuration for the subsystem is different and will not allow all features.
> > Also if there is a plan to move to the supported products this is not supported!
> >
> > The best option is to use the infinispan modules and configure it in server-mode, in this case the cache lifecycle is bound to the WF instance and can be shared/injected to all deployed applications (sharing the cache between application in embedded mode will not work)
> > Note that you might use the infinispan endpoints here, but if there is a plan to use the products the use of endpoints is not supported (as it will make WF a hybrid server for both)
> >
> > Wolf
> >
> > On Wed, Dec 5, 2018 at 12:17 PM Tristan Tarrant <ttarrant at redhat.com> wrote:
> >>
> >> On 12/5/18 9:44 AM, Gunnar Morling wrote:
> >> > Hey,
> >> >
> >> > I was trying to configure and inject an Infinispan cache through CDI,
> >> > running on WildFly 14, using the Infinispan modules provided by the
> >> > server.
> >> >
> >> > While I'm not sure whether that's something supported or recommended,
> >> > I found this preferable over adding Infinispan another time as part of
> >> > the deployment. I couldn't find any recent info on doing this (would
> >> > love any pointers, though), so here's my findings, in case it's
> >> > interesting for others:
> >>
> >> You should not be using the Infinispan subsystem that comes with WildFly
> >> as its configuration capabilities are a bit limited, but the modules we
> >> supply:
> >>
> >> http://infinispan.org/docs/stable/user_guide/user_guide.html#infinispan_modules_for_wildfly_eap
> >>
> >> > Btw. I also couldn't find an example for configuring a cache through
> >> > jboss-cli.sh, perhaps that's something to consider, too?
> >>
> >> Yes, that should be added.
> >>
> >> Tristan
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


From gunnar at hibernate.org  Wed Dec  5 11:01:14 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 5 Dec 2018 17:01:14 +0100
Subject: [infinispan-dev] Obtaining cache via CDI on WildFly
In-Reply-To: <CAFm4XO2mZ3ibFUK7-VNhPnoLLJ4X2eegYbP5iBadPyAPTYDZtQ@mail.gmail.com>
References: <CADGJaX-2dftdvmGMo8vsVHwQ40UGSpNj+P9do-ibT+vo3E_6Rg@mail.gmail.com>
	<c313c761-b72b-50a6-2390-904203f0a7cf@redhat.com>
	<CAKwmrdMcRVDYKWpQv__kpxn9WYZZmRT_aas=OYqL-ZMK4-H4+w@mail.gmail.com>
	<CADGJaX9qh61FL-uJBPa=tu_DDTkyXTmfLQRpRGk3O-8tscY4Jw@mail.gmail.com>
	<CAFm4XO2mZ3ibFUK7-VNhPnoLLJ4X2eegYbP5iBadPyAPTYDZtQ@mail.gmail.com>
Message-ID: <CADGJaX81M0JGVr2vXXmUq+HJQ7fcph_Fkv3-TZbuTX0wE+6j+A@mail.gmail.com>

> if all you want is to invalidate Hibernate ORM's 2LC caches, Hibernate
> exposes a specific API to do just that.

Yes, I am aware of this (using the JPA method for that in the blog post).

But I only want to invalidate the caches after external transactions,
i.e. not after transactions run by the app and Hibernate itself. Hence
I'm keeping a cache of transaction ids run by the application, so the
Debezium event handler can match incoming change events against them
and only call evict() after transactions _not_ executed by the
application. It's described in the blog post draft I linked, perhaps
you can take a look and let me know in case I'm missing anything?
Thanks!


Am Mi., 5. Dez. 2018 um 16:40 Uhr schrieb Sanne Grinovero
<sanne at infinispan.org>:
>
> Hi Gunnar,
>
> if all you want is to invalidate Hibernate ORM's 2LC caches, Hibernate
> exposes a specific API to do just that.
>
> Sanne
>
> On Wed, 5 Dec 2018 at 14:30, Gunnar Morling <gunnar at hibernate.org> wrote:
> >
> > Hey all,
> >
> > Thanks a lot for the quick replies!
> >
> > To give some background on what I was trying to do: my intention was
> > to use a simple cache within my app for a demo + blog post I'm
> > creating on invalidating the JPA 2nd-level cache after external data
> > changes (i.e. bypassing the app) via Debezium:
> >
> >     https://github.com/debezium/debezium-examples/tree/master/cache-invalidation
> >     https://github.com/debezium/debezium.github.io/pull/230
> >
> > For that I need a simple in-app cache to keep track of all
> > transactions run by the app itself, so to keep them apart from
> > transactions run by external clients (as I need to invalidate the 2L
> > cache items only for the latter).
> >
> > So the questions around support are not too much of a concern for my
> > purpose. Using the modules coming with the server seemed so easy in
> > comparison to putting the modules in place :) I'll try and have a look
> > at how this could be done in my Dockerfile (this btw. could be an
> > interesting example for you to have, too). Regarding CDI, I gave up on
> > this and just obtained a cache via the API. Seemed simpler in the end.
> >
> > Thanks again,
> >
> > --Gunnar
> >
> >
> > Am Mi., 5. Dez. 2018 um 13:02 Uhr schrieb Wolf Fink <wfink at redhat.com>:
> > >
> > > As Tristan said, the infinispan bits shipped with WildFly and its configuration will not have all ISPN features. It might change over the time as there is no test which ensure that any feature beside those which are used from the WF container.
> > > The configuration for the subsystem is different and will not allow all features.
> > > Also if there is a plan to move to the supported products this is not supported!
> > >
> > > The best option is to use the infinispan modules and configure it in server-mode, in this case the cache lifecycle is bound to the WF instance and can be shared/injected to all deployed applications (sharing the cache between application in embedded mode will not work)
> > > Note that you might use the infinispan endpoints here, but if there is a plan to use the products the use of endpoints is not supported (as it will make WF a hybrid server for both)
> > >
> > > Wolf
> > >
> > > On Wed, Dec 5, 2018 at 12:17 PM Tristan Tarrant <ttarrant at redhat.com> wrote:
> > >>
> > >> On 12/5/18 9:44 AM, Gunnar Morling wrote:
> > >> > Hey,
> > >> >
> > >> > I was trying to configure and inject an Infinispan cache through CDI,
> > >> > running on WildFly 14, using the Infinispan modules provided by the
> > >> > server.
> > >> >
> > >> > While I'm not sure whether that's something supported or recommended,
> > >> > I found this preferable over adding Infinispan another time as part of
> > >> > the deployment. I couldn't find any recent info on doing this (would
> > >> > love any pointers, though), so here's my findings, in case it's
> > >> > interesting for others:
> > >>
> > >> You should not be using the Infinispan subsystem that comes with WildFly
> > >> as its configuration capabilities are a bit limited, but the modules we
> > >> supply:
> > >>
> > >> http://infinispan.org/docs/stable/user_guide/user_guide.html#infinispan_modules_for_wildfly_eap
> > >>
> > >> > Btw. I also couldn't find an example for configuring a cache through
> > >> > jboss-cli.sh, perhaps that's something to consider, too?
> > >>
> > >> Yes, that should be added.
> > >>
> > >> Tristan
> > >> _______________________________________________
> > >> infinispan-dev mailing list
> > >> infinispan-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev


From gunnar at hibernate.org  Thu Dec  6 04:56:16 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 6 Dec 2018 10:56:16 +0100
Subject: [infinispan-dev] Obtaining cache via CDI on WildFly
In-Reply-To: <CADGJaX81M0JGVr2vXXmUq+HJQ7fcph_Fkv3-TZbuTX0wE+6j+A@mail.gmail.com>
References: <CADGJaX-2dftdvmGMo8vsVHwQ40UGSpNj+P9do-ibT+vo3E_6Rg@mail.gmail.com>
	<c313c761-b72b-50a6-2390-904203f0a7cf@redhat.com>
	<CAKwmrdMcRVDYKWpQv__kpxn9WYZZmRT_aas=OYqL-ZMK4-H4+w@mail.gmail.com>
	<CADGJaX9qh61FL-uJBPa=tu_DDTkyXTmfLQRpRGk3O-8tscY4Jw@mail.gmail.com>
	<CAFm4XO2mZ3ibFUK7-VNhPnoLLJ4X2eegYbP5iBadPyAPTYDZtQ@mail.gmail.com>
	<CADGJaX81M0JGVr2vXXmUq+HJQ7fcph_Fkv3-TZbuTX0wE+6j+A@mail.gmail.com>
Message-ID: <CADGJaX8+r6h=Th8=dxp-W7C6JjWDJ5FBaxwJB_G2QgGmiwLnCw@mail.gmail.com>

Hi,

So I'm using the module ZIP now and changed my app to depend on that
specific slot. Works nicely, thanks again.

One quick note on the module ZIP: this adds modules to the server's
original "system" directory, so this can be tough to be undone, if
needed (not so much an issue when thinking of containerized immutable
infra, but the more traditional server admin might be more concerned).
Have you considered to provide a file using the server's patching
mechanism instead? It's still a ZIP essentially, but contains some
additional metadata. By applying this via jboss-cli.sh's patch
command, this can cleanly be undone (the contents are put into a
separate "overlays" directory instead of "system" itself).

As an example, Hibernate Validator is providing a patch based on that approach:

    https://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#_updating_hibernate_validator_in_wildfly

We've also developed a Maven plug-in which helps to produce such patch
file. You can see it in use for HV here:

    https://github.com/hibernate/hibernate-validator/blob/master/modules/pom.xml

--Gunnar

Am Mi., 5. Dez. 2018 um 17:01 Uhr schrieb Gunnar Morling <gunnar at hibernate.org>:
>
> > if all you want is to invalidate Hibernate ORM's 2LC caches, Hibernate
> > exposes a specific API to do just that.
>
> Yes, I am aware of this (using the JPA method for that in the blog post).
>
> But I only want to invalidate the caches after external transactions,
> i.e. not after transactions run by the app and Hibernate itself. Hence
> I'm keeping a cache of transaction ids run by the application, so the
> Debezium event handler can match incoming change events against them
> and only call evict() after transactions _not_ executed by the
> application. It's described in the blog post draft I linked, perhaps
> you can take a look and let me know in case I'm missing anything?
> Thanks!
>
>
> Am Mi., 5. Dez. 2018 um 16:40 Uhr schrieb Sanne Grinovero
> <sanne at infinispan.org>:
> >
> > Hi Gunnar,
> >
> > if all you want is to invalidate Hibernate ORM's 2LC caches, Hibernate
> > exposes a specific API to do just that.
> >
> > Sanne
> >
> > On Wed, 5 Dec 2018 at 14:30, Gunnar Morling <gunnar at hibernate.org> wrote:
> > >
> > > Hey all,
> > >
> > > Thanks a lot for the quick replies!
> > >
> > > To give some background on what I was trying to do: my intention was
> > > to use a simple cache within my app for a demo + blog post I'm
> > > creating on invalidating the JPA 2nd-level cache after external data
> > > changes (i.e. bypassing the app) via Debezium:
> > >
> > >     https://github.com/debezium/debezium-examples/tree/master/cache-invalidation
> > >     https://github.com/debezium/debezium.github.io/pull/230
> > >
> > > For that I need a simple in-app cache to keep track of all
> > > transactions run by the app itself, so to keep them apart from
> > > transactions run by external clients (as I need to invalidate the 2L
> > > cache items only for the latter).
> > >
> > > So the questions around support are not too much of a concern for my
> > > purpose. Using the modules coming with the server seemed so easy in
> > > comparison to putting the modules in place :) I'll try and have a look
> > > at how this could be done in my Dockerfile (this btw. could be an
> > > interesting example for you to have, too). Regarding CDI, I gave up on
> > > this and just obtained a cache via the API. Seemed simpler in the end.
> > >
> > > Thanks again,
> > >
> > > --Gunnar
> > >
> > >
> > > Am Mi., 5. Dez. 2018 um 13:02 Uhr schrieb Wolf Fink <wfink at redhat.com>:
> > > >
> > > > As Tristan said, the infinispan bits shipped with WildFly and its configuration will not have all ISPN features. It might change over the time as there is no test which ensure that any feature beside those which are used from the WF container.
> > > > The configuration for the subsystem is different and will not allow all features.
> > > > Also if there is a plan to move to the supported products this is not supported!
> > > >
> > > > The best option is to use the infinispan modules and configure it in server-mode, in this case the cache lifecycle is bound to the WF instance and can be shared/injected to all deployed applications (sharing the cache between application in embedded mode will not work)
> > > > Note that you might use the infinispan endpoints here, but if there is a plan to use the products the use of endpoints is not supported (as it will make WF a hybrid server for both)
> > > >
> > > > Wolf
> > > >
> > > > On Wed, Dec 5, 2018 at 12:17 PM Tristan Tarrant <ttarrant at redhat.com> wrote:
> > > >>
> > > >> On 12/5/18 9:44 AM, Gunnar Morling wrote:
> > > >> > Hey,
> > > >> >
> > > >> > I was trying to configure and inject an Infinispan cache through CDI,
> > > >> > running on WildFly 14, using the Infinispan modules provided by the
> > > >> > server.
> > > >> >
> > > >> > While I'm not sure whether that's something supported or recommended,
> > > >> > I found this preferable over adding Infinispan another time as part of
> > > >> > the deployment. I couldn't find any recent info on doing this (would
> > > >> > love any pointers, though), so here's my findings, in case it's
> > > >> > interesting for others:
> > > >>
> > > >> You should not be using the Infinispan subsystem that comes with WildFly
> > > >> as its configuration capabilities are a bit limited, but the modules we
> > > >> supply:
> > > >>
> > > >> http://infinispan.org/docs/stable/user_guide/user_guide.html#infinispan_modules_for_wildfly_eap
> > > >>
> > > >> > Btw. I also couldn't find an example for configuring a cache through
> > > >> > jboss-cli.sh, perhaps that's something to consider, too?
> > > >>
> > > >> Yes, that should be added.
> > > >>
> > > >> Tristan
> > > >> _______________________________________________
> > > >> infinispan-dev mailing list
> > > >> infinispan-dev at lists.jboss.org
> > > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > >
> > > _______________________________________________
> > > infinispan-dev mailing list
> > > infinispan-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/infinispan-dev


From wfink at redhat.com  Thu Dec  6 05:05:01 2018
From: wfink at redhat.com (Wolf Fink)
Date: Thu, 6 Dec 2018 11:05:01 +0100
Subject: [infinispan-dev] Obtaining cache via CDI on WildFly
In-Reply-To: <CADGJaX8+r6h=Th8=dxp-W7C6JjWDJ5FBaxwJB_G2QgGmiwLnCw@mail.gmail.com>
References: <CADGJaX-2dftdvmGMo8vsVHwQ40UGSpNj+P9do-ibT+vo3E_6Rg@mail.gmail.com>
	<c313c761-b72b-50a6-2390-904203f0a7cf@redhat.com>
	<CAKwmrdMcRVDYKWpQv__kpxn9WYZZmRT_aas=OYqL-ZMK4-H4+w@mail.gmail.com>
	<CADGJaX9qh61FL-uJBPa=tu_DDTkyXTmfLQRpRGk3O-8tscY4Jw@mail.gmail.com>
	<CAFm4XO2mZ3ibFUK7-VNhPnoLLJ4X2eegYbP5iBadPyAPTYDZtQ@mail.gmail.com>
	<CADGJaX81M0JGVr2vXXmUq+HJQ7fcph_Fkv3-TZbuTX0wE+6j+A@mail.gmail.com>
	<CADGJaX8+r6h=Th8=dxp-W7C6JjWDJ5FBaxwJB_G2QgGmiwLnCw@mail.gmail.com>
Message-ID: <CAKwmrdNUEjS_PVs+fhBP0mqM4iRgpFZs4Dsr+y=0GACiU0uGAg@mail.gmail.com>

As the DG modules are for EAP6 and EAP7 there is no simple way to have one
zip for all releases. This means we have to multiply the zip if use that
approach and add more testing.

On Thu, Dec 6, 2018 at 10:56 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi,
>
> So I'm using the module ZIP now and changed my app to depend on that
> specific slot. Works nicely, thanks again.
>
> One quick note on the module ZIP: this adds modules to the server's
> original "system" directory, so this can be tough to be undone, if
> needed (not so much an issue when thinking of containerized immutable
> infra, but the more traditional server admin might be more concerned).
> Have you considered to provide a file using the server's patching
> mechanism instead? It's still a ZIP essentially, but contains some
> additional metadata. By applying this via jboss-cli.sh's patch
> command, this can cleanly be undone (the contents are put into a
> separate "overlays" directory instead of "system" itself).
>
> As an example, Hibernate Validator is providing a patch based on that
> approach:
>
>
> https://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#_updating_hibernate_validator_in_wildfly
>
> We've also developed a Maven plug-in which helps to produce such patch
> file. You can see it in use for HV here:
>
>
> https://github.com/hibernate/hibernate-validator/blob/master/modules/pom.xml
>
> --Gunnar
>
> Am Mi., 5. Dez. 2018 um 17:01 Uhr schrieb Gunnar Morling <
> gunnar at hibernate.org>:
> >
> > > if all you want is to invalidate Hibernate ORM's 2LC caches, Hibernate
> > > exposes a specific API to do just that.
> >
> > Yes, I am aware of this (using the JPA method for that in the blog post).
> >
> > But I only want to invalidate the caches after external transactions,
> > i.e. not after transactions run by the app and Hibernate itself. Hence
> > I'm keeping a cache of transaction ids run by the application, so the
> > Debezium event handler can match incoming change events against them
> > and only call evict() after transactions _not_ executed by the
> > application. It's described in the blog post draft I linked, perhaps
> > you can take a look and let me know in case I'm missing anything?
> > Thanks!
> >
> >
> > Am Mi., 5. Dez. 2018 um 16:40 Uhr schrieb Sanne Grinovero
> > <sanne at infinispan.org>:
> > >
> > > Hi Gunnar,
> > >
> > > if all you want is to invalidate Hibernate ORM's 2LC caches, Hibernate
> > > exposes a specific API to do just that.
> > >
> > > Sanne
> > >
> > > On Wed, 5 Dec 2018 at 14:30, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> > > >
> > > > Hey all,
> > > >
> > > > Thanks a lot for the quick replies!
> > > >
> > > > To give some background on what I was trying to do: my intention was
> > > > to use a simple cache within my app for a demo + blog post I'm
> > > > creating on invalidating the JPA 2nd-level cache after external data
> > > > changes (i.e. bypassing the app) via Debezium:
> > > >
> > > >
> https://github.com/debezium/debezium-examples/tree/master/cache-invalidation
> > > >     https://github.com/debezium/debezium.github.io/pull/230
> > > >
> > > > For that I need a simple in-app cache to keep track of all
> > > > transactions run by the app itself, so to keep them apart from
> > > > transactions run by external clients (as I need to invalidate the 2L
> > > > cache items only for the latter).
> > > >
> > > > So the questions around support are not too much of a concern for my
> > > > purpose. Using the modules coming with the server seemed so easy in
> > > > comparison to putting the modules in place :) I'll try and have a
> look
> > > > at how this could be done in my Dockerfile (this btw. could be an
> > > > interesting example for you to have, too). Regarding CDI, I gave up
> on
> > > > this and just obtained a cache via the API. Seemed simpler in the
> end.
> > > >
> > > > Thanks again,
> > > >
> > > > --Gunnar
> > > >
> > > >
> > > > Am Mi., 5. Dez. 2018 um 13:02 Uhr schrieb Wolf Fink <
> wfink at redhat.com>:
> > > > >
> > > > > As Tristan said, the infinispan bits shipped with WildFly and its
> configuration will not have all ISPN features. It might change over the
> time as there is no test which ensure that any feature beside those which
> are used from the WF container.
> > > > > The configuration for the subsystem is different and will not
> allow all features.
> > > > > Also if there is a plan to move to the supported products this is
> not supported!
> > > > >
> > > > > The best option is to use the infinispan modules and configure it
> in server-mode, in this case the cache lifecycle is bound to the WF
> instance and can be shared/injected to all deployed applications (sharing
> the cache between application in embedded mode will not work)
> > > > > Note that you might use the infinispan endpoints here, but if
> there is a plan to use the products the use of endpoints is not supported
> (as it will make WF a hybrid server for both)
> > > > >
> > > > > Wolf
> > > > >
> > > > > On Wed, Dec 5, 2018 at 12:17 PM Tristan Tarrant <
> ttarrant at redhat.com> wrote:
> > > > >>
> > > > >> On 12/5/18 9:44 AM, Gunnar Morling wrote:
> > > > >> > Hey,
> > > > >> >
> > > > >> > I was trying to configure and inject an Infinispan cache
> through CDI,
> > > > >> > running on WildFly 14, using the Infinispan modules provided by
> the
> > > > >> > server.
> > > > >> >
> > > > >> > While I'm not sure whether that's something supported or
> recommended,
> > > > >> > I found this preferable over adding Infinispan another time as
> part of
> > > > >> > the deployment. I couldn't find any recent info on doing this
> (would
> > > > >> > love any pointers, though), so here's my findings, in case it's
> > > > >> > interesting for others:
> > > > >>
> > > > >> You should not be using the Infinispan subsystem that comes with
> WildFly
> > > > >> as its configuration capabilities are a bit limited, but the
> modules we
> > > > >> supply:
> > > > >>
> > > > >>
> http://infinispan.org/docs/stable/user_guide/user_guide.html#infinispan_modules_for_wildfly_eap
> > > > >>
> > > > >> > Btw. I also couldn't find an example for configuring a cache
> through
> > > > >> > jboss-cli.sh, perhaps that's something to consider, too?
> > > > >>
> > > > >> Yes, that should be added.
> > > > >>
> > > > >> Tristan
> > > > >> _______________________________________________
> > > > >> infinispan-dev mailing list
> > > > >> infinispan-dev at lists.jboss.org
> > > > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > > >
> > > > _______________________________________________
> > > > infinispan-dev mailing list
> > > > infinispan-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20181206/f52df946/attachment.html 

From gunnar at hibernate.org  Thu Dec  6 06:58:09 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 6 Dec 2018 12:58:09 +0100
Subject: [infinispan-dev] Obtaining cache via CDI on WildFly
In-Reply-To: <CAKwmrdNUEjS_PVs+fhBP0mqM4iRgpFZs4Dsr+y=0GACiU0uGAg@mail.gmail.com>
References: <CADGJaX-2dftdvmGMo8vsVHwQ40UGSpNj+P9do-ibT+vo3E_6Rg@mail.gmail.com>
	<c313c761-b72b-50a6-2390-904203f0a7cf@redhat.com>
	<CAKwmrdMcRVDYKWpQv__kpxn9WYZZmRT_aas=OYqL-ZMK4-H4+w@mail.gmail.com>
	<CADGJaX9qh61FL-uJBPa=tu_DDTkyXTmfLQRpRGk3O-8tscY4Jw@mail.gmail.com>
	<CAFm4XO2mZ3ibFUK7-VNhPnoLLJ4X2eegYbP5iBadPyAPTYDZtQ@mail.gmail.com>
	<CADGJaX81M0JGVr2vXXmUq+HJQ7fcph_Fkv3-TZbuTX0wE+6j+A@mail.gmail.com>
	<CADGJaX8+r6h=Th8=dxp-W7C6JjWDJ5FBaxwJB_G2QgGmiwLnCw@mail.gmail.com>
	<CAKwmrdNUEjS_PVs+fhBP0mqM4iRgpFZs4Dsr+y=0GACiU0uGAg@mail.gmail.com>
Message-ID: <CADGJaX_xS3XSocRdYy7jkXs-bCO5AUQPNJ8cYvNqTmtsYF2oqw@mail.gmail.com>

Yes, that's a good point. That's why we add the targeted WF version to
the id of the HV patch files (in general we try to only have one for
the latest WF at that point in time). A plain ZIP is more forgiving in
that regard, although I'd argue it should be tested and documented
which server versions are supported by a given ZIP (e.g. this wasn't
quite clear to me from the Infinispan docs).
Am Do., 6. Dez. 2018 um 11:05 Uhr schrieb Wolf Fink <wfink at redhat.com>:
>
> As the DG modules are for EAP6 and EAP7 there is no simple way to have one zip for all releases. This means we have to multiply the zip if use that approach and add more testing.
>
> On Thu, Dec 6, 2018 at 10:56 AM Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>> Hi,
>>
>> So I'm using the module ZIP now and changed my app to depend on that
>> specific slot. Works nicely, thanks again.
>>
>> One quick note on the module ZIP: this adds modules to the server's
>> original "system" directory, so this can be tough to be undone, if
>> needed (not so much an issue when thinking of containerized immutable
>> infra, but the more traditional server admin might be more concerned).
>> Have you considered to provide a file using the server's patching
>> mechanism instead? It's still a ZIP essentially, but contains some
>> additional metadata. By applying this via jboss-cli.sh's patch
>> command, this can cleanly be undone (the contents are put into a
>> separate "overlays" directory instead of "system" itself).
>>
>> As an example, Hibernate Validator is providing a patch based on that approach:
>>
>>     https://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#_updating_hibernate_validator_in_wildfly
>>
>> We've also developed a Maven plug-in which helps to produce such patch
>> file. You can see it in use for HV here:
>>
>>     https://github.com/hibernate/hibernate-validator/blob/master/modules/pom.xml
>>
>> --Gunnar
>>
>> Am Mi., 5. Dez. 2018 um 17:01 Uhr schrieb Gunnar Morling <gunnar at hibernate.org>:
>> >
>> > > if all you want is to invalidate Hibernate ORM's 2LC caches, Hibernate
>> > > exposes a specific API to do just that.
>> >
>> > Yes, I am aware of this (using the JPA method for that in the blog post).
>> >
>> > But I only want to invalidate the caches after external transactions,
>> > i.e. not after transactions run by the app and Hibernate itself. Hence
>> > I'm keeping a cache of transaction ids run by the application, so the
>> > Debezium event handler can match incoming change events against them
>> > and only call evict() after transactions _not_ executed by the
>> > application. It's described in the blog post draft I linked, perhaps
>> > you can take a look and let me know in case I'm missing anything?
>> > Thanks!
>> >
>> >
>> > Am Mi., 5. Dez. 2018 um 16:40 Uhr schrieb Sanne Grinovero
>> > <sanne at infinispan.org>:
>> > >
>> > > Hi Gunnar,
>> > >
>> > > if all you want is to invalidate Hibernate ORM's 2LC caches, Hibernate
>> > > exposes a specific API to do just that.
>> > >
>> > > Sanne
>> > >
>> > > On Wed, 5 Dec 2018 at 14:30, Gunnar Morling <gunnar at hibernate.org> wrote:
>> > > >
>> > > > Hey all,
>> > > >
>> > > > Thanks a lot for the quick replies!
>> > > >
>> > > > To give some background on what I was trying to do: my intention was
>> > > > to use a simple cache within my app for a demo + blog post I'm
>> > > > creating on invalidating the JPA 2nd-level cache after external data
>> > > > changes (i.e. bypassing the app) via Debezium:
>> > > >
>> > > >     https://github.com/debezium/debezium-examples/tree/master/cache-invalidation
>> > > >     https://github.com/debezium/debezium.github.io/pull/230
>> > > >
>> > > > For that I need a simple in-app cache to keep track of all
>> > > > transactions run by the app itself, so to keep them apart from
>> > > > transactions run by external clients (as I need to invalidate the 2L
>> > > > cache items only for the latter).
>> > > >
>> > > > So the questions around support are not too much of a concern for my
>> > > > purpose. Using the modules coming with the server seemed so easy in
>> > > > comparison to putting the modules in place :) I'll try and have a look
>> > > > at how this could be done in my Dockerfile (this btw. could be an
>> > > > interesting example for you to have, too). Regarding CDI, I gave up on
>> > > > this and just obtained a cache via the API. Seemed simpler in the end.
>> > > >
>> > > > Thanks again,
>> > > >
>> > > > --Gunnar
>> > > >
>> > > >
>> > > > Am Mi., 5. Dez. 2018 um 13:02 Uhr schrieb Wolf Fink <wfink at redhat.com>:
>> > > > >
>> > > > > As Tristan said, the infinispan bits shipped with WildFly and its configuration will not have all ISPN features. It might change over the time as there is no test which ensure that any feature beside those which are used from the WF container.
>> > > > > The configuration for the subsystem is different and will not allow all features.
>> > > > > Also if there is a plan to move to the supported products this is not supported!
>> > > > >
>> > > > > The best option is to use the infinispan modules and configure it in server-mode, in this case the cache lifecycle is bound to the WF instance and can be shared/injected to all deployed applications (sharing the cache between application in embedded mode will not work)
>> > > > > Note that you might use the infinispan endpoints here, but if there is a plan to use the products the use of endpoints is not supported (as it will make WF a hybrid server for both)
>> > > > >
>> > > > > Wolf
>> > > > >
>> > > > > On Wed, Dec 5, 2018 at 12:17 PM Tristan Tarrant <ttarrant at redhat.com> wrote:
>> > > > >>
>> > > > >> On 12/5/18 9:44 AM, Gunnar Morling wrote:
>> > > > >> > Hey,
>> > > > >> >
>> > > > >> > I was trying to configure and inject an Infinispan cache through CDI,
>> > > > >> > running on WildFly 14, using the Infinispan modules provided by the
>> > > > >> > server.
>> > > > >> >
>> > > > >> > While I'm not sure whether that's something supported or recommended,
>> > > > >> > I found this preferable over adding Infinispan another time as part of
>> > > > >> > the deployment. I couldn't find any recent info on doing this (would
>> > > > >> > love any pointers, though), so here's my findings, in case it's
>> > > > >> > interesting for others:
>> > > > >>
>> > > > >> You should not be using the Infinispan subsystem that comes with WildFly
>> > > > >> as its configuration capabilities are a bit limited, but the modules we
>> > > > >> supply:
>> > > > >>
>> > > > >> http://infinispan.org/docs/stable/user_guide/user_guide.html#infinispan_modules_for_wildfly_eap
>> > > > >>
>> > > > >> > Btw. I also couldn't find an example for configuring a cache through
>> > > > >> > jboss-cli.sh, perhaps that's something to consider, too?
>> > > > >>
>> > > > >> Yes, that should be added.
>> > > > >>
>> > > > >> Tristan
>> > > > >> _______________________________________________
>> > > > >> infinispan-dev mailing list
>> > > > >> infinispan-dev at lists.jboss.org
>> > > > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> > > >
>> > > > _______________________________________________
>> > > > infinispan-dev mailing list
>> > > > infinispan-dev at lists.jboss.org
>> > > > https://lists.jboss.org/mailman/listinfo/infinispan-dev


From wfink at redhat.com  Thu Dec  6 07:45:43 2018
From: wfink at redhat.com (Wolf Fink)
Date: Thu, 6 Dec 2018 13:45:43 +0100
Subject: [infinispan-dev] Obtaining cache via CDI on WildFly
In-Reply-To: <CADGJaX_xS3XSocRdYy7jkXs-bCO5AUQPNJ8cYvNqTmtsYF2oqw@mail.gmail.com>
References: <CADGJaX-2dftdvmGMo8vsVHwQ40UGSpNj+P9do-ibT+vo3E_6Rg@mail.gmail.com>
	<c313c761-b72b-50a6-2390-904203f0a7cf@redhat.com>
	<CAKwmrdMcRVDYKWpQv__kpxn9WYZZmRT_aas=OYqL-ZMK4-H4+w@mail.gmail.com>
	<CADGJaX9qh61FL-uJBPa=tu_DDTkyXTmfLQRpRGk3O-8tscY4Jw@mail.gmail.com>
	<CAFm4XO2mZ3ibFUK7-VNhPnoLLJ4X2eegYbP5iBadPyAPTYDZtQ@mail.gmail.com>
	<CADGJaX81M0JGVr2vXXmUq+HJQ7fcph_Fkv3-TZbuTX0wE+6j+A@mail.gmail.com>
	<CADGJaX8+r6h=Th8=dxp-W7C6JjWDJ5FBaxwJB_G2QgGmiwLnCw@mail.gmail.com>
	<CAKwmrdNUEjS_PVs+fhBP0mqM4iRgpFZs4Dsr+y=0GACiU0uGAg@mail.gmail.com>
	<CADGJaX_xS3XSocRdYy7jkXs-bCO5AUQPNJ8cYvNqTmtsYF2oqw@mail.gmail.com>
Message-ID: <CAKwmrdOhVN+t+WZ69B5LNiFBbZF2S2ewKBuEQNvo3GTb2Jr7cg@mail.gmail.com>

As far as I know the latest 6.4 and 7.x

On Thu, Dec 6, 2018 at 12:58 PM Gunnar Morling <gunnar at hibernate.org> wrote:

> Yes, that's a good point. That's why we add the targeted WF version to
> the id of the HV patch files (in general we try to only have one for
> the latest WF at that point in time). A plain ZIP is more forgiving in
> that regard, although I'd argue it should be tested and documented
> which server versions are supported by a given ZIP (e.g. this wasn't
> quite clear to me from the Infinispan docs).
> Am Do., 6. Dez. 2018 um 11:05 Uhr schrieb Wolf Fink <wfink at redhat.com>:
> >
> > As the DG modules are for EAP6 and EAP7 there is no simple way to have
> one zip for all releases. This means we have to multiply the zip if use
> that approach and add more testing.
> >
> > On Thu, Dec 6, 2018 at 10:56 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >>
> >> Hi,
> >>
> >> So I'm using the module ZIP now and changed my app to depend on that
> >> specific slot. Works nicely, thanks again.
> >>
> >> One quick note on the module ZIP: this adds modules to the server's
> >> original "system" directory, so this can be tough to be undone, if
> >> needed (not so much an issue when thinking of containerized immutable
> >> infra, but the more traditional server admin might be more concerned).
> >> Have you considered to provide a file using the server's patching
> >> mechanism instead? It's still a ZIP essentially, but contains some
> >> additional metadata. By applying this via jboss-cli.sh's patch
> >> command, this can cleanly be undone (the contents are put into a
> >> separate "overlays" directory instead of "system" itself).
> >>
> >> As an example, Hibernate Validator is providing a patch based on that
> approach:
> >>
> >>
> https://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#_updating_hibernate_validator_in_wildfly
> >>
> >> We've also developed a Maven plug-in which helps to produce such patch
> >> file. You can see it in use for HV here:
> >>
> >>
> https://github.com/hibernate/hibernate-validator/blob/master/modules/pom.xml
> >>
> >> --Gunnar
> >>
> >> Am Mi., 5. Dez. 2018 um 17:01 Uhr schrieb Gunnar Morling <
> gunnar at hibernate.org>:
> >> >
> >> > > if all you want is to invalidate Hibernate ORM's 2LC caches,
> Hibernate
> >> > > exposes a specific API to do just that.
> >> >
> >> > Yes, I am aware of this (using the JPA method for that in the blog
> post).
> >> >
> >> > But I only want to invalidate the caches after external transactions,
> >> > i.e. not after transactions run by the app and Hibernate itself. Hence
> >> > I'm keeping a cache of transaction ids run by the application, so the
> >> > Debezium event handler can match incoming change events against them
> >> > and only call evict() after transactions _not_ executed by the
> >> > application. It's described in the blog post draft I linked, perhaps
> >> > you can take a look and let me know in case I'm missing anything?
> >> > Thanks!
> >> >
> >> >
> >> > Am Mi., 5. Dez. 2018 um 16:40 Uhr schrieb Sanne Grinovero
> >> > <sanne at infinispan.org>:
> >> > >
> >> > > Hi Gunnar,
> >> > >
> >> > > if all you want is to invalidate Hibernate ORM's 2LC caches,
> Hibernate
> >> > > exposes a specific API to do just that.
> >> > >
> >> > > Sanne
> >> > >
> >> > > On Wed, 5 Dec 2018 at 14:30, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >> > > >
> >> > > > Hey all,
> >> > > >
> >> > > > Thanks a lot for the quick replies!
> >> > > >
> >> > > > To give some background on what I was trying to do: my intention
> was
> >> > > > to use a simple cache within my app for a demo + blog post I'm
> >> > > > creating on invalidating the JPA 2nd-level cache after external
> data
> >> > > > changes (i.e. bypassing the app) via Debezium:
> >> > > >
> >> > > >
> https://github.com/debezium/debezium-examples/tree/master/cache-invalidation
> >> > > >     https://github.com/debezium/debezium.github.io/pull/230
> >> > > >
> >> > > > For that I need a simple in-app cache to keep track of all
> >> > > > transactions run by the app itself, so to keep them apart from
> >> > > > transactions run by external clients (as I need to invalidate the
> 2L
> >> > > > cache items only for the latter).
> >> > > >
> >> > > > So the questions around support are not too much of a concern for
> my
> >> > > > purpose. Using the modules coming with the server seemed so easy
> in
> >> > > > comparison to putting the modules in place :) I'll try and have a
> look
> >> > > > at how this could be done in my Dockerfile (this btw. could be an
> >> > > > interesting example for you to have, too). Regarding CDI, I gave
> up on
> >> > > > this and just obtained a cache via the API. Seemed simpler in the
> end.
> >> > > >
> >> > > > Thanks again,
> >> > > >
> >> > > > --Gunnar
> >> > > >
> >> > > >
> >> > > > Am Mi., 5. Dez. 2018 um 13:02 Uhr schrieb Wolf Fink <
> wfink at redhat.com>:
> >> > > > >
> >> > > > > As Tristan said, the infinispan bits shipped with WildFly and
> its configuration will not have all ISPN features. It might change over the
> time as there is no test which ensure that any feature beside those which
> are used from the WF container.
> >> > > > > The configuration for the subsystem is different and will not
> allow all features.
> >> > > > > Also if there is a plan to move to the supported products this
> is not supported!
> >> > > > >
> >> > > > > The best option is to use the infinispan modules and configure
> it in server-mode, in this case the cache lifecycle is bound to the WF
> instance and can be shared/injected to all deployed applications (sharing
> the cache between application in embedded mode will not work)
> >> > > > > Note that you might use the infinispan endpoints here, but if
> there is a plan to use the products the use of endpoints is not supported
> (as it will make WF a hybrid server for both)
> >> > > > >
> >> > > > > Wolf
> >> > > > >
> >> > > > > On Wed, Dec 5, 2018 at 12:17 PM Tristan Tarrant <
> ttarrant at redhat.com> wrote:
> >> > > > >>
> >> > > > >> On 12/5/18 9:44 AM, Gunnar Morling wrote:
> >> > > > >> > Hey,
> >> > > > >> >
> >> > > > >> > I was trying to configure and inject an Infinispan cache
> through CDI,
> >> > > > >> > running on WildFly 14, using the Infinispan modules provided
> by the
> >> > > > >> > server.
> >> > > > >> >
> >> > > > >> > While I'm not sure whether that's something supported or
> recommended,
> >> > > > >> > I found this preferable over adding Infinispan another time
> as part of
> >> > > > >> > the deployment. I couldn't find any recent info on doing
> this (would
> >> > > > >> > love any pointers, though), so here's my findings, in case
> it's
> >> > > > >> > interesting for others:
> >> > > > >>
> >> > > > >> You should not be using the Infinispan subsystem that comes
> with WildFly
> >> > > > >> as its configuration capabilities are a bit limited, but the
> modules we
> >> > > > >> supply:
> >> > > > >>
> >> > > > >>
> http://infinispan.org/docs/stable/user_guide/user_guide.html#infinispan_modules_for_wildfly_eap
> >> > > > >>
> >> > > > >> > Btw. I also couldn't find an example for configuring a cache
> through
> >> > > > >> > jboss-cli.sh, perhaps that's something to consider, too?
> >> > > > >>
> >> > > > >> Yes, that should be added.
> >> > > > >>
> >> > > > >> Tristan
> >> > > > >> _______________________________________________
> >> > > > >> infinispan-dev mailing list
> >> > > > >> infinispan-dev at lists.jboss.org
> >> > > > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >> > > >
> >> > > > _______________________________________________
> >> > > > infinispan-dev mailing list
> >> > > > infinispan-dev at lists.jboss.org
> >> > > > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20181206/5a72ff72/attachment.html 

From slaskawi at redhat.com  Mon Dec 10 09:27:19 2018
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Mon, 10 Dec 2018 15:27:19 +0100
Subject: [infinispan-dev] Single Port Client
Message-ID: <CAA9R9O7-Jcw7ss9F7Pz-QHFf2wOjQm+k1FqYmk0-QtpHWwJyVQ@mail.gmail.com>

Hey guys,

During Infinispan F2F, I had a short discussion with Tristan on Single Port
client-side implementation. Back then, we agreed that the client should
always send a Hotrod Ping request and if won't get any response (or get
some HTTP content back), it will try to upgrade to the Hotrod protocol
using Single Port.

I've been playing with the implementation for a while, and implementing it
this way seems a bit "inconvenient" to me. The Ping Operation uses 60s
timeout, which seems to be a good fit as a default. Unfortunately, for the
Single Port functionality, this means we'd need to wait 60s until we try to
send HTTP request and do an upgrade. Also, another problematic part is in
Netty's HTTP handlers (HttpObjectDecoder, HttpServerCodec and
ByteToMessageDecoder). When those classes fail to decode a message (REST
expects HTTP rather than a stream of bytes specific to Hotrod protocol),
they just ignore it and keep the channel in active state (which also makes
sense for HTTP/1.1 and HTTP/2).

At this point, my intuition tells, that this doesn't look right and seems
to be a over-complicated. The whole HTTP upgrade idea seems to work the
other way around, use HTTP as a fallback and then upgrade to other
protocols. Forcing it to work a bit differently requires some more effort.

What if we preserved the Single Port setting in the client configuration
but implemented it as an enum with the following values - true/false/auto.
In automatic mode, the client would check if the server port is set to
8\d{1,3} (this covers 80, 8080, 8081, 8443 and friends). If that is true,
we'd try to follow HTTP Upgrade procedure. This looks very simple and I
think this might actually work. Please note, that we need the single port
setting in the client configuration to cover some corner cases like the
Single Port exposed on different port (like 4444) or Hot Rod exposed on
port that starts with 8.

What do you think about such simplification?

Thanks,
Sebastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20181210/b3cd1707/attachment.html 

From slaskawi at redhat.com  Tue Dec 11 04:52:18 2018
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Tue, 11 Dec 2018 10:52:18 +0100
Subject: [infinispan-dev] Single Port Client
In-Reply-To: <CAA9R9O7-Jcw7ss9F7Pz-QHFf2wOjQm+k1FqYmk0-QtpHWwJyVQ@mail.gmail.com>
References: <CAA9R9O7-Jcw7ss9F7Pz-QHFf2wOjQm+k1FqYmk0-QtpHWwJyVQ@mail.gmail.com>
Message-ID: <CAA9R9O5s=MbBrSNwrEeZnyignY-xCnFmdmmHsAPGtX=kU18trg@mail.gmail.com>

An updated PR might be found here:
https://github.com/infinispan/infinispan/pull/6133

On Mon, Dec 10, 2018 at 3:27 PM Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

> Hey guys,
>
> During Infinispan F2F, I had a short discussion with Tristan on Single
> Port client-side implementation. Back then, we agreed that the client
> should always send a Hotrod Ping request and if won't get any response (or
> get some HTTP content back), it will try to upgrade to the Hotrod protocol
> using Single Port.
>
> I've been playing with the implementation for a while, and implementing it
> this way seems a bit "inconvenient" to me. The Ping Operation uses 60s
> timeout, which seems to be a good fit as a default. Unfortunately, for the
> Single Port functionality, this means we'd need to wait 60s until we try to
> send HTTP request and do an upgrade. Also, another problematic part is in
> Netty's HTTP handlers (HttpObjectDecoder, HttpServerCodec and
> ByteToMessageDecoder). When those classes fail to decode a message (REST
> expects HTTP rather than a stream of bytes specific to Hotrod protocol),
> they just ignore it and keep the channel in active state (which also makes
> sense for HTTP/1.1 and HTTP/2).
>
> At this point, my intuition tells, that this doesn't look right and seems
> to be a over-complicated. The whole HTTP upgrade idea seems to work the
> other way around, use HTTP as a fallback and then upgrade to other
> protocols. Forcing it to work a bit differently requires some more effort.
>
> What if we preserved the Single Port setting in the client configuration
> but implemented it as an enum with the following values - true/false/auto.
> In automatic mode, the client would check if the server port is set to
> 8\d{1,3} (this covers 80, 8080, 8081, 8443 and friends). If that is true,
> we'd try to follow HTTP Upgrade procedure. This looks very simple and I
> think this might actually work. Please note, that we need the single port
> setting in the client configuration to cover some corner cases like the
> Single Port exposed on different port (like 4444) or Hot Rod exposed on
> port that starts with 8.
>
> What do you think about such simplification?
>
> Thanks,
> Sebastian
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20181211/1c71b2d9/attachment-0001.html 

From rvansa at redhat.com  Tue Dec 11 05:13:06 2018
From: rvansa at redhat.com (Radim Vansa)
Date: Tue, 11 Dec 2018 11:13:06 +0100
Subject: [infinispan-dev] Single Port Client
In-Reply-To: <CAA9R9O7-Jcw7ss9F7Pz-QHFf2wOjQm+k1FqYmk0-QtpHWwJyVQ@mail.gmail.com>
References: <CAA9R9O7-Jcw7ss9F7Pz-QHFf2wOjQm+k1FqYmk0-QtpHWwJyVQ@mail.gmail.com>
Message-ID: <58fd205f-1b17-1cb6-aa7b-af1886de93ca@redhat.com>

I dislike having any logic based on the port number in some range; it's 
not common that behaviour would change if you set port to 9xxx instead 
of 8xxx.

Is there an (up-to-date) design doc?

I don't fully follow, but if there's a problem in the HTTP handlers you 
can add a PING-detecting handler below...?

Radim

On 12/10/2018 03:27 PM, Sebastian Laskawiec wrote:
> Hey guys,
>
> During Infinispan F2F, I had a short discussion with Tristan on Single 
> Port client-side implementation. Back then, we agreed that the client 
> should always send a Hotrod Ping request and if won't get any response 
> (or get some HTTP content back), it will try to upgrade to the Hotrod 
> protocol using Single Port.
>
> I've been playing with the implementation for a while, and 
> implementing it this way seems a bit "inconvenient" to me. The Ping 
> Operation uses 60s timeout, which seems to be a good fit as a default. 
> Unfortunately, for the Single Port functionality, this means we'd need 
> to wait 60s until we try to send HTTP request and do an upgrade. Also, 
> another problematic part is in Netty's HTTP handlers 
> (HttpObjectDecoder, HttpServerCodec and ByteToMessageDecoder). When 
> those classes fail to decode a message (REST expects HTTP rather than 
> a stream of bytes specific to Hotrod protocol), they just ignore it 
> and keep the channel in active state (which also makes sense for 
> HTTP/1.1 and HTTP/2).
>
> At this point, my intuition tells, that this doesn't look right and 
> seems to be a over-complicated. The whole HTTP upgrade idea seems to 
> work the other way around, use HTTP as a fallback and then upgrade to 
> other protocols. Forcing it to work a bit differently requires some 
> more effort.
>
> What if we preserved the Single Port setting in the client 
> configuration but implemented it as an enum with the following values 
> - true/false/auto. In automatic mode, the client would check if the 
> server port is set to 8\d{1,3}?(this covers 80, 8080, 8081, 8443 and 
> friends). If that is true, we'd try to follow HTTP Upgrade procedure. 
> This looks very simple and I think this might actually work. Please 
> note, that we need the single port setting in the client configuration 
> to cover some corner cases like the Single Port exposed on different 
> port (like 4444) or Hot Rod exposed on port that starts with 8.
>
> What do you think about such simplification?
>
> Thanks,
> Sebastian
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From karesti at redhat.com  Tue Dec 11 07:46:48 2018
From: karesti at redhat.com (Katia Aresti)
Date: Tue, 11 Dec 2018 13:46:48 +0100
Subject: [infinispan-dev] Infinispan-Spring-Boot 2.1.1.Final and 1.0.4.Final
In-Reply-To: <CAKypdv=VQHefvMFGLBjmifhjZxXU=08Yb-3MdVUGRjMm1pmRGQ@mail.gmail.com>
References: <CAH8Ud1GaoP_AhKc2SMqFXBitT3pgavzhBQoux6Zqt=tJ=eogZA@mail.gmail.com>
	<CAKypdv=VQHefvMFGLBjmifhjZxXU=08Yb-3MdVUGRjMm1pmRGQ@mail.gmail.com>
Message-ID: <CAKypdvn-jEb+o2X5uk06Gvqqu6sss1AzzLXNyZkK8YskpK9GJQ@mail.gmail.com>

HI all

Infinispan Spring Boot starters are released

https://blog.infinispan.org/2018/12/infinispan-spring-boot-211final-and.html

Cheers

Katia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20181211/5698ae75/attachment.html 

From slaskawi at redhat.com  Wed Dec 12 09:30:53 2018
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Wed, 12 Dec 2018 15:30:53 +0100
Subject: [infinispan-dev] Single Port Client
In-Reply-To: <58fd205f-1b17-1cb6-aa7b-af1886de93ca@redhat.com>
References: <CAA9R9O7-Jcw7ss9F7Pz-QHFf2wOjQm+k1FqYmk0-QtpHWwJyVQ@mail.gmail.com>
	<58fd205f-1b17-1cb6-aa7b-af1886de93ca@redhat.com>
Message-ID: <CAA9R9O6PQ0knCRfHvJ4+eoWaUNJ6mZseuMLkm6J8Qj9n2=wuVA@mail.gmail.com>

On Tue, Dec 11, 2018 at 11:13 AM Radim Vansa <rvansa at redhat.com> wrote:

> I dislike having any logic based on the port number in some range; it's
> not common that behaviour would change if you set port to 9xxx instead
> of 8xxx.
>

That's not a problem with my approach, since you can always manually turn
the setting off or on. Here's how you do it:
ConfigurationBuilder cb = ...
cb.singlePort(SinglePortMode.ENABLED); // other options: DISABLED and AUTO


> Is there an (up-to-date) design doc?
>

No, this is just a proposal. I was hoping that you guys like it and then,
with some thumbs up, I could update the design doc.

Here's the most up-to-date version in case you were looking for it:
https://github.com/infinispan/infinispan-designs/blob/master/Single_port.adoc


>
> I don't fully follow, but if there's a problem in the HTTP handlers you
> can add a PING-detecting handler below...?
>

Thanks for the hint Radim!

Inspired by your idea I went ahead and checked how OpenShift Router
behaves. It turns out that it responds HTTP 400 if you throw Hotrod bytes
at it and then drops the connection. I also realized, there's one more
moving bit - TCP Keepalive. Luckily, we can control this setting over
configuration in our standalone.xml. However, it is perfectly legal what
I've seen in Netty (do not respond and keep the connection alive assuming
that TCP Keepalive is set to true).

The more I think about this, the more I'm convinced that the Single Port
support should be explicitly set in the client (or inferred from the
configuration). I do not know how Nginx, Linkerd or Envoy behaves in
situation when they expect HTTP and get a stream of bytes. Relying on this
partially unknown behavior for doing our upgrade procedure doesn't seem
right to me.

Just in case you're worried about the additional logic on the client side -
it's super small. Really, only 13 lines including brackets ;)
https://github.com/infinispan/infinispan/pull/6133/files#diff-684a10c939f31fcfef0f5f48d469393aR618


>
> Radim
>
> On 12/10/2018 03:27 PM, Sebastian Laskawiec wrote:
> > Hey guys,
> >
> > During Infinispan F2F, I had a short discussion with Tristan on Single
> > Port client-side implementation. Back then, we agreed that the client
> > should always send a Hotrod Ping request and if won't get any response
> > (or get some HTTP content back), it will try to upgrade to the Hotrod
> > protocol using Single Port.
> >
> > I've been playing with the implementation for a while, and
> > implementing it this way seems a bit "inconvenient" to me. The Ping
> > Operation uses 60s timeout, which seems to be a good fit as a default.
> > Unfortunately, for the Single Port functionality, this means we'd need
> > to wait 60s until we try to send HTTP request and do an upgrade. Also,
> > another problematic part is in Netty's HTTP handlers
> > (HttpObjectDecoder, HttpServerCodec and ByteToMessageDecoder). When
> > those classes fail to decode a message (REST expects HTTP rather than
> > a stream of bytes specific to Hotrod protocol), they just ignore it
> > and keep the channel in active state (which also makes sense for
> > HTTP/1.1 and HTTP/2).
> >
> > At this point, my intuition tells, that this doesn't look right and
> > seems to be a over-complicated. The whole HTTP upgrade idea seems to
> > work the other way around, use HTTP as a fallback and then upgrade to
> > other protocols. Forcing it to work a bit differently requires some
> > more effort.
> >
> > What if we preserved the Single Port setting in the client
> > configuration but implemented it as an enum with the following values
> > - true/false/auto. In automatic mode, the client would check if the
> > server port is set to 8\d{1,3} (this covers 80, 8080, 8081, 8443 and
> > friends). If that is true, we'd try to follow HTTP Upgrade procedure.
> > This looks very simple and I think this might actually work. Please
> > note, that we need the single port setting in the client configuration
> > to cover some corner cases like the Single Port exposed on different
> > port (like 4444) or Hot Rod exposed on port that starts with 8.
> >
> > What do you think about such simplification?
> >
> > Thanks,
> > Sebastian
> >
> >
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20181212/8811b80f/attachment.html 

From rvansa at redhat.com  Thu Dec 13 04:08:07 2018
From: rvansa at redhat.com (Radim Vansa)
Date: Thu, 13 Dec 2018 10:08:07 +0100
Subject: [infinispan-dev] Single Port Client
In-Reply-To: <CAA9R9O6PQ0knCRfHvJ4+eoWaUNJ6mZseuMLkm6J8Qj9n2=wuVA@mail.gmail.com>
References: <CAA9R9O7-Jcw7ss9F7Pz-QHFf2wOjQm+k1FqYmk0-QtpHWwJyVQ@mail.gmail.com>
	<58fd205f-1b17-1cb6-aa7b-af1886de93ca@redhat.com>
	<CAA9R9O6PQ0knCRfHvJ4+eoWaUNJ6mZseuMLkm6J8Qj9n2=wuVA@mail.gmail.com>
Message-ID: <29902ae4-ca90-7127-2bf0-32ecdddb385a@redhat.com>

On 12/12/2018 03:30 PM, Sebastian Laskawiec wrote:
> On Tue, Dec 11, 2018 at 11:13 AM Radim Vansa <rvansa at redhat.com 
> <mailto:rvansa at redhat.com>> wrote:
>
>     I dislike having any logic based on the port number in some range;
>     it's
>     not common that behaviour would change if you set port to 9xxx
>     instead
>     of 8xxx.
>
>
> That's not a problem with my approach, since you can always manually 
> turn the setting off or on. Here's how you do it:
> ConfigurationBuilder cb = ...
> cb.singlePort(SinglePortMode.ENABLED); // other options: DISABLED and AUTO

Adding config options is just a way to avoid solving problems :) 
Remember the famous quote: "Less knobs!"

>
>
>     Is there an (up-to-date) design doc?
>
>
> No, this is just a proposal. I was hoping that you guys like it and 
> then, with some thumbs up, I could update the design doc.
>
> Here's the most up-to-date version in case you were looking for it: 
> https://github.com/infinispan/infinispan-designs/blob/master/Single_port.adoc
>
>
>     I don't fully follow, but if there's a problem in the HTTP
>     handlers you
>     can add a PING-detecting handler below...?
>
>
> Thanks for the hint Radim!
>
> Inspired by your idea I went ahead and checked how OpenShift Router 
> behaves. It turns out that it responds HTTP 400 if you throw Hotrod 
> bytes at it and then drops the connection.

I understand that the reason to have Hot Rod PING sent as the first 
operation is to make sure that a new client that tries to connect to old 
server won't confuse the server, is that correct? Or is there anything else?

I'll assume that a new server will handle both Hot Rod PING and HTTP 
request correctly without any prelude, and old one will be ok with Hot 
Rod PING only. I don't really understand the:

 > implementing it this way seems a bit "inconvenient" to me. The Ping
 > Operation uses 60s timeout, which seems to be a good fit as a default.
 > Unfortunately, for the Single Port functionality, this means we'd need
 > to wait 60s until we try to send HTTP request and do an upgrade

why would you wait for 60 seconds? If the other end is Infinispan server 
(old or new), you just send HR PING and you're done, server will proceed 
correctly. If the other server is a router, you'll get a response 
starting with 'HTTP': in Hot Rod protocol that would be parsed as opCode 
0x54 which is illegal response code (the id belongs to 
COUNTER_RESET_REQUEST). At this point you know that this connection is 
going to be closed, and can immediately start another one (is *this* the 
problem?) that will send a HTTP request with Upgrade header.

> I also realized, there's one more moving bit - TCP Keepalive. Luckily, 
> we can control this setting over configuration in our standalone.xml. 
> However, it is perfectly legal what I've seen in Netty (do not respond 
> and keep the connection alive assuming that TCP Keepalive is set to true).
>
> The more I think about this, the more I'm convinced that the Single 
> Port support should be explicitly set in the client (or inferred from 
> the configuration). I do not know how Nginx, Linkerd or Envoy behaves 
> in situation when they expect HTTP and get a stream of bytes. Relying 
> on this partially unknown behavior for doing our upgrade procedure 
> doesn't seem right to me.

FYI Envoy does the same, send 400 and terminate the connection.

>
> Just in case you're worried about the additional logic on the client 
> side - it's super small. Really, only 13 lines including brackets ;) 
> https://github.com/infinispan/infinispan/pull/6133/files#diff-684a10c939f31fcfef0f5f48d469393aR618

I am not worried about any logic in the client code, I am worried about 
logic between chair and keyboard.

R.

>
>     Radim
>
>     On 12/10/2018 03:27 PM, Sebastian Laskawiec wrote:
>     > Hey guys,
>     >
>     > During Infinispan F2F, I had a short discussion with Tristan on
>     Single
>     > Port client-side implementation. Back then, we agreed that the
>     client
>     > should always send a Hotrod Ping request and if won't get any
>     response
>     > (or get some HTTP content back), it will try to upgrade to the
>     Hotrod
>     > protocol using Single Port.
>     >
>     > I've been playing with the implementation for a while, and
>     > implementing it this way seems a bit "inconvenient" to me. The Ping
>     > Operation uses 60s timeout, which seems to be a good fit as a
>     default.
>     > Unfortunately, for the Single Port functionality, this means
>     we'd need
>     > to wait 60s until we try to send HTTP request and do an upgrade.
>     Also,
>     > another problematic part is in Netty's HTTP handlers
>     > (HttpObjectDecoder, HttpServerCodec and ByteToMessageDecoder). When
>     > those classes fail to decode a message (REST expects HTTP rather
>     than
>     > a stream of bytes specific to Hotrod protocol), they just ignore it
>     > and keep the channel in active state (which also makes sense for
>     > HTTP/1.1 and HTTP/2).
>     >
>     > At this point, my intuition tells, that this doesn't look right and
>     > seems to be a over-complicated. The whole HTTP upgrade idea
>     seems to
>     > work the other way around, use HTTP as a fallback and then
>     upgrade to
>     > other protocols. Forcing it to work a bit differently requires some
>     > more effort.
>     >
>     > What if we preserved the Single Port setting in the client
>     > configuration but implemented it as an enum with the following
>     values
>     > - true/false/auto. In automatic mode, the client would check if the
>     > server port is set to 8\d{1,3}?(this covers 80, 8080, 8081, 8443
>     and
>     > friends). If that is true, we'd try to follow HTTP Upgrade
>     procedure.
>     > This looks very simple and I think this might actually work. Please
>     > note, that we need the single port setting in the client
>     configuration
>     > to cover some corner cases like the Single Port exposed on
>     different
>     > port (like 4444) or Hot Rod exposed on port that starts with 8.
>     >
>     > What do you think about such simplification?
>     >
>     > Thanks,
>     > Sebastian
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > infinispan-dev mailing list
>     > infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>     -- 
>     Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
>     JBoss Performance Team
>
>     _______________________________________________
>     infinispan-dev mailing list
>     infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From slaskawi at redhat.com  Thu Dec 13 08:45:20 2018
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Thu, 13 Dec 2018 14:45:20 +0100
Subject: [infinispan-dev] Single Port Client
In-Reply-To: <29902ae4-ca90-7127-2bf0-32ecdddb385a@redhat.com>
References: <CAA9R9O7-Jcw7ss9F7Pz-QHFf2wOjQm+k1FqYmk0-QtpHWwJyVQ@mail.gmail.com>
	<58fd205f-1b17-1cb6-aa7b-af1886de93ca@redhat.com>
	<CAA9R9O6PQ0knCRfHvJ4+eoWaUNJ6mZseuMLkm6J8Qj9n2=wuVA@mail.gmail.com>
	<29902ae4-ca90-7127-2bf0-32ecdddb385a@redhat.com>
Message-ID: <CAA9R9O4jViSBQZCKfmjZkJHCufN1+Ub-=UBTaJJuAFMSBaWJAw@mail.gmail.com>

On Thu, Dec 13, 2018 at 10:23 AM Radim Vansa <rvansa at redhat.com> wrote:

> On 12/12/2018 03:30 PM, Sebastian Laskawiec wrote:
> > On Tue, Dec 11, 2018 at 11:13 AM Radim Vansa <rvansa at redhat.com
> > <mailto:rvansa at redhat.com>> wrote:
> >
> >     I dislike having any logic based on the port number in some range;
> >     it's
> >     not common that behaviour would change if you set port to 9xxx
> >     instead
> >     of 8xxx.
> >
> >
> > That's not a problem with my approach, since you can always manually
> > turn the setting off or on. Here's how you do it:
> > ConfigurationBuilder cb = ...
> > cb.singlePort(SinglePortMode.ENABLED); // other options: DISABLED and
> AUTO
>
> Adding config options is just a way to avoid solving problems :)
> Remember the famous quote: "Less knobs!"
>

It depends on the problem in my opinion. I always preferred to have more
configuration options with good defaults.


>
> >
> >
> >     Is there an (up-to-date) design doc?
> >
> >
> > No, this is just a proposal. I was hoping that you guys like it and
> > then, with some thumbs up, I could update the design doc.
> >
> > Here's the most up-to-date version in case you were looking for it:
> >
> https://github.com/infinispan/infinispan-designs/blob/master/Single_port.adoc
> >
> >
> >     I don't fully follow, but if there's a problem in the HTTP
> >     handlers you
> >     can add a PING-detecting handler below...?
> >
> >
> > Thanks for the hint Radim!
> >
> > Inspired by your idea I went ahead and checked how OpenShift Router
> > behaves. It turns out that it responds HTTP 400 if you throw Hotrod
> > bytes at it and then drops the connection.
>
> I understand that the reason to have Hot Rod PING sent as the first
> operation is to make sure that a new client that tries to connect to old
> server won't confuse the server, is that correct? Or is there anything
> else?
>

Not only. We (Tristan and I when we were discussing it) wanted to introduce
the smallest possible hit on a default scenario - a Hotrod client
connecting to Infinispan without Single Port. If we mess up this scenario,
we might quickly get into all sorts of problem (including performance).


>
> I'll assume that a new server will handle both Hot Rod PING and HTTP
> request correctly without any prelude, and old one will be ok with Hot
> Rod PING only. I don't really understand the:
>

I'm not sure if I follow. The Single Port functionality for non-TLS
scenario requires only REST interface. Hotrod is optional. We upgrade to
Hotrod using HTTP/1.1 Upgrade procedure (see RFC 7230 [1]). This
essentially means, that you need to send an HTTP request in order to
upgrade to another protocol (such as Hotrod) and reuse the same TCP
connection.

So as you can see, the Single Port can not speak both protocols, HTTP and
Hotrod, at the same time. It requires sending an HTTP request with proper
header, and then upgrading to Hotrod. The reason it has been implemented
this way is to support Reverse Proxies (like HAProxy in the OpenShift
Router, but of course there are more of them). As I mentioned in my last
email, the HA proxy immediately responds with HTTP 400 if you throw binary
payload at it. That's why we need to follow the HTTP upgrade procedure - to
get through it.

[1]
https://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7230.html#header.upgrade


>
>  > implementing it this way seems a bit "inconvenient" to me. The Ping
>  > Operation uses 60s timeout, which seems to be a good fit as a default.
>  > Unfortunately, for the Single Port functionality, this means we'd need
>  > to wait 60s until we try to send HTTP request and do an upgrade
>
> why would you wait for 60 seconds? If the other end is Infinispan server
> (old or new), you just send HR PING and you're done, server will proceed
> correctly. If the other server is a router, you'll get a response
> starting with 'HTTP': in Hot Rod protocol that would be parsed as opCode
> 0x54 which is illegal response code (the id belongs to
> COUNTER_RESET_REQUEST). At this point you know that this connection is
> going to be closed, and can immediately start another one (is *this* the
> problem?) that will send a HTTP request with Upgrade header.
>

This is correct. However, you silently assumed that the HTTP Server (either
our own Infinispan REST Server or any type of Reverse Proxy we're passing
through) will respond with an HTTP message (either 4xx or 5xx) when
receiving binary traffic. At this point I know that HAProxy does that, and
the same does Envoy (as you told us in the bottom of this email).
Infinispan REST server just ignores such a request.

So it is safe to assume, that all Reverse Proxies will return an HTTP
message when we send a bunch of bytes at it? If yes, than we need to
correct the REST implementation (that should not be too hard) and kick the
Single Port in, when a Hotrod client receives a HTTP message back when
sending PING. But then, if some Reverse Proxy between the server and client
does something different (ignoring such a request as our Infinispan REST
server does now, or simply refuse a connection, or anything else) we won't
be able to upgrade the connection.

My proposal is to set the Single Port support on the client, so that the
client starts the communication with HTTP message (and not the Hotrod
PING). Doing it this way, allows us to forget about all those crazy
situations with Reverse Proxies. The key point is that we never throw raw
bytes at them. In my opinion this can save us a lot of headache.

So, to be honest, I can implement it whichever way you prefer. My personal
feeling is that an additional setting on the Hotrod client is much safer
bet (at least for now).

@Tristan, @Ryan, I think you guys also have some experience in this matter.
I would be very interested in hearing your opinion as well.


>
> > I also realized, there's one more moving bit - TCP Keepalive. Luckily,
> > we can control this setting over configuration in our standalone.xml.
> > However, it is perfectly legal what I've seen in Netty (do not respond
> > and keep the connection alive assuming that TCP Keepalive is set to
> true).
> >
> > The more I think about this, the more I'm convinced that the Single
> > Port support should be explicitly set in the client (or inferred from
> > the configuration). I do not know how Nginx, Linkerd or Envoy behaves
> > in situation when they expect HTTP and get a stream of bytes. Relying
> > on this partially unknown behavior for doing our upgrade procedure
> > doesn't seem right to me.
>
> FYI Envoy does the same, send 400 and terminate the connection.
>

Ok, so it behaves the same as HA Proxy.


>
> >
> > Just in case you're worried about the additional logic on the client
> > side - it's super small. Really, only 13 lines including brackets ;)
> >
> https://github.com/infinispan/infinispan/pull/6133/files#diff-684a10c939f31fcfef0f5f48d469393aR618
>
> I am not worried about any logic in the client code, I am worried about
> logic between chair and keyboard.
>

Ouch! That was pretty rude, Radim. Words like that make me feel very
uncomfortable and actually offend me. I would like to ask you to stick to
the technical aspect of this thread and do not go personal.

As we've known each other for a pretty long time, I will pretend I didn't
see this and I just read "please have a look what I just wrote, maybe you
will reconsider your implementation?".


>
> R.
>
> >
> >     Radim
> >
> >     On 12/10/2018 03:27 PM, Sebastian Laskawiec wrote:
> >     > Hey guys,
> >     >
> >     > During Infinispan F2F, I had a short discussion with Tristan on
> >     Single
> >     > Port client-side implementation. Back then, we agreed that the
> >     client
> >     > should always send a Hotrod Ping request and if won't get any
> >     response
> >     > (or get some HTTP content back), it will try to upgrade to the
> >     Hotrod
> >     > protocol using Single Port.
> >     >
> >     > I've been playing with the implementation for a while, and
> >     > implementing it this way seems a bit "inconvenient" to me. The Ping
> >     > Operation uses 60s timeout, which seems to be a good fit as a
> >     default.
> >     > Unfortunately, for the Single Port functionality, this means
> >     we'd need
> >     > to wait 60s until we try to send HTTP request and do an upgrade.
> >     Also,
> >     > another problematic part is in Netty's HTTP handlers
> >     > (HttpObjectDecoder, HttpServerCodec and ByteToMessageDecoder). When
> >     > those classes fail to decode a message (REST expects HTTP rather
> >     than
> >     > a stream of bytes specific to Hotrod protocol), they just ignore it
> >     > and keep the channel in active state (which also makes sense for
> >     > HTTP/1.1 and HTTP/2).
> >     >
> >     > At this point, my intuition tells, that this doesn't look right and
> >     > seems to be a over-complicated. The whole HTTP upgrade idea
> >     seems to
> >     > work the other way around, use HTTP as a fallback and then
> >     upgrade to
> >     > other protocols. Forcing it to work a bit differently requires some
> >     > more effort.
> >     >
> >     > What if we preserved the Single Port setting in the client
> >     > configuration but implemented it as an enum with the following
> >     values
> >     > - true/false/auto. In automatic mode, the client would check if the
> >     > server port is set to 8\d{1,3} (this covers 80, 8080, 8081, 8443
> >     and
> >     > friends). If that is true, we'd try to follow HTTP Upgrade
> >     procedure.
> >     > This looks very simple and I think this might actually work. Please
> >     > note, that we need the single port setting in the client
> >     configuration
> >     > to cover some corner cases like the Single Port exposed on
> >     different
> >     > port (like 4444) or Hot Rod exposed on port that starts with 8.
> >     >
> >     > What do you think about such simplification?
> >     >
> >     > Thanks,
> >     > Sebastian
> >     >
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > infinispan-dev mailing list
> >     > infinispan-dev at lists.jboss.org
> >     <mailto:infinispan-dev at lists.jboss.org>
> >     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> >
> >     --
> >     Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
> >     JBoss Performance Team
> >
> >     _______________________________________________
> >     infinispan-dev mailing list
> >     infinispan-dev at lists.jboss.org <mailto:
> infinispan-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20181213/2227dec2/attachment-0001.html 

From rvansa at redhat.com  Thu Dec 13 10:38:27 2018
From: rvansa at redhat.com (Radim Vansa)
Date: Thu, 13 Dec 2018 16:38:27 +0100
Subject: [infinispan-dev] Single Port Client
In-Reply-To: <CAA9R9O4jViSBQZCKfmjZkJHCufN1+Ub-=UBTaJJuAFMSBaWJAw@mail.gmail.com>
References: <CAA9R9O7-Jcw7ss9F7Pz-QHFf2wOjQm+k1FqYmk0-QtpHWwJyVQ@mail.gmail.com>
	<58fd205f-1b17-1cb6-aa7b-af1886de93ca@redhat.com>
	<CAA9R9O6PQ0knCRfHvJ4+eoWaUNJ6mZseuMLkm6J8Qj9n2=wuVA@mail.gmail.com>
	<29902ae4-ca90-7127-2bf0-32ecdddb385a@redhat.com>
	<CAA9R9O4jViSBQZCKfmjZkJHCufN1+Ub-=UBTaJJuAFMSBaWJAw@mail.gmail.com>
Message-ID: <4dc97786-726a-f14c-11b8-ee6d1f90bfce@redhat.com>

Hey Sebastian,

I am sorry that you took my comment about errors between chair and 
keyboard completely wrong: it was definitely not pointed at you! What I 
meant is that users will often misconfigure (I've been there many 
times), and their experience will suffer. Therefore I am not concerned 
about any 'smart' logic we write (regardless of number of lines of 
code), but about any complexity required from, or offered to the users.

Rest of the comments inline...

On 12/13/2018 02:45 PM, Sebastian Laskawiec wrote:
>
>
> On Thu, Dec 13, 2018 at 10:23 AM Radim Vansa <rvansa at redhat.com 
> <mailto:rvansa at redhat.com>> wrote:
>
>     On 12/12/2018 03:30 PM, Sebastian Laskawiec wrote:
>     > On Tue, Dec 11, 2018 at 11:13 AM Radim Vansa <rvansa at redhat.com
>     <mailto:rvansa at redhat.com>
>     > <mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>>> wrote:
>     >
>     >? ? ?I dislike having any logic based on the port number in some
>     range;
>     >? ? ?it's
>     >? ? ?not common that behaviour would change if you set port to 9xxx
>     >? ? ?instead
>     >? ? ?of 8xxx.
>     >
>     >
>     > That's not a problem with my approach, since you can always
>     manually
>     > turn the setting off or on. Here's how you do it:
>     > ConfigurationBuilder cb = ...
>     > cb.singlePort(SinglePortMode.ENABLED); // other options:
>     DISABLED and AUTO
>
>     Adding config options is just a way to avoid solving problems :)
>     Remember the famous quote: "Less knobs!"
>
>
> It depends on the problem in my opinion. I always preferred to have 
> more configuration options with good defaults.
>
>
>     >
>     >
>     >? ? ?Is there an (up-to-date) design doc?
>     >
>     >
>     > No, this is just a proposal. I was hoping that you guys like it and
>     > then, with some thumbs up, I could update the design doc.
>     >
>     > Here's the most up-to-date version in case you were looking for it:
>     >
>     https://github.com/infinispan/infinispan-designs/blob/master/Single_port.adoc
>     >
>     >
>     >? ? ?I don't fully follow, but if there's a problem in the HTTP
>     >? ? ?handlers you
>     >? ? ?can add a PING-detecting handler below...?
>     >
>     >
>     > Thanks for the hint Radim!
>     >
>     > Inspired by your idea I went ahead and checked how OpenShift Router
>     > behaves. It turns out that it responds HTTP 400 if you throw Hotrod
>     > bytes at it and then drops the connection.
>
>     I understand that the reason to have Hot Rod PING sent as the first
>     operation is to make sure that a new client that tries to connect
>     to old
>     server won't confuse the server, is that correct? Or is there
>     anything else?
>
>
> Not only. We (Tristan and I when we were discussing it) wanted to 
> introduce the smallest possible hit on a default scenario - a Hotrod 
> client connecting to Infinispan without Single Port. If we mess up 
> this scenario, we might quickly get into all sorts of problem 
> (including performance).
>
>
>     I'll assume that a new server will handle both Hot Rod PING and HTTP
>     request correctly without any prelude, and old one will be ok with
>     Hot
>     Rod PING only. I don't really understand the:
>
>
> I'm not sure if I follow. The Single Port functionality for non-TLS 
> scenario requires only REST interface. Hotrod is optional. We upgrade 
> to Hotrod using HTTP/1.1 Upgrade procedure (see RFC 7230 [1]). This 
> essentially means, that you need to send an HTTP request in order to 
> upgrade to another protocol (such as Hotrod) and reuse the same TCP 
> connection.

Okay, then my assumption was incorrect. That means that single-port 
server and non-single-port server are incompatible because neither can 
accept other's initial request :-/

It seems that Hot Rod and HTTP communication is easily distinguishable 
with first few bytes: could we enhance single-port to be able to handle 
Hot Rod PING immediately without the HTTP Upgrade to accommodate older 
clients? Then we could run single-port all the time and everyone wins.

Btw., I assume that we can't handle both TLS and non-TLS connections on 
same port either, is that correct? Usually webservers can't be 
configured to handle both HTTP and HTTPS on the same port - is there any 
difference here?

>
> So as you can see, the Single Port can not speak both protocols, HTTP 
> and Hotrod, at the same time. It requires sending an HTTP request with 
> proper header, and then upgrading to Hotrod. The reason it has been 
> implemented this way is to support Reverse Proxies (like HAProxy in 
> the OpenShift Router, but of course there are more of them). As I 
> mentioned in my last email, the HA proxy immediately responds with 
> HTTP 400 if you throw binary payload at it. That's why we need to 
> follow the HTTP upgrade procedure - to get through it.
>
> [1] 
> https://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7230.html#header.upgrade
>
>
>     ?> implementing it this way seems a bit "inconvenient" to me. The Ping
>     ?> Operation uses 60s timeout, which seems to be a good fit as a
>     default.
>     ?> Unfortunately, for the Single Port functionality, this means
>     we'd need
>     ?> to wait 60s until we try to send HTTP request and do an upgrade
>
>     why would you wait for 60 seconds? If the other end is Infinispan
>     server
>     (old or new), you just send HR PING and you're done, server will
>     proceed
>     correctly. If the other server is a router, you'll get a response
>     starting with 'HTTP': in Hot Rod protocol that would be parsed as
>     opCode
>     0x54 which is illegal response code (the id belongs to
>     COUNTER_RESET_REQUEST). At this point you know that this
>     connection is
>     going to be closed, and can immediately start another one (is
>     *this* the
>     problem?) that will send a HTTP request with Upgrade header.
>
>
> This is correct. However, you silently assumed that the HTTP Server 
> (either our own Infinispan REST Server or any type of Reverse Proxy 
> we're passing through) will respond with an HTTP message (either 4xx 
> or 5xx) when receiving binary traffic. At this point I know that 
> HAProxy does that, and the same does Envoy (as you told us in the 
> bottom of this email). Infinispan REST server just ignores such a 
> request.
>
> So it is safe to assume, that all Reverse Proxies will return an HTTP 
> message when we send a bunch of bytes at it? If yes, than we need to 
> correct the REST implementation (that should not be too hard) and kick 
> the Single Port in, when a Hotrod client receives a HTTP message back 
> when sending PING. But then, if some Reverse Proxy between the server 
> and client does something different (ignoring such a request as our 
> Infinispan REST server does now, or simply refuse a connection, or 
> anything else) we won't be able to upgrade the connection.

That's a valid point - the spec says that it SHOULD [1] respond with 400 
but it is not 100% (buggy proxies are to be expected on the internet). 
We should probably correct the REST server...

[1] https://tools.ietf.org/html/rfc7230#section-3.1.1

>
> My proposal is to set the Single Port support on the client, so that 
> the client starts the communication with HTTP message (and not the 
> Hotrod PING). Doing it this way, allows us to forget about all those 
> crazy situations with Reverse Proxies. The key point is that we never 
> throw raw bytes at them. In my opinion this can save us a lot of headache.

I am starting to think that we really should start the communication 
with HTTP message, and this shouldn't be a separate config property 
(single-port) but based on Hot Rod version.

>
> So, to be honest, I can implement it whichever way you prefer. My 
> personal feeling is that an additional setting on the Hotrod client is 
> much safer bet (at least for now).
>
> @Tristan, @Ryan, I think you guys also have some experience in this 
> matter. I would be very interested in hearing your opinion as well.
>
>
>     > I also realized, there's one more moving bit - TCP Keepalive.
>     Luckily,
>     > we can control this setting over configuration in our
>     standalone.xml.
>     > However, it is perfectly legal what I've seen in Netty (do not
>     respond
>     > and keep the connection alive assuming that TCP Keepalive is set
>     to true).
>     >
>     > The more I think about this, the more I'm convinced that the Single
>     > Port support should be explicitly set in the client (or inferred
>     from
>     > the configuration). I do not know how Nginx, Linkerd or Envoy
>     behaves
>     > in situation when they expect HTTP and get a stream of bytes.
>     Relying
>     > on this partially unknown behavior for doing our upgrade procedure
>     > doesn't seem right to me.
>
>     FYI Envoy does the same, send 400 and terminate the connection.
>
>
> Ok, so it behaves the same as HA Proxy.
>
>
>     >
>     > Just in case you're worried about the additional logic on the
>     client
>     > side - it's super small. Really, only 13 lines including
>     brackets ;)
>     >
>     https://github.com/infinispan/infinispan/pull/6133/files#diff-684a10c939f31fcfef0f5f48d469393aR618
>
>     I am not worried about any logic in the client code, I am worried
>     about
>     logic between chair and keyboard.
>
>
> Ouch! That was pretty rude, Radim. Words like that make me feel very 
> uncomfortable and actually offend me. I would like to ask you to stick 
> to the technical aspect of this thread and do not go personal.
>
> As we've known each other for a pretty long time, I will pretend I 
> didn't see this and I just read "please have a look what I just wrote, 
> maybe you will reconsider your implementation?".

See the top, please, and my apologies if you took the above as an 
offense. TBH I haven't even checked the implementation, and I am far 
from judging it.

Radim

>
>     R.
>
>     >
>     >? ? ?Radim
>     >
>     >? ? ?On 12/10/2018 03:27 PM, Sebastian Laskawiec wrote:
>     >? ? ?> Hey guys,
>     >? ? ?>
>     >? ? ?> During Infinispan F2F, I had a short discussion with
>     Tristan on
>     >? ? ?Single
>     >? ? ?> Port client-side implementation. Back then, we agreed that the
>     >? ? ?client
>     >? ? ?> should always send a Hotrod Ping request and if won't get any
>     >? ? ?response
>     >? ? ?> (or get some HTTP content back), it will try to upgrade to the
>     >? ? ?Hotrod
>     >? ? ?> protocol using Single Port.
>     >? ? ?>
>     >? ? ?> I've been playing with the implementation for a while, and
>     >? ? ?> implementing it this way seems a bit "inconvenient" to me.
>     The Ping
>     >? ? ?> Operation uses 60s timeout, which seems to be a good fit as a
>     >? ? ?default.
>     >? ? ?> Unfortunately, for the Single Port functionality, this means
>     >? ? ?we'd need
>     >? ? ?> to wait 60s until we try to send HTTP request and do an
>     upgrade.
>     >? ? ?Also,
>     >? ? ?> another problematic part is in Netty's HTTP handlers
>     >? ? ?> (HttpObjectDecoder, HttpServerCodec and
>     ByteToMessageDecoder). When
>     >? ? ?> those classes fail to decode a message (REST expects HTTP
>     rather
>     >? ? ?than
>     >? ? ?> a stream of bytes specific to Hotrod protocol), they just
>     ignore it
>     >? ? ?> and keep the channel in active state (which also makes
>     sense for
>     >? ? ?> HTTP/1.1 and HTTP/2).
>     >? ? ?>
>     >? ? ?> At this point, my intuition tells, that this doesn't look
>     right and
>     >? ? ?> seems to be a over-complicated. The whole HTTP upgrade idea
>     >? ? ?seems to
>     >? ? ?> work the other way around, use HTTP as a fallback and then
>     >? ? ?upgrade to
>     >? ? ?> other protocols. Forcing it to work a bit differently
>     requires some
>     >? ? ?> more effort.
>     >? ? ?>
>     >? ? ?> What if we preserved the Single Port setting in the client
>     >? ? ?> configuration but implemented it as an enum with the following
>     >? ? ?values
>     >? ? ?> - true/false/auto. In automatic mode, the client would
>     check if the
>     >? ? ?> server port is set to 8\d{1,3}?(this covers 80, 8080,
>     8081, 8443
>     >? ? ?and
>     >? ? ?> friends). If that is true, we'd try to follow HTTP Upgrade
>     >? ? ?procedure.
>     >? ? ?> This looks very simple and I think this might actually
>     work. Please
>     >? ? ?> note, that we need the single port setting in the client
>     >? ? ?configuration
>     >? ? ?> to cover some corner cases like the Single Port exposed on
>     >? ? ?different
>     >? ? ?> port (like 4444) or Hot Rod exposed on port that starts
>     with 8.
>     >? ? ?>
>     >? ? ?> What do you think about such simplification?
>     >? ? ?>
>     >? ? ?> Thanks,
>     >? ? ?> Sebastian
>     >? ? ?>
>     >? ? ?>
>     >? ? ?>
>     >? ? ?>
>     >? ? ?> _______________________________________________
>     >? ? ?> infinispan-dev mailing list
>     >? ? ?> infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>
>     >? ? ?<mailto:infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>>
>     >? ? ?> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     >
>     >
>     >? ? ?--
>     >? ? ?Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>
>     <mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>>>
>     >? ? ?JBoss Performance Team
>     >
>     >? ? ?_______________________________________________
>     >? ? ?infinispan-dev mailing list
>     > infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>
>     <mailto:infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>>
>     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     >
>     >
>     >
>     > _______________________________________________
>     > infinispan-dev mailing list
>     > infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>     -- 
>     Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
>     JBoss Performance Team
>
>     _______________________________________________
>     infinispan-dev mailing list
>     infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From galder at redhat.com  Fri Dec 14 04:05:58 2018
From: galder at redhat.com (Galder Zamarreno)
Date: Fri, 14 Dec 2018 10:05:58 +0100
Subject: [infinispan-dev] Partial updates in 2LC
Message-ID: <CAAcPREsspU-vb2RY524qEm0FYVF7fCh-uKMhx3j9BtRYncu43A@mail.gmail.com>

Hey Radim,

We've had some chats in the past where we discussed the behaviour of non-tx
2LC and partial updates. I've wrote a couple of tests [1] to see how things
behave:

For a repl read-write, entity cache, if the failure happens on the async
FutureUpdate call, that's fine because the Tombstone has already been sent
and the cache won't return anything.

If the failure happens when the Tombstone is sent, we seem to have a
problem because it results in stale data in the node that failed to apply
the Tombstone. The FutureUpdate that comes after the Tombstone cannot apply
because it doesn't find the Tombstone.

Sync logs any errors but does not propagate them [2]. Is there any reason
for not rethrowing the exception? I tried to rethrow it and the JDBC
transaction rolls back, which is not too bad cos at least that way both
nodes contain the last committed data.

As a side note, the CorrectnessTestCase subclasses are not running by
default, we should change that.

Cheers,
Galder

[1]
https://github.com/galderz/infinispan/commit/2934e0b3e8ab9af5fb1471c5fdbb0716e5a11c31
[2]
https://github.com/infinispan/infinispan/blob/master/hibernate/cache-v53/src/main/java/org/infinispan/hibernate/cache/v53/impl/Sync.java
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20181214/e71a01d9/attachment.html 

From galder at redhat.com  Fri Dec 14 04:08:49 2018
From: galder at redhat.com (Galder Zamarreno)
Date: Fri, 14 Dec 2018 10:08:49 +0100
Subject: [infinispan-dev] Partial updates in 2LC
In-Reply-To: <CAAcPREsspU-vb2RY524qEm0FYVF7fCh-uKMhx3j9BtRYncu43A@mail.gmail.com>
References: <CAAcPREsspU-vb2RY524qEm0FYVF7fCh-uKMhx3j9BtRYncu43A@mail.gmail.com>
Message-ID: <CAAcPREuX8fGowPaPUv21h13jE=4BmtNKW0c2yQ_hhBUptuPX2A@mail.gmail.com>

Forgot to point out, here is where Sync logs the exception:
https://github.com/infinispan/infinispan/blob/master/hibernate/cache-v53/src/main/java/org/infinispan/hibernate/cache/v53/impl/Sync.java#L78

On Fri, Dec 14, 2018 at 10:05 AM Galder Zamarreno <galder at redhat.com> wrote:

> Hey Radim,
>
> We've had some chats in the past where we discussed the behaviour of
> non-tx 2LC and partial updates. I've wrote a couple of tests [1] to see how
> things behave:
>
> For a repl read-write, entity cache, if the failure happens on the async
> FutureUpdate call, that's fine because the Tombstone has already been sent
> and the cache won't return anything.
>
> If the failure happens when the Tombstone is sent, we seem to have a
> problem because it results in stale data in the node that failed to apply
> the Tombstone. The FutureUpdate that comes after the Tombstone cannot apply
> because it doesn't find the Tombstone.
>
> Sync logs any errors but does not propagate them [2]. Is there any reason
> for not rethrowing the exception? I tried to rethrow it and the JDBC
> transaction rolls back, which is not too bad cos at least that way both
> nodes contain the last committed data.
>
> As a side note, the CorrectnessTestCase subclasses are not running by
> default, we should change that.
>
> Cheers,
> Galder
>
> [1]
> https://github.com/galderz/infinispan/commit/2934e0b3e8ab9af5fb1471c5fdbb0716e5a11c31
> [2]
> https://github.com/infinispan/infinispan/blob/master/hibernate/cache-v53/src/main/java/org/infinispan/hibernate/cache/v53/impl/Sync.java
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20181214/e70b5dbd/attachment.html 

From rory.odonnell at oracle.com  Fri Dec 14 05:29:52 2018
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 14 Dec 2018 10:29:52 +0000
Subject: [infinispan-dev] JDK 12 enters Rampdown Phase One
Message-ID: <3136a232-402b-fc01-930e-8151b3dd355a@oracle.com>

Hi Galder,

*JDK 12 Early Access build **is now available **at : - jdk.java.net/12/*

  * Per the JDK 12 schedule [1], we are now in Rampdown Phase One.
      o For more details , see Mark Reinhold's email to jdk-dev mailing
        list [2]
      o The overall feature set is frozen, no further JEPs will be
        targeted to this release.
      o We?ve forked the main-line source repository, jdk/jdk, to the
        JDK 12 stabilization repository.

Changes since the last availability email

  * JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector
    (Experimental) <http://openjdk.java.net/jeps/189>?moved to *Targeted*.
  * JEP 334: JVM Constants API <http://openjdk.java.net/jeps/334>?moved
    to *Targeted*.
  * JEP 344: Abortable Mixed Collections for G1
    <http://openjdk.java.net/jeps/344>?moved? to *Targeted*.
  * JEP 346: Promptly Return Unused Committed Memory from G1
    <http://openjdk.java.net/jeps/346> to *Targeted*.
  * JEP 326: Raw String Literals <https://openjdk.java.net/jeps/326>
    (Preview) *Proposed to drop from JDK 12*
      o link to proposal on jdk-dev
        <https://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002402.html>

Bug fixes reported by Open Source Projects? :

      o JDK-8211051 - fixed in b22 - reported by JUnit5
      o JDK-8211422 - fixed in b23 - reported by Apache Batik

The Java Crypto Roadmap <https://java.com/cryptoroadmap>?has been 
updated with the following target:

  * With the 2019-04-16 CPU,
      o Targeted Releases - JDK 12, JDK 11, JDK 8, and JDK 7
      o Distrust TLS server certificates anchored by Symantec Root CAs.

Oracle Java SE 8 Release Updates [3]

  * Public updates for Oracle Java SE 8 released after January 2019 will
    not be available for business, commercial or production use without
    a commercial license.

Rgds, Rory

[1] http://openjdk.java.net/projects/jdk/12/#Schedule
[2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002405.html
[3] https://java.com/en/download/release_notice.jsp

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20181214/db8f8bc6/attachment-0001.html 

From slaskawi at redhat.com  Fri Dec 14 05:49:05 2018
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Fri, 14 Dec 2018 11:49:05 +0100
Subject: [infinispan-dev] Single Port Client
In-Reply-To: <4dc97786-726a-f14c-11b8-ee6d1f90bfce@redhat.com>
References: <CAA9R9O7-Jcw7ss9F7Pz-QHFf2wOjQm+k1FqYmk0-QtpHWwJyVQ@mail.gmail.com>
	<58fd205f-1b17-1cb6-aa7b-af1886de93ca@redhat.com>
	<CAA9R9O6PQ0knCRfHvJ4+eoWaUNJ6mZseuMLkm6J8Qj9n2=wuVA@mail.gmail.com>
	<29902ae4-ca90-7127-2bf0-32ecdddb385a@redhat.com>
	<CAA9R9O4jViSBQZCKfmjZkJHCufN1+Ub-=UBTaJJuAFMSBaWJAw@mail.gmail.com>
	<4dc97786-726a-f14c-11b8-ee6d1f90bfce@redhat.com>
Message-ID: <CAA9R9O48pdgo395ANXGHXWG1QqYh3MikdjCtt4kahcoAHx_h-g@mail.gmail.com>

On Thu, Dec 13, 2018 at 4:42 PM Radim Vansa <rvansa at redhat.com> wrote:

> Hey Sebastian,
>
> I am sorry that you took my comment about errors between chair and
> keyboard completely wrong: it was definitely not pointed at you! What I
> meant is that users will often misconfigure (I've been there many
> times), and their experience will suffer. Therefore I am not concerned
> about any 'smart' logic we write (regardless of number of lines of
> code), but about any complexity required from, or offered to the users.
>

No problem, Radim. I was a little but surprised by that "left jab" coming
from nowhere ;) Emails are such a bad media of communication when it comes
to situations like this. In normal F2F communication that would never
happen. I'm also sorry for all the confusion...

This actually made me thinking, maybe it's the right time to do a small 15
min meeting to discuss this F2F? @Tristan, @Ryan, @Galder - would you also
be interested? I'll prepare some slides to show you the main pain points.


> Rest of the comments inline...
>
> On 12/13/2018 02:45 PM, Sebastian Laskawiec wrote:
> >
> >
> > On Thu, Dec 13, 2018 at 10:23 AM Radim Vansa <rvansa at redhat.com
> > <mailto:rvansa at redhat.com>> wrote:
> >
> >     On 12/12/2018 03:30 PM, Sebastian Laskawiec wrote:
> >     > On Tue, Dec 11, 2018 at 11:13 AM Radim Vansa <rvansa at redhat.com
> >     <mailto:rvansa at redhat.com>
> >     > <mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>>> wrote:
> >     >
> >     >     I dislike having any logic based on the port number in some
> >     range;
> >     >     it's
> >     >     not common that behaviour would change if you set port to 9xxx
> >     >     instead
> >     >     of 8xxx.
> >     >
> >     >
> >     > That's not a problem with my approach, since you can always
> >     manually
> >     > turn the setting off or on. Here's how you do it:
> >     > ConfigurationBuilder cb = ...
> >     > cb.singlePort(SinglePortMode.ENABLED); // other options:
> >     DISABLED and AUTO
> >
> >     Adding config options is just a way to avoid solving problems :)
> >     Remember the famous quote: "Less knobs!"
> >
> >
> > It depends on the problem in my opinion. I always preferred to have
> > more configuration options with good defaults.
> >
> >
> >     >
> >     >
> >     >     Is there an (up-to-date) design doc?
> >     >
> >     >
> >     > No, this is just a proposal. I was hoping that you guys like it and
> >     > then, with some thumbs up, I could update the design doc.
> >     >
> >     > Here's the most up-to-date version in case you were looking for it:
> >     >
> >
> https://github.com/infinispan/infinispan-designs/blob/master/Single_port.adoc
> >     >
> >     >
> >     >     I don't fully follow, but if there's a problem in the HTTP
> >     >     handlers you
> >     >     can add a PING-detecting handler below...?
> >     >
> >     >
> >     > Thanks for the hint Radim!
> >     >
> >     > Inspired by your idea I went ahead and checked how OpenShift Router
> >     > behaves. It turns out that it responds HTTP 400 if you throw Hotrod
> >     > bytes at it and then drops the connection.
> >
> >     I understand that the reason to have Hot Rod PING sent as the first
> >     operation is to make sure that a new client that tries to connect
> >     to old
> >     server won't confuse the server, is that correct? Or is there
> >     anything else?
> >
> >
> > Not only. We (Tristan and I when we were discussing it) wanted to
> > introduce the smallest possible hit on a default scenario - a Hotrod
> > client connecting to Infinispan without Single Port. If we mess up
> > this scenario, we might quickly get into all sorts of problem
> > (including performance).
> >
> >
> >     I'll assume that a new server will handle both Hot Rod PING and HTTP
> >     request correctly without any prelude, and old one will be ok with
> >     Hot
> >     Rod PING only. I don't really understand the:
> >
> >
> > I'm not sure if I follow. The Single Port functionality for non-TLS
> > scenario requires only REST interface. Hotrod is optional. We upgrade
> > to Hotrod using HTTP/1.1 Upgrade procedure (see RFC 7230 [1]). This
> > essentially means, that you need to send an HTTP request in order to
> > upgrade to another protocol (such as Hotrod) and reuse the same TCP
> > connection.
>
> Okay, then my assumption was incorrect. That means that single-port
> server and non-single-port server are incompatible because neither can
> accept other's initial request :-/
>
> It seems that Hot Rod and HTTP communication is easily distinguishable
> with first few bytes: could we enhance single-port to be able to handle
> Hot Rod PING immediately without the HTTP Upgrade to accommodate older
> clients? Then we could run single-port all the time and everyone wins.
>

Yes, that's absolutely doable, but it doesn't solve the problem, because
there might be some Reverse Proxies on the way (such as an OCP Router,
Nginx or anything else). Those proxies might mess up with our upgrade flow
(as you mentioned below, there can be buggy proxies on the way). The main
problem is that we don't know (we can assume but we are not 100% certain),
how the Reverse Proxy will behave if we throw binary protocol at it.

Also, if we always start with Single Port turned on, we'll add additional
round trip (send HTTP with upgrade request, wait for response, then switch
to Hotrod). This adds some delay and I'm not sure we should do it. If we
wanted to consider this, I would need to get Tristan's "green stamp" on it.
But I have serious doubts


>
> Btw., I assume that we can't handle both TLS and non-TLS connections on
> same port either, is that correct? Usually webservers can't be
> configured to handle both HTTP and HTTPS on the same port - is there any
> difference here?
>

The encrypted use case is soooo much easier. The protocol negotiation
happen during TLS handshake. Once it's finished and connection is
established (so after the handshake is done), you already know about the
communication protocol you will be using. If we wanted to support only
encrypted use cases, the implementation would in 10-20 lines of code.

Frankly, I expect people to be using unencrypted use cases when developing
features and encrypted use cases on production. That's my gut feeling how
this feature will be used.


>
> >
> > So as you can see, the Single Port can not speak both protocols, HTTP
> > and Hotrod, at the same time. It requires sending an HTTP request with
> > proper header, and then upgrading to Hotrod. The reason it has been
> > implemented this way is to support Reverse Proxies (like HAProxy in
> > the OpenShift Router, but of course there are more of them). As I
> > mentioned in my last email, the HA proxy immediately responds with
> > HTTP 400 if you throw binary payload at it. That's why we need to
> > follow the HTTP upgrade procedure - to get through it.
> >
> > [1]
> >
> https://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7230.html#header.upgrade
> >
> >
> >      > implementing it this way seems a bit "inconvenient" to me. The
> Ping
> >      > Operation uses 60s timeout, which seems to be a good fit as a
> >     default.
> >      > Unfortunately, for the Single Port functionality, this means
> >     we'd need
> >      > to wait 60s until we try to send HTTP request and do an upgrade
> >
> >     why would you wait for 60 seconds? If the other end is Infinispan
> >     server
> >     (old or new), you just send HR PING and you're done, server will
> >     proceed
> >     correctly. If the other server is a router, you'll get a response
> >     starting with 'HTTP': in Hot Rod protocol that would be parsed as
> >     opCode
> >     0x54 which is illegal response code (the id belongs to
> >     COUNTER_RESET_REQUEST). At this point you know that this
> >     connection is
> >     going to be closed, and can immediately start another one (is
> >     *this* the
> >     problem?) that will send a HTTP request with Upgrade header.
> >
> >
> > This is correct. However, you silently assumed that the HTTP Server
> > (either our own Infinispan REST Server or any type of Reverse Proxy
> > we're passing through) will respond with an HTTP message (either 4xx
> > or 5xx) when receiving binary traffic. At this point I know that
> > HAProxy does that, and the same does Envoy (as you told us in the
> > bottom of this email). Infinispan REST server just ignores such a
> > request.
> >
> > So it is safe to assume, that all Reverse Proxies will return an HTTP
> > message when we send a bunch of bytes at it? If yes, than we need to
> > correct the REST implementation (that should not be too hard) and kick
> > the Single Port in, when a Hotrod client receives a HTTP message back
> > when sending PING. But then, if some Reverse Proxy between the server
> > and client does something different (ignoring such a request as our
> > Infinispan REST server does now, or simply refuse a connection, or
> > anything else) we won't be able to upgrade the connection.
>
> That's a valid point - the spec says that it SHOULD [1] respond with 400
> but it is not 100% (buggy proxies are to be expected on the internet).
> We should probably correct the REST server...
>

Thanks for double checking. Yes, I believe we should. Let me test it a
little bit more and create proper JIRAs.


>
> [1] https://tools.ietf.org/html/rfc7230#section-3.1.1
>
> >
> > My proposal is to set the Single Port support on the client, so that
> > the client starts the communication with HTTP message (and not the
> > Hotrod PING). Doing it this way, allows us to forget about all those
> > crazy situations with Reverse Proxies. The key point is that we never
> > throw raw bytes at them. In my opinion this can save us a lot of
> headache.
>
> I am starting to think that we really should start the communication
> with HTTP message, and this shouldn't be a separate config property
> (single-port) but based on Hot Rod version.
>

I also through about this but finally, I rejected the idea. The main
reasoning behind is this:
- We mess up with our default execution flow - hotrod client connecting to
a hotrod server. If there's any bug there we miss during testing, there is
a high chance we get a critical bug in return. And since Infinispan is not
my primary responsibility at the moment, I'm worried that this will cause
troubles and additional pressure to the team.
- We perform additional round trip when initiating a connection (as I
explained before in this email).
- The default server configuration would be more complicated (especially
the endpoint configuration).
- The final argument (probably the least important) is that we don't
support Websockets and Memcached in Single Port. So the configuration
wouldn't be symmetric. It's probably a nitpick, but I don't like it.


> >
> > So, to be honest, I can implement it whichever way you prefer. My
> > personal feeling is that an additional setting on the Hotrod client is
> > much safer bet (at least for now).
> >
> > @Tristan, @Ryan, I think you guys also have some experience in this
> > matter. I would be very interested in hearing your opinion as well.
> >
> >
> >     > I also realized, there's one more moving bit - TCP Keepalive.
> >     Luckily,
> >     > we can control this setting over configuration in our
> >     standalone.xml.
> >     > However, it is perfectly legal what I've seen in Netty (do not
> >     respond
> >     > and keep the connection alive assuming that TCP Keepalive is set
> >     to true).
> >     >
> >     > The more I think about this, the more I'm convinced that the Single
> >     > Port support should be explicitly set in the client (or inferred
> >     from
> >     > the configuration). I do not know how Nginx, Linkerd or Envoy
> >     behaves
> >     > in situation when they expect HTTP and get a stream of bytes.
> >     Relying
> >     > on this partially unknown behavior for doing our upgrade procedure
> >     > doesn't seem right to me.
> >
> >     FYI Envoy does the same, send 400 and terminate the connection.
> >
> >
> > Ok, so it behaves the same as HA Proxy.
> >
> >
> >     >
> >     > Just in case you're worried about the additional logic on the
> >     client
> >     > side - it's super small. Really, only 13 lines including
> >     brackets ;)
> >     >
> >
> https://github.com/infinispan/infinispan/pull/6133/files#diff-684a10c939f31fcfef0f5f48d469393aR618
> >
> >     I am not worried about any logic in the client code, I am worried
> >     about
> >     logic between chair and keyboard.
> >
> >
> > Ouch! That was pretty rude, Radim. Words like that make me feel very
> > uncomfortable and actually offend me. I would like to ask you to stick
> > to the technical aspect of this thread and do not go personal.
> >
> > As we've known each other for a pretty long time, I will pretend I
> > didn't see this and I just read "please have a look what I just wrote,
> > maybe you will reconsider your implementation?".
>
> See the top, please, and my apologies if you took the above as an
> offense. TBH I haven't even checked the implementation, and I am far
> from judging it.
>

All good Radim, no worries! And thanks for all the stuff you're doing!


>
> Radim
>
> >
> >     R.
> >
> >     >
> >     >     Radim
> >     >
> >     >     On 12/10/2018 03:27 PM, Sebastian Laskawiec wrote:
> >     >     > Hey guys,
> >     >     >
> >     >     > During Infinispan F2F, I had a short discussion with
> >     Tristan on
> >     >     Single
> >     >     > Port client-side implementation. Back then, we agreed that
> the
> >     >     client
> >     >     > should always send a Hotrod Ping request and if won't get any
> >     >     response
> >     >     > (or get some HTTP content back), it will try to upgrade to
> the
> >     >     Hotrod
> >     >     > protocol using Single Port.
> >     >     >
> >     >     > I've been playing with the implementation for a while, and
> >     >     > implementing it this way seems a bit "inconvenient" to me.
> >     The Ping
> >     >     > Operation uses 60s timeout, which seems to be a good fit as a
> >     >     default.
> >     >     > Unfortunately, for the Single Port functionality, this means
> >     >     we'd need
> >     >     > to wait 60s until we try to send HTTP request and do an
> >     upgrade.
> >     >     Also,
> >     >     > another problematic part is in Netty's HTTP handlers
> >     >     > (HttpObjectDecoder, HttpServerCodec and
> >     ByteToMessageDecoder). When
> >     >     > those classes fail to decode a message (REST expects HTTP
> >     rather
> >     >     than
> >     >     > a stream of bytes specific to Hotrod protocol), they just
> >     ignore it
> >     >     > and keep the channel in active state (which also makes
> >     sense for
> >     >     > HTTP/1.1 and HTTP/2).
> >     >     >
> >     >     > At this point, my intuition tells, that this doesn't look
> >     right and
> >     >     > seems to be a over-complicated. The whole HTTP upgrade idea
> >     >     seems to
> >     >     > work the other way around, use HTTP as a fallback and then
> >     >     upgrade to
> >     >     > other protocols. Forcing it to work a bit differently
> >     requires some
> >     >     > more effort.
> >     >     >
> >     >     > What if we preserved the Single Port setting in the client
> >     >     > configuration but implemented it as an enum with the
> following
> >     >     values
> >     >     > - true/false/auto. In automatic mode, the client would
> >     check if the
> >     >     > server port is set to 8\d{1,3} (this covers 80, 8080,
> >     8081, 8443
> >     >     and
> >     >     > friends). If that is true, we'd try to follow HTTP Upgrade
> >     >     procedure.
> >     >     > This looks very simple and I think this might actually
> >     work. Please
> >     >     > note, that we need the single port setting in the client
> >     >     configuration
> >     >     > to cover some corner cases like the Single Port exposed on
> >     >     different
> >     >     > port (like 4444) or Hot Rod exposed on port that starts
> >     with 8.
> >     >     >
> >     >     > What do you think about such simplification?
> >     >     >
> >     >     > Thanks,
> >     >     > Sebastian
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     > _______________________________________________
> >     >     > infinispan-dev mailing list
> >     >     > infinispan-dev at lists.jboss.org
> >     <mailto:infinispan-dev at lists.jboss.org>
> >     >     <mailto:infinispan-dev at lists.jboss.org
> >     <mailto:infinispan-dev at lists.jboss.org>>
> >     >     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >     >
> >     >
> >     >     --
> >     >     Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>
> >     <mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>>>
> >     >     JBoss Performance Team
> >     >
> >     >     _______________________________________________
> >     >     infinispan-dev mailing list
> >     > infinispan-dev at lists.jboss.org
> >     <mailto:infinispan-dev at lists.jboss.org>
> >     <mailto:infinispan-dev at lists.jboss.org
> >     <mailto:infinispan-dev at lists.jboss.org>>
> >     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > infinispan-dev mailing list
> >     > infinispan-dev at lists.jboss.org
> >     <mailto:infinispan-dev at lists.jboss.org>
> >     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> >
> >     --
> >     Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
> >     JBoss Performance Team
> >
> >     _______________________________________________
> >     infinispan-dev mailing list
> >     infinispan-dev at lists.jboss.org <mailto:
> infinispan-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20181214/1b2f2367/attachment-0001.html 

From rvansa at redhat.com  Fri Dec 14 08:26:35 2018
From: rvansa at redhat.com (Radim Vansa)
Date: Fri, 14 Dec 2018 14:26:35 +0100
Subject: [infinispan-dev] Single Port Client
In-Reply-To: <CAA9R9O48pdgo395ANXGHXWG1QqYh3MikdjCtt4kahcoAHx_h-g@mail.gmail.com>
References: <CAA9R9O7-Jcw7ss9F7Pz-QHFf2wOjQm+k1FqYmk0-QtpHWwJyVQ@mail.gmail.com>
	<58fd205f-1b17-1cb6-aa7b-af1886de93ca@redhat.com>
	<CAA9R9O6PQ0knCRfHvJ4+eoWaUNJ6mZseuMLkm6J8Qj9n2=wuVA@mail.gmail.com>
	<29902ae4-ca90-7127-2bf0-32ecdddb385a@redhat.com>
	<CAA9R9O4jViSBQZCKfmjZkJHCufN1+Ub-=UBTaJJuAFMSBaWJAw@mail.gmail.com>
	<4dc97786-726a-f14c-11b8-ee6d1f90bfce@redhat.com>
	<CAA9R9O48pdgo395ANXGHXWG1QqYh3MikdjCtt4kahcoAHx_h-g@mail.gmail.com>
Message-ID: <c04b49a3-eb3f-bdcf-a6e8-f3eced2b6933@redhat.com>

On 12/14/2018 11:49 AM, Sebastian Laskawiec wrote:
>
>
> On Thu, Dec 13, 2018 at 4:42 PM Radim Vansa <rvansa at redhat.com 
> <mailto:rvansa at redhat.com>> wrote:
>
>     Hey Sebastian,
>
>     I am sorry that you took my comment about errors between chair and
>     keyboard completely wrong: it was definitely not pointed at you!
>     What I
>     meant is that users will often misconfigure (I've been there many
>     times), and their experience will suffer. Therefore I am not
>     concerned
>     about any 'smart' logic we write (regardless of number of lines of
>     code), but about any complexity required from, or offered to the
>     users.
>
>
> No problem, Radim. I was a little but surprised by that "left jab" 
> coming from nowhere ;) Emails are such a bad media of communication 
> when it comes to situations like this. In normal F2F communication 
> that would never happen. I'm also sorry for all the confusion...
>
> This actually made me thinking, maybe it's the right time to do a 
> small 15 min meeting to discuss this F2F? @Tristan, @Ryan, @Galder - 
> would you also be interested? I'll prepare some slides to show you the 
> main pain points.
>
>
>     Rest of the comments inline...
>
>     On 12/13/2018 02:45 PM, Sebastian Laskawiec wrote:
>     >
>     >
>     > On Thu, Dec 13, 2018 at 10:23 AM Radim Vansa <rvansa at redhat.com
>     <mailto:rvansa at redhat.com>
>     > <mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>>> wrote:
>     >
>     >? ? ?On 12/12/2018 03:30 PM, Sebastian Laskawiec wrote:
>     >? ? ?> On Tue, Dec 11, 2018 at 11:13 AM Radim Vansa
>     <rvansa at redhat.com <mailto:rvansa at redhat.com>
>     >? ? ?<mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>>
>     >? ? ?> <mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>
>     <mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>>>> wrote:
>     >? ? ?>
>     >? ? ?>? ? ?I dislike having any logic based on the port number in
>     some
>     >? ? ?range;
>     >? ? ?>? ? ?it's
>     >? ? ?>? ? ?not common that behaviour would change if you set port
>     to 9xxx
>     >? ? ?>? ? ?instead
>     >? ? ?>? ? ?of 8xxx.
>     >? ? ?>
>     >? ? ?>
>     >? ? ?> That's not a problem with my approach, since you can always
>     >? ? ?manually
>     >? ? ?> turn the setting off or on. Here's how you do it:
>     >? ? ?> ConfigurationBuilder cb = ...
>     >? ? ?> cb.singlePort(SinglePortMode.ENABLED); // other options:
>     >? ? ?DISABLED and AUTO
>     >
>     >? ? ?Adding config options is just a way to avoid solving problems :)
>     >? ? ?Remember the famous quote: "Less knobs!"
>     >
>     >
>     > It depends on the problem in my opinion. I always preferred to have
>     > more configuration options with good defaults.
>     >
>     >
>     >? ? ?>
>     >? ? ?>
>     >? ? ?>? ? ?Is there an (up-to-date) design doc?
>     >? ? ?>
>     >? ? ?>
>     >? ? ?> No, this is just a proposal. I was hoping that you guys
>     like it and
>     >? ? ?> then, with some thumbs up, I could update the design doc.
>     >? ? ?>
>     >? ? ?> Here's the most up-to-date version in case you were
>     looking for it:
>     >? ? ?>
>     >
>     https://github.com/infinispan/infinispan-designs/blob/master/Single_port.adoc
>     >? ? ?>
>     >? ? ?>
>     >? ? ?>? ? ?I don't fully follow, but if there's a problem in the HTTP
>     >? ? ?>? ? ?handlers you
>     >? ? ?>? ? ?can add a PING-detecting handler below...?
>     >? ? ?>
>     >? ? ?>
>     >? ? ?> Thanks for the hint Radim!
>     >? ? ?>
>     >? ? ?> Inspired by your idea I went ahead and checked how
>     OpenShift Router
>     >? ? ?> behaves. It turns out that it responds HTTP 400 if you
>     throw Hotrod
>     >? ? ?> bytes at it and then drops the connection.
>     >
>     >? ? ?I understand that the reason to have Hot Rod PING sent as
>     the first
>     >? ? ?operation is to make sure that a new client that tries to
>     connect
>     >? ? ?to old
>     >? ? ?server won't confuse the server, is that correct? Or is there
>     >? ? ?anything else?
>     >
>     >
>     > Not only. We (Tristan and I when we were discussing it) wanted to
>     > introduce the smallest possible hit on a default scenario - a
>     Hotrod
>     > client connecting to Infinispan without Single Port. If we mess up
>     > this scenario, we might quickly get into all sorts of problem
>     > (including performance).
>     >
>     >
>     >? ? ?I'll assume that a new server will handle both Hot Rod PING
>     and HTTP
>     >? ? ?request correctly without any prelude, and old one will be
>     ok with
>     >? ? ?Hot
>     >? ? ?Rod PING only. I don't really understand the:
>     >
>     >
>     > I'm not sure if I follow. The Single Port functionality for non-TLS
>     > scenario requires only REST interface. Hotrod is optional. We
>     upgrade
>     > to Hotrod using HTTP/1.1 Upgrade procedure (see RFC 7230 [1]). This
>     > essentially means, that you need to send an HTTP request in
>     order to
>     > upgrade to another protocol (such as Hotrod) and reuse the same TCP
>     > connection.
>
>     Okay, then my assumption was incorrect. That means that single-port
>     server and non-single-port server are incompatible because neither
>     can
>     accept other's initial request :-/
>
>     It seems that Hot Rod and HTTP communication is easily
>     distinguishable
>     with first few bytes: could we enhance single-port to be able to
>     handle
>     Hot Rod PING immediately without the HTTP Upgrade to accommodate
>     older
>     clients? Then we could run single-port all the time and everyone wins.
>
>
> Yes, that's absolutely doable, but it doesn't solve the problem, 
> because there might be some Reverse Proxies on the way (such as an OCP 
> Router, Nginx or anything else). Those proxies might mess up with our 
> upgrade flow (as you mentioned below, there can be buggy proxies on 
> the way). The main problem is that we don't know (we can assume but we 
> are not 100% certain), how the Reverse Proxy will behave if we throw 
> binary protocol at it.

Handling Hot Rod on single port in the first case would be there to 
allow old clients connecting to new server. If you point an old client 
to some proxy instead of Hot Rod server, you're out of luck anyway.

>
> Also, if we always start with Single Port turned on, we'll add 
> additional round trip (send HTTP with upgrade request, wait for 
> response, then switch to Hotrod). This adds some delay and I'm not 
> sure we should do it. If we wanted to consider this, I would need to 
> get Tristan's "green stamp" on it. But I have serious doubts

We don't need extra roundtrip. Client sends HTTP Upgrade: Hot Rod, 
server responds with 101 Switching protocols and immediately follows 
with Hot Rod Ping response. The client will expect that. Any extra 
parameters we currently send in PING could be added to the initial HTTP 
Upgrade request as extra headers. We start every connection with PING 
anyway so this would not add any latency.

>
>     Btw., I assume that we can't handle both TLS and non-TLS
>     connections on
>     same port either, is that correct? Usually webservers can't be
>     configured to handle both HTTP and HTTPS on the same port - is
>     there any
>     difference here?
>
>
> The encrypted use case is soooo much easier. The protocol negotiation 
> happen during TLS handshake. Once it's finished and connection is 
> established (so after the handshake is done), you already know about 
> the communication protocol you will be using. If we wanted to support 
> only encrypted use cases, the implementation would in 10-20 lines of code.
>
> Frankly, I expect people to be using unencrypted use cases when 
> developing features and encrypted use cases on production. That's my 
> gut feeling how this feature will be used.

I had rather the use case when you have a non-encrypted *and* encrypted 
service exposed on the *same* port. Yes, ALPN can do a lot for you for free.

>
>     >
>     > So as you can see, the Single Port can not speak both protocols,
>     HTTP
>     > and Hotrod, at the same time. It requires sending an HTTP
>     request with
>     > proper header, and then upgrading to Hotrod. The reason it has been
>     > implemented this way is to support Reverse Proxies (like HAProxy in
>     > the OpenShift Router, but of course there are more of them). As I
>     > mentioned in my last email, the HA proxy immediately responds with
>     > HTTP 400 if you throw binary payload at it. That's why we need to
>     > follow the HTTP upgrade procedure - to get through it.
>     >
>     > [1]
>     >
>     https://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7230.html#header.upgrade
>     >
>     >
>     >? ? ??> implementing it this way seems a bit "inconvenient" to
>     me. The Ping
>     >? ? ??> Operation uses 60s timeout, which seems to be a good fit as a
>     >? ? ?default.
>     >? ? ??> Unfortunately, for the Single Port functionality, this means
>     >? ? ?we'd need
>     >? ? ??> to wait 60s until we try to send HTTP request and do an
>     upgrade
>     >
>     >? ? ?why would you wait for 60 seconds? If the other end is
>     Infinispan
>     >? ? ?server
>     >? ? ?(old or new), you just send HR PING and you're done, server will
>     >? ? ?proceed
>     >? ? ?correctly. If the other server is a router, you'll get a
>     response
>     >? ? ?starting with 'HTTP': in Hot Rod protocol that would be
>     parsed as
>     >? ? ?opCode
>     >? ? ?0x54 which is illegal response code (the id belongs to
>     >? ? ?COUNTER_RESET_REQUEST). At this point you know that this
>     >? ? ?connection is
>     >? ? ?going to be closed, and can immediately start another one (is
>     >? ? ?*this* the
>     >? ? ?problem?) that will send a HTTP request with Upgrade header.
>     >
>     >
>     > This is correct. However, you silently assumed that the HTTP Server
>     > (either our own Infinispan REST Server or any type of Reverse Proxy
>     > we're passing through) will respond with an HTTP message (either
>     4xx
>     > or 5xx) when receiving binary traffic. At this point I know that
>     > HAProxy does that, and the same does Envoy (as you told us in the
>     > bottom of this email). Infinispan REST server just ignores such a
>     > request.
>     >
>     > So it is safe to assume, that all Reverse Proxies will return an
>     HTTP
>     > message when we send a bunch of bytes at it? If yes, than we
>     need to
>     > correct the REST implementation (that should not be too hard)
>     and kick
>     > the Single Port in, when a Hotrod client receives a HTTP message
>     back
>     > when sending PING. But then, if some Reverse Proxy between the
>     server
>     > and client does something different (ignoring such a request as our
>     > Infinispan REST server does now, or simply refuse a connection, or
>     > anything else) we won't be able to upgrade the connection.
>
>     That's a valid point - the spec says that it SHOULD [1] respond
>     with 400
>     but it is not 100% (buggy proxies are to be expected on the
>     internet).
>     We should probably correct the REST server...
>
>
> Thanks for double checking. Yes, I believe we should. Let me test it a 
> little bit more and create proper JIRAs.
>
>
>     [1] https://tools.ietf.org/html/rfc7230#section-3.1.1
>
>     >
>     > My proposal is to set the Single Port support on the client, so
>     that
>     > the client starts the communication with HTTP message (and not the
>     > Hotrod PING). Doing it this way, allows us to forget about all
>     those
>     > crazy situations with Reverse Proxies. The key point is that we
>     never
>     > throw raw bytes at them. In my opinion this can save us a lot of
>     headache.
>
>     I am starting to think that we really should start the communication
>     with HTTP message, and this shouldn't be a separate config property
>     (single-port) but based on Hot Rod version.
>
>
> I also through about this but finally, I rejected the idea. The main 
> reasoning behind is this:
> - We mess up with our default execution flow - hotrod client 
> connecting to a hotrod server. If there's any bug there we miss during 
> testing, there is a high chance we get a critical bug in return. And 
> since Infinispan is not my primary responsibility at the moment, I'm 
> worried that this will cause troubles and additional pressure to the team.

1) old client connecting to new server (without proxy) would work, since 
single port would support Hot-Rod-prior-knowledge.
2) old client connecting through proxy is already screwed
3) new client connecting to old server must already set the protocol 
version manually (no change)
4) new client connecting to new server would fly nicely (just a few more 
bytes sent, but no latency), through proxy or not

> - We perform additional round trip when initiating a connection (as I 
> explained before in this email).

Not necessary, explained.

> - The default server configuration would be more complicated 
> (especially the endpoint configuration).

I would think that with removing the options it would actually become 
*less* complicated. Since we're working on ServerNG, the configuration 
could actually declare that on one place, something like:

<single-port-connector socket-binding="foo" security-realm="..." 
cache-container="clustered" >

I admit this needs to list all the use cases but the above is as complex 
as declaring Hot Rod-only connector and involves them all.

> - The final argument (probably the least important) is that we don't 
> support Websockets and Memcached in Single Port. So the configuration 
> wouldn't be symmetric. It's probably a nitpick, but I don't like it.

Websockets are dropped. Memcached... the request starts with 0x80 so 
it's distinguishable to our 0xA0 and HTTP's 'H' = 0x54 - let's put it 
under the umbrella, too.

Radim

>
>
>     >
>     > So, to be honest, I can implement it whichever way you prefer. My
>     > personal feeling is that an additional setting on the Hotrod
>     client is
>     > much safer bet (at least for now).
>     >
>     > @Tristan, @Ryan, I think you guys also have some experience in this
>     > matter. I would be very interested in hearing your opinion as well.
>     >
>     >
>     >? ? ?> I also realized, there's one more moving bit - TCP Keepalive.
>     >? ? ?Luckily,
>     >? ? ?> we can control this setting over configuration in our
>     >? ? ?standalone.xml.
>     >? ? ?> However, it is perfectly legal what I've seen in Netty (do not
>     >? ? ?respond
>     >? ? ?> and keep the connection alive assuming that TCP Keepalive
>     is set
>     >? ? ?to true).
>     >? ? ?>
>     >? ? ?> The more I think about this, the more I'm convinced that
>     the Single
>     >? ? ?> Port support should be explicitly set in the client (or
>     inferred
>     >? ? ?from
>     >? ? ?> the configuration). I do not know how Nginx, Linkerd or Envoy
>     >? ? ?behaves
>     >? ? ?> in situation when they expect HTTP and get a stream of bytes.
>     >? ? ?Relying
>     >? ? ?> on this partially unknown behavior for doing our upgrade
>     procedure
>     >? ? ?> doesn't seem right to me.
>     >
>     >? ? ?FYI Envoy does the same, send 400 and terminate the connection.
>     >
>     >
>     > Ok, so it behaves the same as HA Proxy.
>     >
>     >
>     >? ? ?>
>     >? ? ?> Just in case you're worried about the additional logic on the
>     >? ? ?client
>     >? ? ?> side - it's super small. Really, only 13 lines including
>     >? ? ?brackets ;)
>     >? ? ?>
>     >
>     https://github.com/infinispan/infinispan/pull/6133/files#diff-684a10c939f31fcfef0f5f48d469393aR618
>     >
>     >? ? ?I am not worried about any logic in the client code, I am
>     worried
>     >? ? ?about
>     >? ? ?logic between chair and keyboard.
>     >
>     >
>     > Ouch! That was pretty rude, Radim. Words like that make me feel
>     very
>     > uncomfortable and actually offend me. I would like to ask you to
>     stick
>     > to the technical aspect of this thread and do not go personal.
>     >
>     > As we've known each other for a pretty long time, I will pretend I
>     > didn't see this and I just read "please have a look what I just
>     wrote,
>     > maybe you will reconsider your implementation?".
>
>     See the top, please, and my apologies if you took the above as an
>     offense. TBH I haven't even checked the implementation, and I am far
>     from judging it.
>
>
> All good Radim, no worries! And thanks for all the stuff you're doing!
>
>
>     Radim
>
>     >
>     >? ? ?R.
>     >
>     >? ? ?>
>     >? ? ?>? ? ?Radim
>     >? ? ?>
>     >? ? ?>? ? ?On 12/10/2018 03:27 PM, Sebastian Laskawiec wrote:
>     >? ? ?>? ? ?> Hey guys,
>     >? ? ?>? ? ?>
>     >? ? ?>? ? ?> During Infinispan F2F, I had a short discussion with
>     >? ? ?Tristan on
>     >? ? ?>? ? ?Single
>     >? ? ?>? ? ?> Port client-side implementation. Back then, we
>     agreed that the
>     >? ? ?>? ? ?client
>     >? ? ?>? ? ?> should always send a Hotrod Ping request and if
>     won't get any
>     >? ? ?>? ? ?response
>     >? ? ?>? ? ?> (or get some HTTP content back), it will try to
>     upgrade to the
>     >? ? ?>? ? ?Hotrod
>     >? ? ?>? ? ?> protocol using Single Port.
>     >? ? ?>? ? ?>
>     >? ? ?>? ? ?> I've been playing with the implementation for a
>     while, and
>     >? ? ?>? ? ?> implementing it this way seems a bit "inconvenient"
>     to me.
>     >? ? ?The Ping
>     >? ? ?>? ? ?> Operation uses 60s timeout, which seems to be a good
>     fit as a
>     >? ? ?>? ? ?default.
>     >? ? ?>? ? ?> Unfortunately, for the Single Port functionality,
>     this means
>     >? ? ?>? ? ?we'd need
>     >? ? ?>? ? ?> to wait 60s until we try to send HTTP request and do an
>     >? ? ?upgrade.
>     >? ? ?>? ? ?Also,
>     >? ? ?>? ? ?> another problematic part is in Netty's HTTP handlers
>     >? ? ?>? ? ?> (HttpObjectDecoder, HttpServerCodec and
>     >? ? ?ByteToMessageDecoder). When
>     >? ? ?>? ? ?> those classes fail to decode a message (REST expects
>     HTTP
>     >? ? ?rather
>     >? ? ?>? ? ?than
>     >? ? ?>? ? ?> a stream of bytes specific to Hotrod protocol), they
>     just
>     >? ? ?ignore it
>     >? ? ?>? ? ?> and keep the channel in active state (which also makes
>     >? ? ?sense for
>     >? ? ?>? ? ?> HTTP/1.1 and HTTP/2).
>     >? ? ?>? ? ?>
>     >? ? ?>? ? ?> At this point, my intuition tells, that this doesn't
>     look
>     >? ? ?right and
>     >? ? ?>? ? ?> seems to be a over-complicated. The whole HTTP
>     upgrade idea
>     >? ? ?>? ? ?seems to
>     >? ? ?>? ? ?> work the other way around, use HTTP as a fallback
>     and then
>     >? ? ?>? ? ?upgrade to
>     >? ? ?>? ? ?> other protocols. Forcing it to work a bit differently
>     >? ? ?requires some
>     >? ? ?>? ? ?> more effort.
>     >? ? ?>? ? ?>
>     >? ? ?>? ? ?> What if we preserved the Single Port setting in the
>     client
>     >? ? ?>? ? ?> configuration but implemented it as an enum with the
>     following
>     >? ? ?>? ? ?values
>     >? ? ?>? ? ?> - true/false/auto. In automatic mode, the client would
>     >? ? ?check if the
>     >? ? ?>? ? ?> server port is set to 8\d{1,3}?(this covers 80, 8080,
>     >? ? ?8081, 8443
>     >? ? ?>? ? ?and
>     >? ? ?>? ? ?> friends). If that is true, we'd try to follow HTTP
>     Upgrade
>     >? ? ?>? ? ?procedure.
>     >? ? ?>? ? ?> This looks very simple and I think this might actually
>     >? ? ?work. Please
>     >? ? ?>? ? ?> note, that we need the single port setting in the client
>     >? ? ?>? ? ?configuration
>     >? ? ?>? ? ?> to cover some corner cases like the Single Port
>     exposed on
>     >? ? ?>? ? ?different
>     >? ? ?>? ? ?> port (like 4444) or Hot Rod exposed on port that starts
>     >? ? ?with 8.
>     >? ? ?>? ? ?>
>     >? ? ?>? ? ?> What do you think about such simplification?
>     >? ? ?>? ? ?>
>     >? ? ?>? ? ?> Thanks,
>     >? ? ?>? ? ?> Sebastian
>     >? ? ?>? ? ?>
>     >? ? ?>? ? ?>
>     >? ? ?>? ? ?>
>     >? ? ?>? ? ?>
>     >? ? ?>? ? ?> _______________________________________________
>     >? ? ?>? ? ?> infinispan-dev mailing list
>     >? ? ?>? ? ?> infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>
>     >? ? ?<mailto:infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>>
>     >? ? ?>? ? ?<mailto:infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>
>     >? ? ?<mailto:infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>>>
>     >? ? ?>? ? ?> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     >? ? ?>
>     >? ? ?>
>     >? ? ?>? ? ?--
>     >? ? ?>? ? ?Radim Vansa <rvansa at redhat.com
>     <mailto:rvansa at redhat.com> <mailto:rvansa at redhat.com
>     <mailto:rvansa at redhat.com>>
>     >? ? ?<mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>
>     <mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>>>>
>     >? ? ?>? ? ?JBoss Performance Team
>     >? ? ?>
>     >? ? ?> ?_______________________________________________
>     >? ? ?>? ? ?infinispan-dev mailing list
>     >? ? ?> infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>
>     >? ? ?<mailto:infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>>
>     >? ? ?<mailto:infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>
>     >? ? ?<mailto:infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>>>
>     >? ? ?> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     >? ? ?>
>     >? ? ?>
>     >? ? ?>
>     >? ? ?> _______________________________________________
>     >? ? ?> infinispan-dev mailing list
>     >? ? ?> infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>
>     >? ? ?<mailto:infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>>
>     >? ? ?> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     >
>     >
>     >? ? ?--
>     >? ? ?Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>
>     <mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>>>
>     >? ? ?JBoss Performance Team
>     >
>     >? ? ?_______________________________________________
>     >? ? ?infinispan-dev mailing list
>     > infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>
>     <mailto:infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>>
>     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     >
>     >
>     >
>     > _______________________________________________
>     > infinispan-dev mailing list
>     > infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>     -- 
>     Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
>     JBoss Performance Team
>
>     _______________________________________________
>     infinispan-dev mailing list
>     infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From rvansa at redhat.com  Fri Dec 14 08:43:31 2018
From: rvansa at redhat.com (Radim Vansa)
Date: Fri, 14 Dec 2018 14:43:31 +0100
Subject: [infinispan-dev] Partial updates in 2LC
In-Reply-To: <CAAcPREuX8fGowPaPUv21h13jE=4BmtNKW0c2yQ_hhBUptuPX2A@mail.gmail.com>
References: <CAAcPREsspU-vb2RY524qEm0FYVF7fCh-uKMhx3j9BtRYncu43A@mail.gmail.com>
	<CAAcPREuX8fGowPaPUv21h13jE=4BmtNKW0c2yQ_hhBUptuPX2A@mail.gmail.com>
Message-ID: <74a0a737-9d79-5b5a-13d8-c1f9e7c7691e@redhat.com>

You're right, it would be wiser for the Sync to let the exception be 
propagated. I can't recall why I've caught the exception terminally.

About CorrectnessTestCase - this is a stress test, and as such we're not 
running it by default. TBH it's been a while since I've last started 
that... It also has some parameters that I used to tune manually 
(commenting certain parts), such as running evictAll which dramatically 
lowers the likelihood of other events to happen.

Radim

On 12/14/2018 10:08 AM, Galder Zamarreno wrote:
> Forgot to point out, here is where Sync logs the exception:
> https://github.com/infinispan/infinispan/blob/master/hibernate/cache-v53/src/main/java/org/infinispan/hibernate/cache/v53/impl/Sync.java#L78
>
> On Fri, Dec 14, 2018 at 10:05 AM Galder Zamarreno <galder at redhat.com 
> <mailto:galder at redhat.com>> wrote:
>
>     Hey Radim,
>
>     We've had some chats in the past where we discussed the behaviour
>     of non-tx 2LC and partial updates. I've wrote a couple of tests
>     [1] to see how things behave:
>
>     For a repl read-write, entity cache, if the failure happens on the
>     async FutureUpdate call, that's fine because the Tombstone has
>     already been sent and the cache won't return anything.
>
>     If the failure happens when the Tombstone is sent, we seem to have
>     a problem because it results in stale data in the node that failed
>     to apply the Tombstone. The FutureUpdate that comes after the
>     Tombstone cannot apply because it doesn't find the Tombstone.
>
>     Sync logs any errors but does not propagate them [2]. Is there any
>     reason for not rethrowing the exception? I tried to rethrow it and
>     the JDBC transaction rolls back, which is not too bad cos at least
>     that way both nodes contain the last committed data.
>
>     As a side note, the CorrectnessTestCase subclasses are not running
>     by default, we should change that.
>
>     Cheers,
>     Galder
>
>     [1]
>     https://github.com/galderz/infinispan/commit/2934e0b3e8ab9af5fb1471c5fdbb0716e5a11c31
>     [2]
>     https://github.com/infinispan/infinispan/blob/master/hibernate/cache-v53/src/main/java/org/infinispan/hibernate/cache/v53/impl/Sync.java
>

-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From postmaster at lists.jboss.org  Mon Dec 24 06:45:21 2018
From: postmaster at lists.jboss.org (MAILER-DAEMON)
Date: Mon, 24 Dec 2018 19:45:21 +0800
Subject: [infinispan-dev] Returned mail: Data format error
Message-ID: <201812241142.wBOBg8b1020416@lists01.dmz-a.mwc.hst.phx2.redhat.com>

The original message was received at Mon, 24 Dec 2018 19:45:21 +0800
from lists.jboss.org [170.234.174.38]

----- The following addresses had permanent fatal errors -----
<infinispan-dev at lists.jboss.org>

----- Transcript of session follows -----
  while talking to lists.jboss.org.:
>>> MAIL From:"MAILER-DAEMON" <postmaster at lists.jboss.org>
<<< 501 "MAILER-DAEMON" <postmaster at lists.jboss.org>... Refused



-------------- next part --------------
A non-text attachment was scrubbed...
Name: document.pif
Type: application/octet-stream
Size: 46020 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20181224/81d8a9a4/attachment-0001.obj