RE: Get rid of @Nullable and @NotNull
Classification: Public +1 for using @Nullable. @Nullable is not panacea, but much better than nothing. It's clear indication that you should check the marked object for null before using. There is advantage in using @Nullable than @NotNull - Idea or any tool like findbugs shows you potential NPE places - where you forgot to check for null object marked @Nullable, otherwise if you use only @NotNull it's much harder to see NPE problems as, I believe, always will be too many noise - places where developers just forgot to place annotation. And another arguable point is statistics, in my experience there are more objects that not null by nature than nullable. So if you should mark only all @NotNull objects, you will need to place much more annotations than if mark only @Nullable objects. Kind regards, Sergey Kosarev -Original Message- From: Ivan Pavlukhin [mailto:vololo...@gmail.com] Sent: 27 March 2020 13:28 To: dev Subject: Re: Get rid of @Nullable and @NotNull Here is my opinion. As we do not have a common practice to use @Nullable and @NotNull annotations everywhere I would consider every not annotated item as effectively @Nullable. @NotNull seems a useful annotation for me, sometimes it is a really good thing to assume that something cannot be null instead of doing explicit null check everywhere. Best regards, Ivan Pavlukhin пт, 27 мар. 2020 г. в 13:05, Denis Garus : > > Hi! > I'm not sure that @Nullable can really fix the NPE problem. > Currently, we have @Nullable annotation and NPE simultaneously. > The best way to avoid NPE is by using a null object pattern. > I agree we shouldn't rely on @Nullable. > > > пт, 27 мар. 2020 г. в 12:58, Sergey Antonov : > > > I disagree. > > > > Intellij idea IDE has a static code analysis, which uses that > > annotation too. IDE highlights possible problems. It helps to make > > our code more stable and bugless. > > > > пт, 27 мар. 2020 г. в 12:06, Pavel Tupitsyn : > > > > > I disagree, it would be a step back. > > > > > > > What's the reason for using it? > > > Null was a billion dollar mistake [1]. > > > NullPointerExceptions happen quite a lot in Ignite, and > > > annotations > > provide > > > some clues to avoid those. > > > > > > [1] > > > https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions > > > > > > On Fri, Mar 27, 2020 at 10:58 AM Anton Vinogradov wrote: > > > > > > > Folks, > > > > > > > > Found we still use @Nullable annotation. > > > > > > > > What's the reason for using it? > > > > Everything is Object and Nullable :) > > > > > > > > How about get rid of @Nullable usages and restrict its usage by > > > checkstyle > > > > plugin? > > > > > > > > BTW, We already "do not use @NotNull annotation" (с) Coding > > > > Guidelines > > > [1] > > > > which may have some cense in contrast to @Nullable. > > > > But I see a lot of usages at code. > > > > > > > > How about to get rid of @NotNull too and to add such check to > > checkstyle > > > > plugin too? > > > > > > > > [1] > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines > > #CodingGuidelines-@Annotations > > > > > > > > > > > > > -- > > BR, Sergey Antonov > > --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.
RE: deadlock in system pool on meta update
Classification: Public
Hi Sergey,
Ticket is here https://issues.apache.org/jira/browse/IGNITE-12793
I will try to make reproducer in the coming days.
Kind regards,
Sergey Kosarev
-Original Message-
From: Sergey Chugunov [mailto:sergey.chugu...@gmail.com]
Sent: 17 March 2020 09:45
To: dev
Subject: Re: deadlock in system pool on meta update
Hello Sergey,
Your analysis looks valid to me, we definitely need to investigate this
deadlock and find out how to fix it.
Could you create a ticket and write a test that reproduces the issue with
sufficient probability?
Thanks!
On Mon, Mar 16, 2020 at 8:22 PM Sergey-A Kosarev
wrote:
> Classification: Public
>
> Hi,
> I've recently tried to apply Ilya's idea (
> https://issues.apache.org/jira/browse/IGNITE-12663) of minimizing
> thread pools and tried to set system pool to 3 in my own tests.
> It caused deadlock on a client node and I think it can happen not only
> on such small pool values.
>
> Details are following:
> I'm not using persistence currently (if it matters).
> On the client note I use ignite compute to call a job on every server
> node (there are 3 server nodes in the tests).
>
> Then I've found in logs:
>
> [10:55:21] : [Step 1/1] [2020-03-13 10:55:21,773] {
> grid-timeout-worker-#8} [WARN] [o.a.i.i.IgniteKernal] - Possible
> thread pool starvation detected (no task completed in last 3ms, is
> system thread pool size large enough?)
> [10:55:21] : [Step 1/1] ^-- System thread pool [active=3, idle=0,
> qSize=9]
>
>
> I see in threaddumps that all 3 system pool workers do the same -
> processing of job responses:
>
> "sys-#26" #605 daemon prio=5 os_prio=0 tid=0x64a0a800
> nid=0x1f34 waiting on condition [0x7b91d000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:749)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$1.metadata(CacheObjectBinaryProcessorImpl.java:250)
> at
> org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1169)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2005)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:285)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:184)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1797)
> at
> org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:2160)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2091)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1914)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1982)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:702)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:887)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1797)
> at
> org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:2160)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2091)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1914)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(Bina
deadlock in system pool on meta update
nseMessage will be received and processed on the client node. But MetadataResponseMessage(GridTopic.TOPIC_METADATA_REQ) is also processing in system pool. (I see that method GridIoManager#processRegularMessage routes it to the System Pool) So it causes deadlock as the Sytem Pool is already full. Will appreciate any feedback on the topic. Am I just shooting to my foot or should I create a ticket for this? Is it correct that both job responses and metadata responses are processing in the System Pool, and if yes then how this case should be handled successfully? I suppose on bigger pool values there is still a chance to get into such a situation, if many concurrent jobs are invoked from the same client node, or is there some golden rule to follow - something like not than (capacity of the system pool - 1) concurrent jobs from the same node should be invoked? Kind regards, Sergey Kosarev --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.
RE: [DISCUSSION] Release Apache Ignite 2.8.0 RC1
Classification: Public There are no RC anymore, I believe. It's now just 2.8.0 (as in Maven Central) Thank you to all involved in the release guys, especially Maxim! Kind regards, Sergey Kosarev -Original Message- From: Ivan Pavlukhin [mailto:vololo...@gmail.com] Sent: 05 March 2020 12:49 To: dev Subject: Re: [DISCUSSION] Release Apache Ignite 2.8.0 RC1 Wow. I impressed that users try out even RC. Best regards, Ivan Pavlukhin чт, 5 мар. 2020 г. в 12:01, Maxim Muzafarov : > > Ivan, > > I think `final steps` is mostly related not to binary\sources itself > but for the announce message. All documentation must be up-to-date > when it occurs. > > But I think you're right that users already using a new version of > Apache Ignite without announcing. We've got some questions\bugs on > user-list already [1] [2]. > > > [1] > http://apache-ignite-users.70518.x6.nabble.com/Ignite-2-8-get-exceptio > n-while-use-batch-insert-in-streaming-mode-td31614.html > [2] > http://apache-ignite-users.70518.x6.nabble.com/Zookeeper-discovery-wit > h-Ignite-2-8-0-class-NoClassDefFound-td31615.html > > On Thu, 5 Mar 2020 at 11:51, Ivan Pavlukhin wrote: > > > > Maxim, > > > > You did the great job! Many thanks for that! > > > > I suppose there is some confusion with terminology. I understand > > that Ignite release process has several final steps. And for example > > binaries can be published before documentation is ready and it is ok > > (I suppose opposite will make no harm as well). My personal > > understanding is that a product version "is considered released" > > once a user can receive and use it tagged with the target version. > > In other words, once it is generally available (GA). And we should > > not force users to check product web sites and other announcement > > channels to check that a package available in the Maven repository > > is valid. For someone it might be just "keeping all dependencies up to > > date". > > > > Best regards, > > Ivan Pavlukhin > > > > чт, 5 мар. 2020 г. в 09:33, Maxim Muzafarov : > > > > > > Ivan, > > > > > > I did something wrong? > > > What should I do to release all effectively? > > > > > > On Thu, 5 Mar 2020 at 08:23, Denis Magda wrote: > > > > > > > > Ivan, > > > > > > > > The release of binaries is one of the final steps. There are > > > > still several steps left before we can consider all the 2.8 release > > > > activities completed: > > > > https://cwiki.apache.org/confluence/display/IGNITE/Release+Proce > > > > ss#ReleaseProcess-6.3.4.Releasedocumentaiononreadme.io > > > > https://cwiki.apache.org/confluence/display/IGNITE/Release+Proce > > > > ss#ReleaseProcess-6.4.Announcerelease > > > > > > > > - > > > > Denis > > > > > > > > > > > > On Wed, Mar 4, 2020 at 7:57 PM Ivan Pavlukhin > > > > wrote: > > > > > > > > > Denis, folks, > > > > > > > > > > As it was already mentioned 2.8 is already in maven [1]. > > > > > Consequently "effectively" released. In my opinion it is not > > > > > correct to consider release in progress. > > > > > > > > > > Agree that 2.8.1 sounds as a proper option here. > > > > > > > > > > [1] > > > > > https://mvnrepository.com/artifact/org.apache.ignite/ignite-co > > > > > re/2.8.0 > > > > > > > > > > Best regards, > > > > > Ivan Pavlukhin > > > > > > > > > > ср, 4 мар. 2020 г. в 17:08, Denis Magda : > > > > > > > > > > > > Dmitriy, > > > > > > > > > > > > Ignite 2.8 will be announced as soon as the documentation is > > > > > > prepared and released. Until then, the release is still considered > > > > > > under progress. > > > > > Here > > > > > > is a dedicated discussion for documentation activities. We > > > > > > should be > > > > > ready > > > > > > soon: > > > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-2 > > > > > -8-documentation-td46008.html > > > > > > > > > > > > Also, I've started a discussion related to our announcement > > > > > > steps. Pleas
RE: Apache Ignite 2.8 RELEASE [Time, Scope, Manager] [I]
Classification: For internal use only Hi, I can confirm. I also see: 404 You do not have enough permissions to access project with internal id: project20 i.e for this link: https://ci.ignite.apache.org/viewLog.html?buildId=5085462=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum=buildResultsDiv Kind regards, Sergey Kosarev -Original Message- From: Pavel Tupitsyn [mailto:ptupit...@apache.org] Sent: 28 February 2020 11:58 To: dev Subject: Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager] Sergey, can't confirm, those links work for me On Thu, Feb 27, 2020 at 11:17 PM Sergey Antonov wrote: > Hello, Maxim! > > All your links to ci.ignite.apache.org/ return 404 http code. It's okay? > > чт, 27 февр. 2020 г. в 19:06, Maxim Muzafarov : > > > Igniters, > > > > > > I've prepared everything to start a vote. > > Are we ready to go on? > > > > > > I have uploaded a release candidate to: > > https://dist.apache.org/repos/dist/dev/ignite/2.8.0-rc1/ > > https://dist.apache.org/repos/dist/dev/ignite/packages_2.8.0-rc1/ > > > > The following staging can be used for testing: > > https://repository.apache.org/content/repositories/orgapacheignite-1 > > 474/ > > > > Tag with name 2.8.0-rc1 created: > > > > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=341b01dfd8 > abf2d9b01d468ad1bb26dfe84ac4f6 > > > > > > TC [Check RC: Licenses, compile, chksum] > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085462= > ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum=build > ResultsDiv > > > > TC [3] Build & Upload Nuget Staging Packages > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085460= > ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages=buildResul > tsDiv > > > > TC [2] Compare w/ Previous Release > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085458= > ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency=build > ResultsDiv > > > > On Wed, 26 Feb 2020 at 22:44, Pavel Tupitsyn > wrote: > > > > > > Maxim, > > > > > > Fixes are in ignite-2.8 now, and builds have passed [1]. > > > I think we can proceed. > > > > > > Thank you and sorry for the broken build. > > > > > > [1] > > > > > > https://ci.ignite.apache.org/buildConfiguration/ApacheIgniteReleaseJav > a8_PrepareVote3BuildNuGetPackages/5083539?buildTab=overview > > > > > > On Wed, Feb 26, 2020 at 8:46 PM Pavel Tupitsyn > > > > > wrote: > > > > > > > I'm running a final check in branch ignite-2.8-dotnet-build-fix, > > should be > > > > done soon. > > > > After that I'll merge the changes into ignite-2.8 (and backport > > > > to master), and we can proceed. > > > > > > > > I had to fix both TC project and the build script. > > > > There were a few regressions introduced by various recent changes. > > > > > > > > > Can you also provide some details - which exactly artefacts > > > > > should > I > > > > check on staging resource after the [1] suite execution? > > > > We are supposed to verify that NuGet packages are valid by > > > > installing > > them > > > > and starting Ignite. > > > > However, we added an automatic check recently: `Run NuGet > verification > > > > script` build step. > > > > So the only thing to check is that new package appears on MyGet > > > > [1] (scroll down to see versions and dates) > > > > > > > > [1] > > > > > > > https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache. > Ignite > > > > > > > > > > > > On Wed, Feb 26, 2020 at 7:42 PM Maxim Muzafarov > > > > > > wrote: > > > > > > > >> Pavel, > > > >> > > > >> > > > >> Thank you for your help. > > > >> Please, let me know when I can proceed with a vote preparation. > > > >> > > > >> > > > >> Can you also provide some details - which exactly artefacts > > > >> should I check on staging resource after the [1] suite execution? > > > >> > > > >> [1] > > > >> > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgniteRel > easeJava8_PrepareVote3BuildNuGetPackages > > > >> > > > >> On Wed, 26 Feb 2020 at 10:46, Pa
RE: [DISCUSSION] Deprecation of obsolete rebalancing functionality
Classification: Public Alexey, then I don't have objections. -Original Message- From: Alexei Scherbakov [mailto:alexey.scherbak...@gmail.com] Sent: 12 February 2020 12:01 To: dev Subject: Re: [DISCUSSION] Deprecation of obsolete rebalancing functionality Sergey, The ticket looks outdated. In fact this is already implemented. ср, 12 февр. 2020 г. в 11:58, Sergey-A Kosarev : > Classification: Public > > Hi, Alexey. > I believe it can't be done until in-memory caches will use baseline > topology [1]. > In our case we are using rebalanceDelay for in-memory caches. > > [1] https://issues.apache.org/jira/browse/IGNITE-8414 > > > Kind regards, > Sergey Kosarev > > -Original Message- > From: Zhenya Stanilovsky [mailto:arzamas...@mail.ru.INVALID] > Sent: 12 February 2020 11:33 > To: dev@ignite.apache.org > Subject: Re: [DISCUSSION] Deprecation of obsolete rebalancing > functionality > > > > I know guys who use this setting (may be erroneously) = MAX_INT for > real rebalance delaying (very small sla) grid without persistence. But > i don`t know further algo, may be if backup nodes become extremely > small they creates the same cluster near it. Can ignite simple disable > rebalance? > > >Folks, > > > >I want to deprecate some obsolete functionality related to rebalancing. > >Details in [1] > > > >Any objections ? > > > >[1] https://issues.apache.org/jira/browse/IGNITE-12662 > > > >-- > > > >Best regards, > >Alexei Scherbakov > > > > > > > > > --- > This e-mail may contain confidential and/or privileged information. If > you are not the intended recipient (or have received this e-mail in > error) please notify the sender immediately and delete this e-mail. > Any unauthorized copying, disclosure or distribution of the material > in this e-mail is strictly forbidden. > > Please refer to https://www.db.com/disclosures for additional EU > corporate and regulatory disclosures and to > http://www.db.com/unitedkingdom/content/privacy.htm for information > about privacy. > -- Best regards, Alexei Scherbakov --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.
RE: [DISCUSSION] Deprecation of obsolete rebalancing functionality
Classification: Public Hi, Alexey. I believe it can't be done until in-memory caches will use baseline topology [1]. In our case we are using rebalanceDelay for in-memory caches. [1] https://issues.apache.org/jira/browse/IGNITE-8414 Kind regards, Sergey Kosarev -Original Message- From: Zhenya Stanilovsky [mailto:arzamas...@mail.ru.INVALID] Sent: 12 February 2020 11:33 To: dev@ignite.apache.org Subject: Re: [DISCUSSION] Deprecation of obsolete rebalancing functionality I know guys who use this setting (may be erroneously) = MAX_INT for real rebalance delaying (very small sla) grid without persistence. But i don`t know further algo, may be if backup nodes become extremely small they creates the same cluster near it. Can ignite simple disable rebalance? >Folks, > >I want to deprecate some obsolete functionality related to rebalancing. >Details in [1] > >Any objections ? > >[1] https://issues.apache.org/jira/browse/IGNITE-12662 > >-- > >Best regards, >Alexei Scherbakov > --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.
RE: Wrong results on Scan queries on REPLICATED caches during rebalance
Classification: Public Hi Ivan, Yes, I have simple reproducer and I've checked on master, unfortunately issue is still actual. -Original Message- From: Ivan Rakov [mailto:ira...@gridgain.com] Sent: 16 January 2020 14:33 To: dev@ignite.apache.org Subject: Re: Wrong results on Scan queries on REPLICATED caches during rebalance Hi Sergey, Just FYI: a similar problem with replicated caches has been fixed in SQL [1]. If you have a reproducer, you may check whether your issue is still actual. [1]: https://issues.apache.org/jira/browse/IGNITE-12482 On Thu, Jan 16, 2020 at 1:51 PM Sergey-A Kosarev wrote: > Classification: Public > Hello, Igniters, > > Recently I've came across a problem with REPLICATED caches, so I've > created an issue: > https://issues.apache.org/jira/browse/IGNITE-12549 > > Please look at this. I believe, it's a bug. > > Not sure I could fix it quickly, feel free to take it if you like. > > And as workaround I think PARTITIONED caches with Integer.MAX_VALUE > backups can be used instead of REPLICATED caches. > > Will be glad for any feedback. > > Kind regards, > Sergey Kosarev > > > > > --- > This e-mail may contain confidential and/or privileged information. If > you are not the intended recipient (or have received this e-mail in > error) please notify the sender immediately and delete this e-mail. > Any unauthorized copying, disclosure or distribution of the material > in this e-mail is strictly forbidden. > > Please refer to https://www.db.com/disclosures for additional EU > corporate and regulatory disclosures and to > http://www.db.com/unitedkingdom/content/privacy.htm for information > about privacy. > -- Best Regards, Ivan Rakov --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.
Wrong results on Scan queries on REPLICATED caches during rebalance
Classification: Public Hello, Igniters, Recently I've came across a problem with REPLICATED caches, so I've created an issue: https://issues.apache.org/jira/browse/IGNITE-12549 Please look at this. I believe, it's a bug. Not sure I could fix it quickly, feel free to take it if you like. And as workaround I think PARTITIONED caches with Integer.MAX_VALUE backups can be used instead of REPLICATED caches. Will be glad for any feedback. Kind regards, Sergey Kosarev --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.
