Comments (62)
Cotton-Ben
commented on July 19, 2024
This build will take place at my Fork of the ISPN 7 repo https://github.com/Cotton-Ben/infinispan
At some point we want to also x-package as net.openhft.collections.jcache.infinispan.DefaultCacheImpl
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
Dmitry, Let's take down Peter's OpenHFT maven central dependency pom
http://central.maven.org/maven2/net/openhft/collections/3.0a/collections-3.0a.pom
and start a "HelloOpenHFT" test at https://github.com/Cotton-Ben/infinispan
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
Dmitry we need to use different maven-settings.xml to build at JPM. This is royal pain. I recommend we just keep 2 copies. Depending where we are, just do a
From $GITHOME/infinispan/
mvn -s maven-settings.xml.jpmc install -DskipTests
mvn -s maven-settings.xml.redhat install -DskipTests
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
Dmitry. FYI.
Thanks Peter. The plan is for Dmitry and I to at first extend VanillaSharedHashMap and groom it into an ISPN7 join via their DataContainer API bridge.
That ExtendedVSHM will be morphed into a fully inter-operable JCACHE operand will
- initially be brokered by the ISPN 7 config (JSR107 <----> VSHMExtendedDataContainer <----> VSHM)
- eventually, possibly, be rendered with ExtendedVSHM directly implementing javax.cache.Cache (in addititon to DataContainer)
On 03/07/2014 11:43 AM, Peter Lawrey wrote:
In the medium term I would see SHM supporting a DataContainer. If a Cache were supported I would do it as a layered class so those who don't need the functionality of a Cache don't incur an overhead.
On 8 Mar 2014 03:35, "Ben Cotton" <[hidden email]> wrote:
Thank you for this insight Mircea ...
Ultimately ... I want the OpenHFT SHM off-heap operand to behave exactly like a JCACHE ... Amenable to being soundly/completely operated upon by any/all parts of ISPN7's Impl of the JSR-107 API .
Musing openly: Won't that (eventually) necessitate me physically implementing javax.cache.Cache ?
> Another way to do it is to have CacheImpl implement the DataContainer only, and then configure Infinispan's JCache implementation to use that custom DataContainer.
I see what you mean. OK, for sure, this sounds much simpler than what I have put on my initial TODO list.
Question: Will doing it this way in any manner suggest that my JSR-107 specific operators are being transitively "brokered" by the ISPN config onto my OpenHFT SHM operand? If possible, I want everything to be direct -- no API bridge.
Thanks again, Mircea.
-Ben and Dmitry
Sent from my iPhone
On 03/07/2014 09:45 AM, Mircea Markus-2 [via Infinispan Developer List] wrote:
Hi Ben,
In the diagram provided, the CacheImpl (your class) extends both from javax.cache.Cache and org.infinispan.container.DataContainer.
The Cache and DataContainer interfaces are quite different and I anticipate an single class implementing both to be hard to follow and potentially not very efficient.
Another way to do it is to have CacheImpl implement the DataContainer only, and then configure Infinispan's JCache implementation to use that custom DataContainer.
On Mar 3, 2014, at 3:46 PM, cotton-ben <[hidden email]> wrote:
Quick Update:
It is my understandng that Peter Lawrey will make available an OpenHFT HC
Alpha Release in Maven Central next weekend. At that time, Dmitry Gordeev
and I will take the OpenHFT dependency tag and proceed to build a branch of
Red Hat's ISPN 7 that will treat net.openhft.collections.SharedHashMap as a
Red Hat Infinispan 7 default impl of a fully JSR-107 interoperable off-heap
javax.cache.Cache ...A diagram of this build effort can be found here:
https://raw.github.com/Cotton-Ben/OpenHFT/master/doc/AdaptingOpenHFT-SHM-as-JCACHE-Impl.jpg
...
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
Dmitry: 2 things
- Let's only do work @ our ISPN7 fork via Peter's official @mavencentral dependency tag (currently 3.0alpha ). It should change w/ release updates frequently (e.g. Peter will have a Beta ready Mar 15th).
- To get a continuously integrated view of Peter's latest commits I strongly recommend you switch to IntelliJ CE (it is free). To do this in Eclipse is extremely unpleasant. BTW, IntelliJ's mvn and git integration knock the socks off Eclipse's capability. Truth is: If you must use Eclipse, keep a separate shell for command line git synchronization with Peter. Here is an old ksh that I used before I made the (necessary!) full switch to IntelliJ:
[email protected]> cat OpenHFTBigBang.ksh
#!/bin/ksh
for k in OpenHFT
do
tput clear
echo "In the beginning, there was only darkness (and a GIT ROOT_DIR)"
sleep 3
cd $HOME/Github
echo ""
rm -fr OpenHFT
echo "And it was said: 'Let there be OpenHFT ...' "
sleep 2
git clone https://github.com/Cotton-Ben/$k.git #Ben's fork
echo "And off to OpenHFT we went...' "
cd OpenHFT
#Treat Peter's repo as our 'upstream' master
git remote add upstream https://github.com/OpenHFT/$k.git
git remote -v #confirm our workspace 2 views: origin(Ben) upstream(Peter)
#at this point we have in our workspace Ben's Fork of Peter's upstream master
#now, pull down into the workspace any of Peter's upstream changes
git pull -u upstream master
#commit those upstream changes
git commit -m 'synch $k upstream changes' .
#git push -u origin master #push the the upstream changes to our Fork origin
for j in TransFIX HugeCollections Java-Thread-Affinity Java-Runtime-Compiler Java-Chronicle Java-Lang
do
echo
echo $j
git clone https://github.com/Cotton-Ben/$j.git #Ben's fork
cd $j
#Treat Peter's repo as our 'upstream' master
git remote add upstream https://github.com/OpenHFT/$j.git
git remote -v #confirm our workspace 2 views: origin(Ben) upstream(Peter)
#at this point we have in our workspace Ben's Fork of Peter's upstream master
#now, pull down into the workspace any of Peter's upstream changes
git pull -u upstream master
#commit those upstream changes
#do work in work
git commit -m 'synch $j upstream changes' .
#git push -u origin master #push the the upstream changes to our Fork origin
cd - #back to $HOME/Github/OpenHFT
done
echo
echo
pwd
echo
echo
mvn clean compile package install -DskipTests
echo "^G"
echo "^G"
sleep 1
tput clear
echo "^G"
echo "^G"
echo "Running OpenHFT Tests in 10 seconds ..."
sleep 10
mvn clean compile package install
cd - #back to $HOME/Github
done
[email protected]>
from hugecollections-old.
ben--cotton
commented on July 19, 2024
We have established the following at my ISPN 7 fork ( https://github.com/Cotton-Ben/infinispan ):
-
Created a new [jcache-off-heap] module and bound it to master ISPN 7 pom.xml -
Within [jcache-off-heap] created a pom.xml that successfully joins OpenHFT 3.0a and ISPN 7.0.0 APIs. -
Created an org.infinispan.jcache.JCacheOffHeapImpl place-holder Class that both extends net.openhft.collections.VanillaSharedHashMap and implements org.infinispan.container.DataContainer -
Created an org.infinispan.jcache.JCacheOffHeapImplTest place-holder that will drive the tests to demonstrate that we have rendered a sound/complete [3]. -
Confirmed that we can build [3][4] from the ISPN 7 master maven invoke.
Before proceeding further, Dmitry and I need to establish from Mircea and RedHat that this module, in this form, will adapt (without concern) into the existing RedHat ISPN 7 root build environment.
Ben D. Cotton III
J.P.Morgan
Liquidity Risk Technology
277 Park Ave Desk 08-GG64
New York, NY 10172-0003
212.622.5010
[email protected]:[email protected]
From: Ben Cotton [mailto:[email protected]]
Sent: Friday, March 07, 2014 2:49 PM
To: OpenHFT/HugeCollections
Subject: Re: [HugeCollections] Adapting OpenHFT SHM as JSR-107 interoperable JCACHE (Off-Heap!) operand (#13)
Dmitry. FYI.
Thanks Peter. The plan is for Dmitry and I to at first extend VanillaSharedHashMap and groom it into an ISPN7 join via their DataContainer API bridge.
That ExtendedVSHM will be morphed into a fully inter-operable JCACHE operand will
- initially be brokered by the ISPN 7 config (JSR107 <----> VSHMExtendedDataContainer <----> VSHM)
- eventually, possibly, be rendered with ExtendedVSHM directly implementing javax.cache.Cache (in addititon to DataContainer)
On 03/07/2014 11:43 AM, Peter Lawrey wrote:
In the medium term I would see SHM supporting a DataContainer. If a Cache were supported I would do it as a layered class so those who don't need the functionality of a Cache don't incur an overhead.
On 8 Mar 2014 03:35, "Ben Cotton" <[hidden email]> wrote:
Thank you for this insight Mircea ...
Ultimately ... I want the OpenHFT SHM off-heap operand to behave exactly like a JCACHE ... Amenable to being soundly/completely operated upon by any/all parts of ISPN7's Impl of the JSR-107 API .
Musing openly: Won't that (eventually) necessitate me physically implementing javax.cache.Cache ?
Another way to do it is to have CacheImpl implement the DataContainer only, and then configure Infinispan's JCache implementation to use that custom DataContainer.
I see what you mean. OK, for sure, this sounds much simpler than what I have put on my initial TODO list.
Question: Will doing it this way in any manner suggest that my JSR-107 specific operators are being transitively "brokered" by the ISPN config onto my OpenHFT SHM operand? If possible, I want everything to be direct -- no API bridge.
Thanks again, Mircea.
-Ben and Dmitry
Sent from my iPhone
On 03/07/2014 09:45 AM, Mircea Markus-2 [via Infinispan Developer List] wrote:
Hi Ben,
In the diagram provided, the CacheImpl (your class) extends both from javax.cache.Cache and org.infinispan.container.DataContainer.
The Cache and DataContainer interfaces are quite different and I anticipate an single class implementing both to be hard to follow and potentially not very efficient.
Another way to do it is to have CacheImpl implement the DataContainer only, and then configure Infinispan's JCache implementation to use that custom DataContainer.
On Mar 3, 2014, at 3:46 PM, cotton-ben <[hidden email]> wrote:
Quick Update:
It is my understandng that Peter Lawrey will make available an OpenHFT HC
Alpha Release in Maven Central next weekend. At that time, Dmitry Gordeev
and I will take the OpenHFT dependency tag and proceed to build a branch of
Red Hat's ISPN 7 that will treat net.openhft.collections.SharedHashMap as a
Red Hat Infinispan 7 default impl of a fully JSR-107 interoperable off-heap
javax.cache.Cache ...
A diagram of this build effort can be found here:
https://raw.github.com/Cotton-Ben/OpenHFT/master/doc/AdaptingOpenHFT-SHM-as-JCACHE-Impl.jpg
...
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-37060687.
This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
upgraded to OpenHFT 3.0b,
stubbed out JCacheOffHeapImpl with 'super.XXX()' invokes onto Peter's VanillaSharedHashMap impl.
TODO: morph get()/peek()/remove() to return RedHat ICE
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
Dmitry,
As per Mircea, I moved [jcache-off-heap] ISPN7 module to new name [off0heap] ISPN7 module. We will (for now) use the org.inifnispan.container.DataContainer API to cross the "Red Hat bridge" to JCACHE. Eventually, I think we might want to build our own "direct bridge" to JCACHE and we ourselves implement javax.cache.Cache ... any way ... here you go.
Please ACK that you can build the full ISPN7 (from my fork) with both from within the bank
mvn -s maven-settings.xml.jpmc clean compile validate package -DskipTests
and
from the public internet
mvn -s maven-settings.xml.redhat clean compile validate package -DskipTests
Also, did you switch to IntelliJ CE 13? Do that, I promise you do that. IntelliJ CE 13 knocks the socks off Eclipse (you'll see).
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
FYI. Attached is dialog with Red Hat's ISPN lead = Mircea Markus. For now Dmitry and I will code this adoption to be coupled to ISPN7 as our lone JCACHE provider. However, it will be loosley coupled -- and at all times coded as such - with the consideration to grow VSHM to potetnailly accommodate any/all JCACHE providers.
Ben, at this stage you already have an JCache implementation backed by the DataContainer, by using the JCache implementation provided by ISPN an configuring Infinispan with the new custom data container.
Thanks Mircea. We now "see it" and are proceeding accordingly. We have removed all ambition to directly implement JCACHE (in any form) from our Fork. (see newly documented goals at https://github.com/Cotton-Ben/infinispan) We have also simply re-named the new module [off-heap].
Thanks for your support. We are in full gear to adapt/test/contribute this Fork. Stay tuned.
configuring Infinispan with the new custom data container
Looking forward to learning from you guys exactly how to do this!
Thanks!
from hugecollections-old.
peter-lawrey
commented on July 19, 2024
A key enhancement to VSHM is the addition of meta data for each entry.
There is none currently however you might find it useful for timestamps
like last updated, or counters like the number of times accessed.
This will be supported by you providing a visitor interface which will be
called with the meta/key/value for different actions.
I believe it might also be useful for supporting caches eg expiry info.
It is intended to help support multimaster replication.
On 12 Mar 2014 03:02, "Ben Cotton" [email protected] wrote:
FYI. Attached is dialog with Red Hat's ISPN lead = Mircea Markus. For now
Dmitry and I will code this adoption to be coupled to ISPN7 as our lone
JCACHE provider. However, it will be loosley coupled -- and at all times
coded as such - with the consideration to grow VSHM to potetnaillyaccommodate any/all JCACHE providers.
Ben, at this stage you already have an JCache implementation backed by the
DataContainer, by using the JCache implementation provided by ISPN an
configuring Infinispan with the new custom data container.Thanks Mircea. We now "see it" and are proceeding accordingly. We have
removed all ambition to directly implement JCACHE (in any form) from our
Fork. (see newly documented goals at
https://github.com/Cotton-Ben/infinispan) We have also simply re-named
the new module [off-heap].Thanks for your support. We are in full gear to adapt/test/contribute this
Fork. Stay tuned.configuring Infinispan with the new custom data container
Looking forward to learning from you guys exactly how to do this!
Thanks!
Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-37313061
.
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
Ø I believe it might also be useful for supporting caches eg expiry info.
+1
Is MetaData already in 3.0c? don’t respond … going there now to check myself.
From: Peter Lawrey [mailto:[email protected]]
Sent: Tuesday, March 11, 2014 4:04 PM
To: OpenHFT/HugeCollections
Cc: Ben Cotton
Subject: Re: [HugeCollections] Adapting OpenHFT SHM as JSR-107 interoperable JCACHE (Off-Heap!) operand (#13)
A key enhancement to VSHM is the addition of meta data for each entry.
There is none currently however you might find it useful for timestamps
like last updated, or counters like the number of times accessed.
This will be supported by you providing a visitor interface which will be
called with the meta/key/value for different actions.
I believe it might also be useful for supporting caches eg expiry info.
It is intended to help support multimaster replication.
On 12 Mar 2014 03:02, "Ben Cotton" [email protected] wrote:
FYI. Attached is dialog with Red Hat's ISPN lead = Mircea Markus. For now
Dmitry and I will code this adoption to be coupled to ISPN7 as our lone
JCACHE provider. However, it will be loosley coupled -- and at all times
coded as such - with the consideration to grow VSHM to potetnaillyaccommodate any/all JCACHE providers.
Ben, at this stage you already have an JCache implementation backed by the
DataContainer, by using the JCache implementation provided by ISPN an
configuring Infinispan with the new custom data container.Thanks Mircea. We now "see it" and are proceeding accordingly. We have
removed all ambition to directly implement JCACHE (in any form) from our
Fork. (see newly documented goals at
https://github.com/Cotton-Ben/infinispan) We have also simply re-named
the new module [off-heap].Thanks for your support. We are in full gear to adapt/test/contribute this
Fork. Stay tuned.configuring Infinispan with the new custom data container
Looking forward to learning from you guys exactly how to do this!
Thanks!
Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-37313061
.
—
Reply to this email directly or view it on GitHub #13 (comment) . https://github.com/notifications/beacon/3024996__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcxMDE4NzQzMywiZGF0YSI6eyJpZCI6MjY3Nzg2NzF9fQ==--0c71a113b7dfb2fc9f5333c73f73facecfc05a97.gif
from hugecollections-old.
peter-lawrey
commented on July 19, 2024
No meta data in 3.0c, will be 3.0d
On 12 March 2014 10:49, Ben Cotton [email protected] wrote:
Ø I believe it might also be useful for supporting caches eg expiry info.
+1
Is MetaData already in 3.0c? don't respond ... going there now to check
myself.From: Peter Lawrey [mailto:[email protected]]
Sent: Tuesday, March 11, 2014 4:04 PM
To: OpenHFT/HugeCollections
Cc: Ben Cotton
Subject: Re: [HugeCollections] Adapting OpenHFT SHM as JSR-107
interoperable JCACHE (Off-Heap!) operand (#13)A key enhancement to VSHM is the addition of meta data for each entry.
There is none currently however you might find it useful for timestamps
like last updated, or counters like the number of times accessed.This will be supported by you providing a visitor interface which will be
called with the meta/key/value for different actions.I believe it might also be useful for supporting caches eg expiry info.
It is intended to help support multimaster replication.
On 12 Mar 2014 03:02, "Ben Cotton" [email protected] wrote:FYI. Attached is dialog with Red Hat's ISPN lead = Mircea Markus. For
now
Dmitry and I will code this adoption to be coupled to ISPN7 as our lone
JCACHE provider. However, it will be loosley coupled -- and at all times
coded as such - with the consideration to grow VSHM to potetnaillyaccommodate any/all JCACHE providers.
Ben, at this stage you already have an JCache implementation backed by
the
DataContainer, by using the JCache implementation provided by ISPN an
configuring Infinispan with the new custom data container.Thanks Mircea. We now "see it" and are proceeding accordingly. We have
removed all ambition to directly implement JCACHE (in any form) from our
Fork. (see newly documented goals at
https://github.com/Cotton-Ben/infinispan) We have also simply re-named
the new module [off-heap].Thanks for your support. We are in full gear to adapt/test/contribute
this
Fork. Stay tuned.configuring Infinispan with the new custom data container
Looking forward to learning from you guys exactly how to do this!
Thanks!
Reply to this email directly or view it on GitHub<
https://github.com/OpenHFT/HugeCollections/issues/13#issuecomment-37313061>.
Reply to this email directly or view it on GitHub <
https://github.com/OpenHFT/HugeCollections/issues/13#issuecomment-37342932>
. <
https://github.com/notifications/beacon/3024996__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcxMDE4NzQzMywiZGF0YSI6eyJpZCI6MjY3Nzg2NzF9fQ==--0c71a113b7dfb2fc9f5333c73f73facecfc05a97.gif>Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-37360595
.
from hugecollections-old.
RobAustin
commented on July 19, 2024
Git pushes ( aka checking’s ) - now synced with JIRA, see example below :
and clicking on one of this links gives you :
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
? (maybe I'm not seeing the full text of Rob's post? e.g. "example below:" ? )
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
Dmitry, Let's do it like this. You and I will be 'cross-streams' to one another. ISPN7 will be 'upstream' to us both. For this issue only, our OpenHFT join point will be strictly through their maven central pom. currently 3.0c.
So do this:
cd /apps/dgor/workspace/
git clone https://github.com/infinispan/infinispan.git
cd infinispan
git remote add upstream https://github.com/infinispan/infinispan.git
git remote add cross-stream https://github.com/Cotton-Bin/infinispan.git
git remote -v
#make sure you see all of this:
#origin: https://github.com/dgor/infinispan.git
#upstream: https://github.com/infinispan/infinispan.git
#cross-stream: https://github.com/Cotton-Ben/infinispan.git
git pull -u cross-stream master #pull my fork's view into your workspace
git push -u origin master #push your workspace update of my fork to your fork
#now build the RDR_DIMENSION VO in your workspace
#when you have committed updates, push to your origin. send me a pull request
#when i've committed updates, i push to my origin, send you a pull request
#each morning, we both do
git pull -u upstream master #pull RedHat's commits into our workspace
git push -u origin master #push RedHat's commits fr: our workspace to: our fork
#when we are ready to push the off-heap solution to redhat, we send them a pull request
#BTW, anyone else from LRI wanting to join us, we *mandate* IntelliJ be used.
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
Dmitry,
This is our first effort to put Peter's SHM off-heap operand in the path of ISPN7's JSR-107 operator set.
At this stage its only ambition is to do a "Hello ISPN7, I'm an OpenHFT SHM, and I want to be your Cache.Entry<K,V> off-heap custodian."
DONE: model the existing ISPN7 DefaultDataContainer and replace all occurrences of RedHat ConcurrentParallelMap<K,V> with OpenHFT SharedHashMap<K,V>
Here are the payload lines, for now:
protected SharedHashMap<Object, InternalCacheEntry> entries;
and
entries = new SharedHashMapBuilder()
.generatedValueType(Boolean.TRUE)
.entrySize(512)
.create(
new File("/dev/shm/offHeapSharedHashMap.DataContainer"),
Object.class,
InternalCacheEntry.class
);
TODO: 1 re-use RedHat default DataContainer? (but, I hate the idea of hiding super().entries with new Type)
TODO: 2 get RedHat counsel
TODO: 3 @test the POC of RDR_DIM_VO as RedHat ICE
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
FYI
from hugecollections-old.
peter-lawrey
commented on July 19, 2024
Only use an Object key if you really have no idea what the key type is.
Also avoid serializing types which impliments Serializable as these are
particularly inefficient.
On 15 Mar 2014 12:39, "Ben Cotton" [email protected] wrote:
Dmitry,
This is our first effort to put Peter's SHM off-heap operand in the path
of ISPN7's JSR-107 operator set.At this stage its only ambition is to do a "Hello ISPN7, I'm an OpenHFT
SHM, and I want to be your Cache.Entry off-heap custodian."DONE: model the existing ISPN7 DefaultDataContainer and replace all
occurrences of RedHat ConcurrentParallelMap with OpenHFT SharedHashMapHere are the payload lines, for now:
protected SharedHashMap<Object, InternalCacheEntry> entries;
and
entries = new SharedHashMapBuilder()
.generatedValueType(Boolean.TRUE)
.entrySize(512)
.create(
new File("/dev/shm/offHeapSharedHashMap.DataContainer"),
Object.class,
InternalCacheEntry.class
);TODO: 1 re-use RedHat default DataContainer? (but, I hate the idea of
hiding super().entries with new Type)TODO: 2 get RedHat counsel
TODO: 3 @test https://github.com/Test the POC of RDR_DIM_VO as RedHat
ICEReply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-37712106
.
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
Hi Dmitry,
We now have the basis for an @test
please issue this cross-stream pull:
git pull -u cross-stream master https://github.com/Cotton-Ben/infinispan.git
The test is still incomplete. We need RedHat counsel on how to use their internal APIs in tests. E.g
InternalEntryFactoryImpl internalEntryFactory = new InternalEntryFactoryImpl();
internalEntryFactory.injectTimeService(TIME_SERVICE);
I'm not gonna queue up questions in their developer forum. So let's just take it slow with the expectation for this test to pass early this week.
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
Dmitry, Xiao,
We now have a potential to adapt OpenHFT to a second JCACHE provider = HazelCast. Very early stages of discovery, this is a Fork to a HZ "research" instance. Unlike, our Infinispan Fork, this Fork bridges to no official upstream HZ product.
https://github.com/Cotton-Ben/hznextgen
Of course, the RedHad adaptation remains priority one.
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
Following Peter's counsel, providing generic K parameter (no longer Object.class)
Build accommodating Test to prove the InfoQ article's BondVOInterface can act as an off-heap Cache<K,V> (from the Infinispan 7 DataContainer View).
TODO:
ConfigurationBuilder a = new ConfigurationBuilder();
a.dataContainer().dataContainer(new OffHeapContainer());
ConfigurationBuilder b = new ConfigurationBuilder();
b.dataContainer().dataContainer(new DefaultDataContainer());
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
Dmitry: Pushed up a set of @test that are still failing, but, just ignore it. still I need this synched.
I'd say we are about Half-Way done with OpenHFT adaptation as off-heap [container] [meta-d…
…ata] [entry] [cache] provider to ISPN7. Even though there are failures the @test set is now running .... and it is just a matter of serving our "hard labor" implementation sentence ... and the @test set will pass.
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
Every imaginable off-heap Cache.Entry<K,V> bridge to OpenHFT is being accommodated.
[Container] [Entry] [Versioned] [MVCC] and [metaData].
No tests have run nor passed. But the bridges are being built nicely.
Xiao will help tomorrow with the CopyOnMutateRedHatCodin isolation strategy. @tests for for the intoleranceSet = {DIRTY_READ, NON_REPEATABLE_READ, PHANTOM_READ} ar ein place (but not run).
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
Hi Peter,
We have started explicit testing of ISPN7 with OpenHFT 3.0d as its Off-Heap JCACHE operand provider.
Would 3.0d's new entrySet support possibly have the effect of requiring BondVOInterface to manage getEntry()/setEntry() signatures?
I am running this @test = testOpenHFTasOffHeapJcacheOperandProvider()
from https://github.com/Cotton-Ben/infinispan/tree/master/off-heap/src/test/java/org/infinispan/offheap
and I experience the following stackTrace from the line 73
BondVOInterface bondV = DataValueClasses.newDirectReference(BondVOInterface.class);
invoke. BondVOInterface is exactly as it was for the InfoQ article.
[TestNG] Running:
/root/.IdeaIC13/system/temp-testng-customsuite.xml
ISPN7 JCACHE DataContainer view of OpenHFT SHM is being created
OpenHFT SHMBuilder starting: /dev/shmSHM/bondVO.@t=1395279471808 entries=[NULL]
OpenHFT SHMBuilder done: /dev/shmSHM/bondVO.@t=1395279471808 entries=[{}]
ISPN7 JCACHE DataContainer created jcacheDataContainer=[org.infinispan.offheap.container.OffHeapDefaultDataContainer@10fd8ce3]
java.lang.AssertionError: java.lang.IllegalArgumentException: *Field entry must have a getter and setter*.
at net.openhft.lang.model.DataValueClassCache.newDirectReference(DataValueClassCache.java:39)
at net.openhft.lang.model.DataValueClasses.newDirectReference(DataValueClasses.java:36)
at org.infinispan.offheap.OffHeapDefaultDataContainerTest.testOpenHFTasOffHeapJcacheOperandProvider(OffHeapDefaultDataContainerTest.java:73)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
at org.testng.TestRunner.privateRun(TestRunner.java:767)
at org.testng.TestRunner.run(TestRunner.java:617)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
at org.testng.SuiteRunner.run(SuiteRunner.java:240)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1198)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1123)
at org.testng.TestNG.run(TestNG.java:1031)
at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111)
at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204)
at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175)
at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:125)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: java.lang.IllegalArgumentException: Field entry must have a getter and setter.
at net.openhft.lang.model.DataValueModelImpl.<init>(DataValueModelImpl.java:158)
at net.openhft.lang.model.DataValueModels.acquireModel(DataValueModels.java:42)
at net.openhft.lang.model.DataValueGenerator.acquireNativeClass(DataValueGenerator.java:299)
at net.openhft.lang.model.DataValueClassCache.directClassFor(DataValueClassCache.java:48)
at net.openhft.lang.model.DataValueClassCache.newDirectReference(DataValueClassCache.java:37)
... 32 more
===============================================
Custom suite
Total tests run: 1, Failures: 1, Skips: 0
===============================================
Process finished with exit code 0
from hugecollections-old.
peter-lawrey
commented on July 19, 2024
The error needs to be improved to say which field and what the problem
really is. Are you sure you have 3.0d as I would have expected this error
only in older versions.
On 20 Mar 2014 02:14, "Ben Cotton" [email protected] wrote:
Hi Peter,
We have started explicit testing of ISPN7 with OpenHFT 3.0d as its
Off-Heap JCACHE operand provider.Would 3.0d's new entrySet support possibly have the effect of requiring
BondVOInterface to manage getEntry()/setEntry() signatures?I am running this @test https://github.com/Test =
testOpenHFTasOffHeapJcacheOperandProvider()from
https://github.com/Cotton-Ben/infinispan/tree/master/off-heap/src/test/java/org/infinispan/offheapand I experience the following stackTrace from the line 73
BondVOInterface bondV =
DataValueClasses.newDirectReference(BondVOInterface.class);invoke. BondVOInterface is exactly as it was for the InfoQ article.
[TestNG] Running:
/root/.IdeaIC13/system/temp-testng-customsuite.xmlISPN7 JCACHE DataContainer view of OpenHFT SHM is being created
OpenHFT SHMBuilder starting: /dev/shmSHM/bondVO.@t=1395279471808 entries=[NULL]
OpenHFT SHMBuilder done: /dev/shmSHM/bondVO.@t=1395279471808 entries=[{}]
ISPN7 JCACHE DataContainer created jcacheDataContainer=[org.infinispan.offheap.container.OffHeapDefaultDataContainer@10fd8ce3]
java.lang.AssertionError: java.lang.IllegalArgumentException: Field entry must have a getter and setter.
at net.openhft.lang.model.DataValueClassCache.newDirectReference(DataValueClassCache.java:39)
at net.openhft.lang.model.DataValueClasses.newDirectReference(DataValueClasses.java:36)
at org.infinispan.offheap.OffHeapDefaultDataContainerTest.testOpenHFTasOffHeapJcacheOperandProvider(OffHeapDefaultDataContainerTest.java:73)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
at org.testng.TestRunner.privateRun(TestRunner.java:767)
at org.testng.TestRunner.run(TestRunner.java:617)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
at org.testng.SuiteRunner.run(SuiteRunner.java:240)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1198)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1123)
at org.testng.TestNG.run(TestNG.java:1031)
at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111)
at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204)
at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175)
at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:125)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: java.lang.IllegalArgumentException: Field entry must have a getter and setter.
at net.openhft.lang.model.DataValueModelImpl.(DataValueModelImpl.java:158)
at net.openhft.lang.model.DataValueModels.acquireModel(DataValueModels.java:42)
at net.openhft.lang.model.DataValueGenerator.acquireNativeClass(DataValueGenerator.java:299)
at net.openhft.lang.model.DataValueClassCache.directClassFor(DataValueClassCache.java:48)
at net.openhft.lang.model.DataValueClassCache.newDirectReference(DataValueClassCache.java:37)
... 32 moreCustom suite
Total tests run: 1, Failures: 1, Skips: 0
Process finished with exit code 0
Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-38129097
.
from hugecollections-old.
ben--cotton
commented on July 19, 2024
Definitely 3.0d ... Otherwise I get the entrySet unsupportedException
Can you still run the infoq docs pkg of tests w 3.0d? Specifically the .newDirectReference(BondVOInterface.class); invoke?
Sent with Good (www.good.com)
-----Original Message-----
From: Peter Lawrey [[email protected]:[email protected]]
Sent: Wednesday, March 19, 2014 11:57 PM Central Standard Time
To: OpenHFT/HugeCollections
Cc: Cotton, Ben
Subject: Re: [HugeCollections] Adapting OpenHFT SHM as JSR-107 interoperable JCACHE (Off-Heap!) operand (#13)
The error needs to be improved to say which field and what the problem
really is. Are you sure you have 3.0d as I would have expected this error
only in older versions.
On 20 Mar 2014 02:14, "Ben Cotton" [email protected] wrote:
Hi Peter,
We have started explicit testing of ISPN7 with OpenHFT 3.0d as its
Off-Heap JCACHE operand provider.Would 3.0d's new entrySet support possibly have the effect of requiring
BondVOInterface to manage getEntry()/setEntry() signatures?I am running this @test https://github.com/Test =
testOpenHFTasOffHeapJcacheOperandProvider()from
https://github.com/Cotton-Ben/infinispan/tree/master/off-heap/src/test/java/org/infinispan/offheapand I experience the following stackTrace from the line 73
BondVOInterface bondV =
DataValueClasses.newDirectReference(BondVOInterface.class);invoke. BondVOInterface is exactly as it was for the InfoQ article.
[TestNG] Running:
/root/.IdeaIC13/system/temp-testng-customsuite.xmlISPN7 JCACHE DataContainer view of OpenHFT SHM is being created
OpenHFT SHMBuilder starting: /dev/shmSHM/bondVO.@t=1395279471808 entries=[NULL]
OpenHFT SHMBuilder done: /dev/shmSHM/bondVO.@t=1395279471808 entries=[{}]
ISPN7 JCACHE DataContainer created jcacheDataContainer=[org.infinispan.offheap.container.OffHeapDefaultDataContainer@10fd8ce3]
java.lang.AssertionError: java.lang.IllegalArgumentException: Field entry must have a getter and setter.
at net.openhft.lang.model.DataValueClassCache.newDirectReference(DataValueClassCache.java:39)
at net.openhft.lang.model.DataValueClasses.newDirectReference(DataValueClasses.java:36)
at org.infinispan.offheap.OffHeapDefaultDataContainerTest.testOpenHFTasOffHeapJcacheOperandProvider(OffHeapDefaultDataContainerTest.java:73)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
at org.testng.TestRunner.privateRun(TestRunner.java:767)
at org.testng.TestRunner.run(TestRunner.java:617)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
at org.testng.SuiteRunner.run(SuiteRunner.java:240)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1198)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1123)
at org.testng.TestNG.run(TestNG.java:1031)
at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111)
at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204)
at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175)
at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:125)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: java.lang.IllegalArgumentException: Field entry must have a getter and setter.
at net.openhft.lang.model.DataValueModelImpl.(DataValueModelImpl.java:158)
at net.openhft.lang.model.DataValueModels.acquireModel(DataValueModels.java:42)
at net.openhft.lang.model.DataValueGenerator.acquireNativeClass(DataValueGenerator.java:299)
at net.openhft.lang.model.DataValueClassCache.directClassFor(DataValueClassCache.java:48)
at net.openhft.lang.model.DataValueClassCache.newDirectReference(DataValueClassCache.java:37)
... 32 moreCustom suite
Total tests run: 1, Failures: 1, Skips: 0
Process finished with exit code 0
Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-38129097
.
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-38135270.
This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.
from hugecollections-old.
peter-lawrey
commented on July 19, 2024
I will have to test on the weekend. It is possible there was a merge issue
and a regress of code.
In the meantime try dropping the record field or adding dummy
getter/setters for it.
On 20 Mar 2014 05:05, "Ben Cotton" [email protected] wrote:
Definitely 3.0d ... Otherwise I get the entrySet unsupportedException
Can you still run the infoq docs pkg of tests w 3.0d? Specifically the
.newDirectReference(BondVOInterface.class); invoke?Sent with Good (www.good.com)
-----Original Message-----
From: Peter Lawrey [[email protected]<mailto:
[email protected]>]
Sent: Wednesday, March 19, 2014 11:57 PM Central Standard Time
To: OpenHFT/HugeCollections
Cc: Cotton, Ben
Subject: Re: [HugeCollections] Adapting OpenHFT SHM as JSR-107
interoperable JCACHE (Off-Heap!) operand (#13)The error needs to be improved to say which field and what the problem
really is. Are you sure you have 3.0d as I would have expected this error
only in older versions.
On 20 Mar 2014 02:14, "Ben Cotton" [email protected] wrote:Hi Peter,
We have started explicit testing of ISPN7 with OpenHFT 3.0d as its
Off-Heap JCACHE operand provider.Would 3.0d's new entrySet support possibly have the effect of requiring
BondVOInterface to manage getEntry()/setEntry() signatures?I am running this @test https://github.com/Test =
testOpenHFTasOffHeapJcacheOperandProvider()from
https://github.com/Cotton-Ben/infinispan/tree/master/off-heap/src/test/java/org/infinispan/offheap
and I experience the following stackTrace from the line 73
BondVOInterface bondV =
DataValueClasses.newDirectReference(BondVOInterface.class);invoke. BondVOInterface is exactly as it was for the InfoQ article.
[TestNG] Running:
/root/.IdeaIC13/system/temp-testng-customsuite.xmlISPN7 JCACHE DataContainer view of OpenHFT SHM is being created
OpenHFT SHMBuilder starting: /dev/shmSHM/bondVO.@t=1395279471808
entries=[NULL]
OpenHFT SHMBuilder done: /dev/shmSHM/bondVO.@t=1395279471808
entries=[{}]
ISPN7 JCACHE DataContainer created
jcacheDataContainer=[org.infinispan.offheap.container.OffHeapDefaultDataContainer@10fd8ce3]java.lang.AssertionError: java.lang.IllegalArgumentException: Field
entry must have a getter and setter.
at
net.openhft.lang.model.DataValueClassCache.newDirectReference(DataValueClassCache.java:39)at
net.openhft.lang.model.DataValueClasses.newDirectReference(DataValueClasses.java:36)at
org.infinispan.offheap.OffHeapDefaultDataContainerTest.testOpenHFTasOffHeapJcacheOperandProvider(OffHeapDefaultDataContainerTest.java:73)at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)at java.lang.reflect.Method.invoke(Method.java:606)
at
org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
at
org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
at org.testng.TestRunner.privateRun(TestRunner.java:767)
at org.testng.TestRunner.run(TestRunner.java:617)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
at org.testng.SuiteRunner.run(SuiteRunner.java:240)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1198)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1123)
at org.testng.TestNG.run(TestNG.java:1031)
at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111)
at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204)
at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175)
at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:125)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: java.lang.IllegalArgumentException: Field entry must have a
getter and setter.
at
net.openhft.lang.model.DataValueModelImpl.(DataValueModelImpl.java:158)at
net.openhft.lang.model.DataValueModels.acquireModel(DataValueModels.java:42)at
net.openhft.lang.model.DataValueGenerator.acquireNativeClass(DataValueGenerator.java:299)at
net.openhft.lang.model.DataValueClassCache.directClassFor(DataValueClassCache.java:48)at
net.openhft.lang.model.DataValueClassCache.newDirectReference(DataValueClassCache.java:37)... 32 more
Custom suite
Total tests run: 1, Failures: 1, Skips: 0
Process finished with exit code 0
Reply to this email directly or view it on GitHub<
https://github.com/OpenHFT/HugeCollections/issues/13#issuecomment-38129097>.
Reply to this email directly or view it on GitHub<
https://github.com/OpenHFT/HugeCollections/issues/13#issuecomment-38135270>.This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of securities,
accuracy and completeness of information, viruses, confidentiality, legal
privilege, and legal entity disclaimers, available at
http://www.jpmorgan.com/pages/disclosures/email.Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-38135539
.
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
No hurry (and thanks!)
FYI. added these signatures to BondVOInterInterface.java ... which produced an improved effect, but still a few issues with the 3.0d depdendency.
//Ben forgets, ..., is it 'record' or 'entry' that is the field?
void setRecord(Bytes record);
Bytes getRecord();
void setEntry(Bytes entry);
Bytes getEntry();
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
FYI, Here is the current 3.0d Exception that we encounter:
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:12: error: class MarketPx£native is public, should be declared in a file named MarketPx£native.java
public class MarketPx£native implements MarketPx, BytesMarshallable, Byteable, Copyable<org.infinispan.offheap.BondVOInterface$MarketPx> {
^
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:12: error: cannot find symbol
public class MarketPx£native implements MarketPx, BytesMarshallable, Byteable, Copyable<org.infinispan.offheap.BondVOInterface$MarketPx> {
^
symbol: class MarketPx
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:12: error: cannot find symbol
public class MarketPx£native implements MarketPx, BytesMarshallable, Byteable, Copyable<org.infinispan.offheap.BondVOInterface$MarketPx> {
^
symbol: class BondVOInterface$MarketPx
location: package org.infinispan.offheap
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:63: error: cannot find symbol
public void copyFrom(org.infinispan.offheap.BondVOInterface$MarketPx from) {
^
symbol: class BondVOInterface$MarketPx
location: package org.infinispan.offheap
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:113: error: cannot find symbol
if (!(o instanceof MarketPx)) return false;
[...]
```` ^
from hugecollections-old.
peter-lawrey
commented on July 19, 2024
There is a problem with using £ in a class name on macs. It works on
windows and linux but only sometimes on mac. In some contexts it compiles
file in others it thinks the file name doesn't match or can't fimd the file
which is clearly there. I.e. encoding on the file name is messed up.
Will have to replace the £ with $$
On 20 Mar 2014 19:56, "Ben Cotton" [email protected] wrote:
FYI, Here is the current 3.0d Exception that we encounter:
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:12: error: class MarketPx£native is public, should be declared in a file named MarketPx£native.java
public class MarketPx£native implements MarketPx, BytesMarshallable, Byteable, Copyable<org.infinispan.offheap.BondVOInterface$MarketPx> {
^
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:12: error: cannot find symbol
public class MarketPx£native implements MarketPx, BytesMarshallable, Byteable, Copyable<org.infinispan.offheap.BondVOInterface$MarketPx> {
^
symbol: class MarketPx
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:12: error: cannot find symbol
public class MarketPx£native implements MarketPx, BytesMarshallable, Byteable, Copyable<org.infinispan.offheap.BondVOInterface$MarketPx> {
^
symbol: class BondVOInterface$MarketPx
location: package org.infinispan.offheap
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:63: error: cannot find symbol
public void copyFrom(org.infinispan.offheap.BondVOInterface$MarketPx from) {
^
symbol: class BondVOInterface$MarketPx
location: package org.infinispan.offheap
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:113: error: cannot find symbol
if (!(o instanceof MarketPx)) return false;[...]
-- Reply to this email directly or view it on GitHub<https://github.com/OpenHFT/HugeCollections/issues/13#issuecomment-38213575> .
from hugecollections-old.
ben--cotton
commented on July 19, 2024
Thanks Peter. So £ to $$ exchange in 3.0e should bring remedy? (sort of a JDK inner-class version of a currency preference. :-) )
P.S. In addition to the Mac, I do see this exact same Exception in my TestNG/IntelliJ13-CE/ OpenJDK-7/ Fedora 20 Linux environment.
Ben D. Cotton III
J.P.Morgan
Liquidity Risk Technology
277 Park Ave Desk 08-GG64
New York, NY 10172-0003
212.622.5010
[email protected]:[email protected]
From: Peter Lawrey [mailto:[email protected]]
Sent: Thursday, March 20, 2014 10:46 PM
To: OpenHFT/HugeCollections
Cc: Cotton, Ben
Subject: Re: [HugeCollections] Adapting OpenHFT SHM as JSR-107 interoperable JCACHE (Off-Heap!) operand (#13)
There is a problem with using £ in a class name on macs. It works on
windows and linux but only sometimes on mac. In some contexts it compiles
file in others it thinks the file name doesn't match or can't fimd the file
which is clearly there. I.e. encoding on the file name is messed up.
Will have to replace the £ with $$
On 20 Mar 2014 19:56, "Ben Cotton" <[email protected]mailto:[email protected]> wrote:
FYI, Here is the current 3.0d Exception that we encounter:
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:12: error: class MarketPx£native is public, should be declared in a file named MarketPx£native.java
public class MarketPx£native implements MarketPx, BytesMarshallable, Byteable, Copyable<org.infinispan.offheap.BondVOInterface$MarketPx> {
^
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:12: error: cannot find symbol
public class MarketPx£native implements MarketPx, BytesMarshallable, Byteable, Copyable<org.infinispan.offheap.BondVOInterface$MarketPx> {
^
symbol: class MarketPx
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:12: error: cannot find symbol
public class MarketPx£native implements MarketPx, BytesMarshallable, Byteable, Copyable<org.infinispan.offheap.BondVOInterface$MarketPx> {
^
symbol: class BondVOInterface$MarketPx
location: package org.infinispan.offheap
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:63: error: cannot find symbol
public void copyFrom(org.infinispan.offheap.BondVOInterface$MarketPx from) {
^
symbol: class BondVOInterface$MarketPx
location: package org.infinispan.offheap
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:113: error: cannot find symbol
if (!(o instanceof MarketPx)) return false;[...]
-- Reply to this email directly or view it on GitHub<https://github.com/OpenHFT/HugeCollections/issues/13#issuecomment-38213575> .
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-38245099.
This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.
from hugecollections-old.
RobAustin
commented on July 19, 2024
Ben
This should be fixed in the latest snapshot (and subsequent release):
net.openhft
collections
3.0e-SNAPSHOT
please let me know if you still have any problems
Thanks
Rob Austin
On 21 Mar 2014, at 13:57, Ben Cotton [email protected] wrote:
Thanks Peter. So £ to $$ exchange in 3.0e should bring remedy? (sort of a JDK inner-class version of a currency preference. :-) )
P.S. In addition to the Mac, I do see this exact same Exception in my TestNG/IntelliJ13-CE/ OpenJDK-7/ Fedora 20 Linux environment.
Ben D. Cotton III
J.P.Morgan
Liquidity Risk Technology
277 Park Ave Desk 08-GG64
New York, NY 10172-0003
212.622.5010
[email protected]:[email protected]From: Peter Lawrey [mailto:[email protected]]
Sent: Thursday, March 20, 2014 10:46 PM
To: OpenHFT/HugeCollections
Cc: Cotton, Ben
Subject: Re: [HugeCollections] Adapting OpenHFT SHM as JSR-107 interoperable JCACHE (Off-Heap!) operand (#13)There is a problem with using £ in a class name on macs. It works on
windows and linux but only sometimes on mac. In some contexts it compiles
file in others it thinks the file name doesn't match or can't fimd the file
which is clearly there. I.e. encoding on the file name is messed up.
Will have to replace the £ with $$
On 20 Mar 2014 19:56, "Ben Cotton" <[email protected]mailto:[email protected]> wrote:FYI, Here is the current 3.0d Exception that we encounter:
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:12: error: class MarketPx£native is public, should be declared in a file named MarketPx£native.java
public class MarketPx£native implements MarketPx, BytesMarshallable, Byteable, Copyable<org.infinispan.offheap.BondVOInterface$MarketPx> {
^
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:12: error: cannot find symbol
public class MarketPx£native implements MarketPx, BytesMarshallable, Byteable, Copyable<org.infinispan.offheap.BondVOInterface$MarketPx> {
^
symbol: class MarketPx
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:12: error: cannot find symbol
public class MarketPx£native implements MarketPx, BytesMarshallable, Byteable, Copyable<org.infinispan.offheap.BondVOInterface$MarketPx> {
^
symbol: class BondVOInterface$MarketPx
location: package org.infinispan.offheap
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:63: error: cannot find symbol
public void copyFrom(org.infinispan.offheap.BondVOInterface$MarketPx from) {
^
symbol: class BondVOInterface$MarketPx
location: package org.infinispan.offheap
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:113: error: cannot find symbol
if (!(o instanceof MarketPx)) return false;[...]
-- Reply to this email directly or view it on GitHub<https://github.com/OpenHFT/HugeCollections/issues/13#issuecomment-38213575> .—
Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-38245099.This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.
—
Reply to this email directly or view it on GitHub.
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
Hi Rob, I pulled from https://github.com/OpenHFT/HugeCollections.git and noted the new
IntValue$$Native.java
LongValue$$Native.java
additions that indicated your patch's Test was correctly rendering $$ named inner classes.
I built what I pulled from you guys locally and maven put these into the 3.0e-SNAPSHOT .jar that was installed into my local ~/.m2/repository tree.
After I got 3.0e-SNAPSHOT built and installed I then updated my ISPN7 [off-heap] module's pom.xml to reference the newly built 3.0e-SNAPSHOT version dependency.
I then re-ran the Test that was failing becasue of the GBP symbol inner class separator issue (https://github.com/Cotton-Ben/infinispan/tree/master/off-heap/ ) We got the exact same error.
[TestNG] Running:
/root/.IdeaIC13/system/temp-testng-customsuite.xml
ISPN7 JCACHE DataContainer view of OpenHFT SHM is being created
OpenHFT SHMBuilder starting: /dev/shmSHM/bondVO.@t=1395449272662 entries=[NULL]
OpenHFT SHMBuilder done: /dev/shmSHM/bondVO.@t=1395449272662 entries=[{}]
ISPN7 JCACHE DataContainer created jcacheDataContainer=[org.infinispan.offheap.container.OffHeapDefaultDataContainer@5926557e]
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:12: error: class MarketPx£native is public, should be declared in a file named MarketPx£native.java
public class MarketPx£native implements MarketPx, BytesMarshallable, Byteable, Copyable<org.infinispan.offheap.BondVOInterface$MarketPx> {
^
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:12: error: cannot find symbol
public class MarketPx£native implements MarketPx, BytesMarshallable, Byteable, Copyable<org.infinispan.offheap.BondVOInterface$MarketPx> {
^
symbol: class MarketPx
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:12: error: cannot find symbol
public class MarketPx£native implements MarketPx, BytesMarshallable, Byteable, Copyable<org.infinispan.offheap.BondVOInterface$MarketPx> {
^
symbol: class BondVOInterface$MarketPx
location: package org.infinispan.offheap
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:63: error: cannot find symbol
public void copyFrom(org.infinispan.offheap.BondVOInterface$MarketPx from) {
^
symbol: class BondVOInterface$MarketPx
location: package org.infinispan.offheap
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:113: error: cannot find symbol
if (!(o instanceof MarketPx)) return false;
^
symbol: class MarketPx
location: class MarketPx£native
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:114: error: cannot find symbol
MarketPx that = (MarketPx) o;
^
symbol: class MarketPx
location: class MarketPx£native
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:114: error: cannot find symbol
MarketPx that = (MarketPx) o;
^
symbol: class MarketPx
location: class MarketPx£native
7 errors
java.lang.AssertionError: java.lang.ClassNotFoundException: org.infinispan.offheap.BondVOInterface$MarketPx£native
at net.openhft.lang.model.DataValueGenerator.acquireNativeClass(DataValueGenerator.java:315)
at net.openhft.lang.model.DataValueGenerator.acquireNativeClass(DataValueGenerator.java:302)
at net.openhft.lang.model.DataValueClassCache.directClassFor(DataValueClassCache.java:48)
at net.openhft.lang.model.DataValueClassCache.newDirectReference(DataValueClassCache.java:37)
at net.openhft.lang.model.DataValueClasses.newDirectReference(DataValueClasses.java:36)
at org.infinispan.offheap.test.OffHeapDefaultDataContainerTest.testOpenHFTasOffHeapJcacheOperandProvider(OffHeapDefaultDataContainerTest.java:75)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
at org.testng.TestRunner.privateRun(TestRunner.java:767)
at org.testng.TestRunner.run(TestRunner.java:617)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
at org.testng.SuiteRunner.run(SuiteRunner.java:240)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1198)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1123)
at org.testng.TestNG.run(TestNG.java:1031)
at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111)
at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204)
at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175)
at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:125)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: java.lang.ClassNotFoundException: org.infinispan.offheap.BondVOInterface$MarketPx£native
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at net.openhft.compiler.CachedCompiler.loadFromJava(CachedCompiler.java:108)
at net.openhft.lang.model.DataValueGenerator.acquireNativeClass(DataValueGenerator.java:313)
... 35 more
===============================================
Custom suite
Total tests run: 1, Failures: 1, Skips: 0
===============================================
Process finished with exit code 0
I became concerned that I may not be getting the 3.0e-SNAPSHOT effect due to something delinquent in my local maven build tactics (I'm used to 3.0d being in maven central). So I ran a script to prune off any non-3.0e-SNAPSHOT jar from my environment.
root@i7-benx> find /root/.m2/repository/ -print | grep .jar | grep collections-3.0
/root/.m2/repository/net/openhft/collections/3.0e-SNAPSHOT/collections-3.0e-SNAPSHOT.jar.lastUpdated
/root/.m2/repository/net/openhft/collections/3.0e-SNAPSHOT/collections-3.0e-SNAPSHOT-sources.jar
/root/.m2/repository/net/openhft/collections/3.0e-SNAPSHOT/collections-3.0e-SNAPSHOT.jar
/root/.m2/repository/net/openhft/collections/3.0e-SNAPSHOT/collections-3.0e-SNAPSHOT-javadoc.jar
root@i7-benx>
SO I feel pretty sure that the local 3.0e-SNAPSHOT.jar is probably the only possible HC library participarting in my test.
Any ideas how to proceed?
P.S. Many many thanks!
from hugecollections-old.
peter-lawrey
commented on July 19, 2024
Thank you for the update. Would have checked this myself but came home to
find it burgled. Not impressed.
On 22 Mar 2014 00:55, "Ben Cotton" [email protected] wrote:
Hi Rob, I pulled from https://github.com/OpenHFT/HugeCollections.git and
noted the newIntValue$$Native.java
LongValue$$Native.javaadditions that indicated your patch's Test was correctly rendering $$
named inner classes.I built what I pulled from you guys locally and maven put these into the
3.0e-SNAPSHOT .jar that was installed into my local ~/.m2/repository tree.After I got 3.0e-SNAPSHOT built and installed I then updated my ISPN7
[off-heap] module's pom.xml to reference the newly built 3.0e-SNAPSHOT
version dependency.I then re-ran the Test that was failing becasue of the GBP symbol inner
class separator issue (
https://github.com/Cotton-Ben/infinispan/tree/master/off-heap/ ) We got
the exact same error.[TestNG] Running:
/root/.IdeaIC13/system/temp-testng-customsuite.xmlISPN7 JCACHE DataContainer view of OpenHFT SHM is being created
OpenHFT SHMBuilder starting: /dev/shmSHM/bondVO.@t=1395449272662 entries=[NULL]
OpenHFT SHMBuilder done: /dev/shmSHM/bondVO.@t=1395449272662 entries=[{}]
ISPN7 JCACHE DataContainer created jcacheDataContainer=[org.infinispan.offheap.container.OffHeapDefaultDataContainer@5926557e]
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:12: error: class MarketPx£native is public, should be declared in a file named MarketPx£native.java
public class MarketPx£native implements MarketPx, BytesMarshallable, Byteable, Copyable<org.infinispan.offheap.BondVOInterface$MarketPx> {
^
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:12: error: cannot find symbol
public class MarketPx£native implements MarketPx, BytesMarshallable, Byteable, Copyable<org.infinispan.offheap.BondVOInterface$MarketPx> {
^
symbol: class MarketPx
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:12: error: cannot find symbol
public class MarketPx£native implements MarketPx, BytesMarshallable, Byteable, Copyable<org.infinispan.offheap.BondVOInterface$MarketPx> {
^
symbol: class BondVOInterface$MarketPx
location: package org.infinispan.offheap
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:63: error: cannot find symbol
public void copyFrom(org.infinispan.offheap.BondVOInterface$MarketPx from) {
^
symbol: class BondVOInterface$MarketPx
location: package org.infinispan.offheap
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:113: error: cannot find symbol
if (!(o instanceof MarketPx)) return false;
^
symbol: class MarketPx
location: class MarketPx£native
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:114: error: cannot find symbol
MarketPx that = (MarketPx) o;
^
symbol: class MarketPx
location: class MarketPx£native
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:114: error: cannot find symbol
MarketPx that = (MarketPx) o;
^
symbol: class MarketPx
location: class MarketPx£native
7 errors
java.lang.AssertionError: java.lang.ClassNotFoundException: org.infinispan.offheap.BondVOInterface$MarketPx£native
at net.openhft.lang.model.DataValueGenerator.acquireNativeClass(DataValueGenerator.java:315)
at net.openhft.lang.model.DataValueGenerator.acquireNativeClass(DataValueGenerator.java:302)
at net.openhft.lang.model.DataValueClassCache.directClassFor(DataValueClassCache.java:48)
at net.openhft.lang.model.DataValueClassCache.newDirectReference(DataValueClassCache.java:37)
at net.openhft.lang.model.DataValueClasses.newDirectReference(DataValueClasses.java:36)
at org.infinispan.offheap.test.OffHeapDefaultDataContainerTest.testOpenHFTasOffHeapJcacheOperandProvider(OffHeapDefaultDataContainerTest.java:75)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
at org.testng.TestRunner.privateRun(TestRunner.java:767)
at org.testng.TestRunner.run(TestRunner.java:617)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
at org.testng.SuiteRunner.run(SuiteRunner.java:240)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1198)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1123)
at org.testng.TestNG.run(TestNG.java:1031)
at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111)
at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204)
at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175)
at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:125)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: java.lang.ClassNotFoundException: org.infinispan.offheap.BondVOInterface$MarketPx£native
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at net.openhft.compiler.CachedCompiler.loadFromJava(CachedCompiler.java:108)
at net.openhft.lang.model.DataValueGenerator.acquireNativeClass(DataValueGenerator.java:313)
... 35 moreCustom suite
Total tests run: 1, Failures: 1, Skips: 0
Process finished with exit code 0
I became concerned that I may not be getting the 3.0e-SNAPSHOT effect due
to something delinquent in my local maven build tactics (I'm used to 3.0d
being in maven central). So I ran a script to prune off any
non-3.0e-SNAPSHOT jar from my environment.root@i7-benx> find /root/.m2/repository/ -print | grep .jar | grep collections-3.0
/root/.m2/repository/net/openhft/collections/3.0e-SNAPSHOT/collections-3.0e-SNAPSHOT.jar.lastUpdated
/root/.m2/repository/net/openhft/collections/3.0e-SNAPSHOT/collections-3.0e-SNAPSHOT-sources.jar
/root/.m2/repository/net/openhft/collections/3.0e-SNAPSHOT/collections-3.0e-SNAPSHOT.jar
/root/.m2/repository/net/openhft/collections/3.0e-SNAPSHOT/collections-3.0e-SNAPSHOT-javadoc.jar
root@i7-benx>SO I feel pretty sure that the local 3.0e-SNAPSHOT.jar is probably the
only possible HC library participarting in my test.Any ideas how to proceed?
P.S. Many many thanks!
Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-38338566
.
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
Oh no, Peter. So sorry to hear about this. Lazy, pathetic criminals.
Pity them.
On 3/22/2014 12:26 AM, Peter Lawrey wrote:
Thank you for the update. Would have checked this myself but came home to
find it burgled. Not impressed.
On 22 Mar 2014 00:55, "Ben Cotton" [email protected] wrote:Hi Rob, I pulled from https://github.com/OpenHFT/HugeCollections.git
and
noted the newIntValue$$Native.java
LongValue$$Native.javaadditions that indicated your patch's Test was correctly rendering $$
named inner classes.I built what I pulled from you guys locally and maven put these into
the
3.0e-SNAPSHOT .jar that was installed into my local ~/.m2/repository
tree.After I got 3.0e-SNAPSHOT built and installed I then updated my ISPN7
[off-heap] module's pom.xml to reference the newly built 3.0e-SNAPSHOT
version dependency.I then re-ran the Test that was failing becasue of the GBP symbol inner
class separator issue (
https://github.com/Cotton-Ben/infinispan/tree/master/off-heap/ ) We got
the exact same error.[TestNG] Running:
/root/.IdeaIC13/system/temp-testng-customsuite.xmlISPN7 JCACHE DataContainer view of OpenHFT SHM is being created
OpenHFT SHMBuilder starting: /dev/shmSHM/bondVO.@t=1395449272662
entries=[NULL]
OpenHFT SHMBuilder done: /dev/shmSHM/bondVO.@t=1395449272662
entries=[{}]
ISPN7 JCACHE DataContainer created
jcacheDataContainer=[org.infinispan.offheap.container.OffHeapDefaultDataContainer@5926557e]
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:12:
error: class MarketPx£native is public, should be declared in a file
named MarketPx£native.java
public class MarketPx£native implements MarketPx, BytesMarshallable,
Byteable, Copyable<org.infinispan.offheap.BondVOInterface$MarketPx> {
^
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:12:
error: cannot find symbol
public class MarketPx£native implements MarketPx, BytesMarshallable,
Byteable, Copyable<org.infinispan.offheap.BondVOInterface$MarketPx> {
^
symbol: class MarketPx
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:12:
error: cannot find symbol
public class MarketPx£native implements MarketPx, BytesMarshallable,
Byteable, Copyable<org.infinispan.offheap.BondVOInterface$MarketPx> {
^
symbol: class BondVOInterface$MarketPx
location: package org.infinispan.offheap
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:63:
error: cannot find symbol
public void copyFrom(org.infinispan.offheap.BondVOInterface$MarketPx
from) {
^
symbol: class BondVOInterface$MarketPx
location: package org.infinispan.offheap
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:113:
error: cannot find symbol
if (!(o instanceof MarketPx)) return false;
^
symbol: class MarketPx
location: class MarketPx£native
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:114:
error: cannot find symbol
MarketPx that = (MarketPx) o;
^
symbol: class MarketPx
location: class MarketPx£native
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:114:
error: cannot find symbol
MarketPx that = (MarketPx) o;
^
symbol: class MarketPx
location: class MarketPx£native
7 errors
java.lang.AssertionError: java.lang.ClassNotFoundException:
org.infinispan.offheap.BondVOInterface$MarketPx£native
at
net.openhft.lang.model.DataValueGenerator.acquireNativeClass(DataValueGenerator.java:315)
at
net.openhft.lang.model.DataValueGenerator.acquireNativeClass(DataValueGenerator.java:302)
at
net.openhft.lang.model.DataValueClassCache.directClassFor(DataValueClassCache.java:48)
at
net.openhft.lang.model.DataValueClassCache.newDirectReference(DataValueClassCache.java:37)
at
net.openhft.lang.model.DataValueClasses.newDirectReference(DataValueClasses.java:36)
at
org.infinispan.offheap.test.OffHeapDefaultDataContainerTest.testOpenHFTasOffHeapJcacheOperandProvider(OffHeapDefaultDataContainerTest.java:75)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
at
org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
at org.testng.TestRunner.privateRun(TestRunner.java:767)
at org.testng.TestRunner.run(TestRunner.java:617)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
at org.testng.SuiteRunner.run(SuiteRunner.java:240)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1198)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1123)
at org.testng.TestNG.run(TestNG.java:1031)
at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111)
at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204)
at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175)
at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:125)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: java.lang.ClassNotFoundException:
org.infinispan.offheap.BondVOInterface$MarketPx£native
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
net.openhft.compiler.CachedCompiler.loadFromJava(CachedCompiler.java:108)
at
net.openhft.lang.model.DataValueGenerator.acquireNativeClass(DataValueGenerator.java:313)
... 35 moreCustom suite
Total tests run: 1, Failures: 1, Skips: 0
Process finished with exit code 0
I became concerned that I may not be getting the 3.0e-SNAPSHOT
effect due
to something delinquent in my local maven build tactics (I'm used to
3.0d
being in maven central). So I ran a script to prune off any
non-3.0e-SNAPSHOT jar from my environment.root@i7-benx> find /root/.m2/repository/ -print | grep .jar | grep
collections-3.0/root/.m2/repository/net/openhft/collections/3.0e-SNAPSHOT/collections-3.0e-SNAPSHOT.jar.lastUpdated
/root/.m2/repository/net/openhft/collections/3.0e-SNAPSHOT/collections-3.0e-SNAPSHOT-sources.jar
/root/.m2/repository/net/openhft/collections/3.0e-SNAPSHOT/collections-3.0e-SNAPSHOT.jar
/root/.m2/repository/net/openhft/collections/3.0e-SNAPSHOT/collections-3.0e-SNAPSHOT-javadoc.jar
root@i7-benx>SO I feel pretty sure that the local 3.0e-SNAPSHOT.jar is probably the
only possible HC library participarting in my test.Any ideas how to proceed?
P.S. Many many thanks!
Reply to this email directly or view it on
GitHubhttps://github.com//issues/13#issuecomment-38338566
.—
Reply to this email directly or view it on GitHub
#13 (comment).
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
Hey Dmitry and Xiao,
Thanks for your push of the re-factored off-heap interfaces, removing redundancy from the existing RedHat ICE and existing ISPN7 DataContainer interfaces. Indeed, the design is much cleaner.
1 issue caused by all of us authorized to directly pushing to a central Git repo is that we endure Conflict risk. (E.g click on "..." at https://github.com/Cotton-Ben/infinispan/commits/master/off-heap )
It may be best that, instead of us all pushing directly, we cross-issue to each of our streams' branches a "pull" request. Then we can locally assess Conflict risk before merging the pull to our central repo view. This would affect for us a 2PC-like protocol onto our "push" ambitions.
from hugecollections-old.
danielshaya
commented on July 19, 2024
Oh no that's terrible, so frustrating...
Did you lose a lot of stuff?
On 22 March 2014 04:26, Peter Lawrey [email protected] wrote:
Thank you for the update. Would have checked this myself but came home to
find it burgled. Not impressed.
On 22 Mar 2014 00:55, "Ben Cotton" [email protected] wrote:Hi Rob, I pulled from https://github.com/OpenHFT/HugeCollections.gitand
noted the newIntValue$$Native.java
LongValue$$Native.javaadditions that indicated your patch's Test was correctly rendering $$
named inner classes.I built what I pulled from you guys locally and maven put these into the
3.0e-SNAPSHOT .jar that was installed into my local ~/.m2/repository
tree.After I got 3.0e-SNAPSHOT built and installed I then updated my ISPN7
[off-heap] module's pom.xml to reference the newly built 3.0e-SNAPSHOT
version dependency.I then re-ran the Test that was failing becasue of the GBP symbol inner
class separator issue (
https://github.com/Cotton-Ben/infinispan/tree/master/off-heap/ ) We got
the exact same error.[TestNG] Running:
/root/.IdeaIC13/system/temp-testng-customsuite.xmlISPN7 JCACHE DataContainer view of OpenHFT SHM is being created
OpenHFT SHMBuilder starting: /dev/shmSHM/bondVO.@t=1395449272662
entries=[NULL]
OpenHFT SHMBuilder done: /dev/shmSHM/bondVO.@t=1395449272662
entries=[{}]
ISPN7 JCACHE DataContainer created
jcacheDataContainer=[org.infinispan.offheap.container.OffHeapDefaultDataContainer@5926557e]/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:12: error:
class MarketPx£native is public, should be declared in a file named
MarketPx£native.java
public class MarketPx£native implements MarketPx, BytesMarshallable,
Byteable, Copyable<org.infinispan.offheap.BondVOInterface$MarketPx> {
^
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:12: error:
cannot find symbol
public class MarketPx£native implements MarketPx, BytesMarshallable,
Byteable, Copyable<org.infinispan.offheap.BondVOInterface$MarketPx> {
^
symbol: class MarketPx
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:12: error:
cannot find symbol
public class MarketPx£native implements MarketPx, BytesMarshallable,
Byteable, Copyable<org.infinispan.offheap.BondVOInterface$MarketPx> {
^
symbol: class BondVOInterface$MarketPx
location: package org.infinispan.offheap
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:63: error:
cannot find symbol
public void copyFrom(org.infinispan.offheap.BondVOInterface$MarketPx
from) {
^
symbol: class BondVOInterface$MarketPx
location: package org.infinispan.offheap
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:113: error:
cannot find symbol
if (!(o instanceof MarketPx)) return false;
^
symbol: class MarketPx
location: class MarketPx£native
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:114: error:
cannot find symbol
MarketPx that = (MarketPx) o;
^
symbol: class MarketPx
location: class MarketPx£native
/org/infinispan/offheap/BondVOInterface$MarketPx£native.java:114: error:
cannot find symbol
MarketPx that = (MarketPx) o;
^
symbol: class MarketPx
location: class MarketPx£native
7 errors
java.lang.AssertionError: java.lang.ClassNotFoundException:
org.infinispan.offheap.BondVOInterface$MarketPx£native
at
net.openhft.lang.model.DataValueGenerator.acquireNativeClass(DataValueGenerator.java:315)at
net.openhft.lang.model.DataValueGenerator.acquireNativeClass(DataValueGenerator.java:302)at
net.openhft.lang.model.DataValueClassCache.directClassFor(DataValueClassCache.java:48)at
net.openhft.lang.model.DataValueClassCache.newDirectReference(DataValueClassCache.java:37)at
net.openhft.lang.model.DataValueClasses.newDirectReference(DataValueClasses.java:36)at
org.infinispan.offheap.test.OffHeapDefaultDataContainerTest.testOpenHFTasOffHeapJcacheOperandProvider(OffHeapDefaultDataContainerTest.java:75)at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)at java.lang.reflect.Method.invoke(Method.java:606)
at
org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
at
org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
at org.testng.TestRunner.privateRun(TestRunner.java:767)
at org.testng.TestRunner.run(TestRunner.java:617)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
at org.testng.SuiteRunner.run(SuiteRunner.java:240)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1198)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1123)
at org.testng.TestNG.run(TestNG.java:1031)
at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111)
at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204)
at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175)
at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:125)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: java.lang.ClassNotFoundException:
org.infinispan.offheap.BondVOInterface$MarketPx£native
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
net.openhft.compiler.CachedCompiler.loadFromJava(CachedCompiler.java:108)
at
net.openhft.lang.model.DataValueGenerator.acquireNativeClass(DataValueGenerator.java:313)... 35 more
Custom suite
Total tests run: 1, Failures: 1, Skips: 0
Process finished with exit code 0
I became concerned that I may not be getting the 3.0e-SNAPSHOT effect
due
to something delinquent in my local maven build tactics (I'm used to
3.0d
being in maven central). So I ran a script to prune off any
non-3.0e-SNAPSHOT jar from my environment.root@i7-benx> find /root/.m2/repository/ -print | grep .jar | grep
collections-3.0/root/.m2/repository/net/openhft/collections/3.0e-SNAPSHOT/collections-3.0e-SNAPSHOT.jar.lastUpdated
/root/.m2/repository/net/openhft/collections/3.0e-SNAPSHOT/collections-3.0e-SNAPSHOT-sources.jar
/root/.m2/repository/net/openhft/collections/3.0e-SNAPSHOT/collections-3.0e-SNAPSHOT.jar
/root/.m2/repository/net/openhft/collections/3.0e-SNAPSHOT/collections-3.0e-SNAPSHOT-javadoc.jar
root@i7-benx>
SO I feel pretty sure that the local 3.0e-SNAPSHOT.jar is probably the
only possible HC library participarting in my test.Any ideas how to proceed?
P.S. Many many thanks!
Reply to this email directly or view it on GitHub<
https://github.com/OpenHFT/HugeCollections/issues/13#issuecomment-38338566>.
Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-38342702
.
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
New approach. Instead of welding OpenHFT into ISPN7 directly, we are going to build a new module
OpenHFT/HugeCollections/JCache
that will allow ISPN7 (and any other JSR-107 compliant JCACHE product) to come to OpenHFT and view this new module as an off-heap data container SPI. I.e. the mountain comes to OpenHFT, not OpenHFT goes to the mountain.
Xiao, Dmitry,
Please take these steps.
- cd brand_new_empty_workspace
- git clone https://github.com/infinispan/infinispan.git #our Fork of RedHat (needs unwelding)
- cd infinispan
- git remote add upstream https://github.com/infinispan/infinispan.git #[email protected]
- mvn -s maven-settings.xml install -DskipTests # has to be exactly like this (RedHat repos)
- cd ..
- git clone https://github.com/Cotton-Ben/OpenHFT.git #notice new JCache module
- cd OpenHFT
- git remote add upstream https://github.com/OpenHFT/OpenHFT.git
- for i in HugeCollections
Java-Chronicle
Java-Lang
Java-Runtime-Compiler
Java-Thread-Affinity
TransFIX
JCache
do
echo $i
rm -rf $i
git clone https://github.com/Cotton-Ben/$i.git
cd $i
git remote add upstream https://github.com/OpenHFT/$i.git
git remote -v
echo
cd -
done - mvn clean compile validate package install verify -DskipTests
- start intelliJ and (a) import maven project 'infinispan' and (b) import maven project 'OpenHFT'
- from OpenHFT project, goto src/test/java/net/openhft/jcache/OffHeapDefaultContainerTest.java line 290
- right click on 'testKeySet()' method and select "RUN testKeySet() TEST"
- Confirm you see the JL DataValueClassCache.java line 39 NPE
- Help me build this module as an OpenHFT/HC/JCache sub-module making it easier for Peter to support us.
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
Readable step 10
for i in HugeCollections \
Java-Chronicle \
Java-Lang \
Java-Runtime-Compiler \
Java-Thread-Affinity \
TransFIX \
JCache
do
echo $i
rm -rf $i
git clone https://github.com/Cotton-Ben/$i.git
cd $i
git remote add upstream https://github.com/OpenHFT/$i.git
git remote -v
echo
cd -
done
from hugecollections-old.
geminigx
commented on July 19, 2024
Hi Ben,
I tried these steps. Just move step #5 to right beofre step #12 and everything runs as you outline. If you leave step #5 as is, the build will technically fail because you OpenHFT reference is a SNAPSHOT (not in central repo). Other wise all good.
Thanks,
Xiao
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
Thanks so much, Xiao. I have re-factored all the SHM as JCACHE data container tests to fall under net.openhft.collections.jcache package (test scope). Our new [jcache] test join-point will eventually fall in line with the other [ipc] [osgi] [jsr166] [fromdocs] test peers under [collections]. This is a much better structure from which we can solicit Peter's support.
TODO: In my Fork, I can currently pass all the tests under
however I cannot pass any (of the now 10 total) tests under
please assist ! thx again, -Ben
from hugecollections-old.
peter-lawrey
commented on July 19, 2024
Can you move this to another/new module which is a pier to collections e.g.
jcache, and issue a pull request?
On 28 Mar 2014 21:08, "Ben Cotton" [email protected] wrote:
Thanks so much, Xiao. I have re-factored all the SHM as JCACHE data
container tests to fall under net.openhft.collections.jcache package (test
scope). Our new [jcache] test join-point will eventually fall in line with
the other [ipc] [osgi] [jsr166] [fromdocs] test peers under [collections].
This is a much better structure from which we can solicit Peter's support.TODO: In my Fork, I can currently pass all the tests under
however I cannot pass any (of the now 10 total) tests under
please assist ! thx again, -Ben
Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-38968143
.
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
Hi Xiao, made the latest commit at my RedHat fork (see Cotton-Ben/infinispan@3be5a0a) OpenHFT SHM is now an off-heap org.inifinispan,container.DataContainer. As per Peter, we are promoting [collections.jcache ] to be its own new [jcache] module. I will need you to take a look w me before issue pull request.
Hi Dmitry, I want to take everything we built specifically under org.infinispan.offheap and research building Peter a generic off-heap [SHM as JCACHE] SPI bridge - accommodating any JSR-107 impl's potential join to OpenHFT. This is no longer a musing, let's do it.
Hi Peter, working today on separating [jcache] as its own OpenHFT module.
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
HI Dimtry, Xiao
I have built this repo at https://github.com/Cotton-Ben/JCache from which I want to eventually build a pull request to Peter. There is nothing in it for the moment but the simplest join to JCACHE provider=ISPN7, bridging from OpenHFT SHM to RedHat as an off-heap DataContainer.
If you guys go to your workspace /apps/OpenHFT/
and execute a
git pull -u benstream master
does this new module show up? What exactly entails the 'issue a git pull request' mechanics? Did I just issue one to you? :-) or is it (likely) something more formal?
from hugecollections-old.
peter-lawrey
commented on July 19, 2024
I can't check now as I am on a plane. It's not too hard from the web gui.
On 29 Mar 2014 15:49, "Ben Cotton" [email protected] wrote:
HI Dimtry, Xiao
I have built this repo at https://github.com/Cotton-Ben/JCache from which
I want to eventually build a pull request to Peter. There is nothing in it
for the moment but the simplest join to JCACHE provider=ISPN7, bridging
from OpenHFT SHM to RedHat as an off-heap DataContainer.If you guys go to your workspace /apps/OpenHFT/
and execute a
git pull -u benstream master
does this new module show up? What exactly entails the 'issue a git pull
request' mechanics? Did I just issue one to you? :-) or is it (likely)
something more formal?Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-38999382
.
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
LOL. I was just at the web gui and am lost. will wait for Dmitry or
Xiao. Bon voyage.
On 03/29/2014 11:52 AM, Peter Lawrey wrote:
I can't check now as I am on a plane. It's not too hard from the web gui.
On 29 Mar 2014 15:49, "Ben Cotton" [email protected] wrote:HI Dimtry, Xiao
I have built this repo at https://github.com/Cotton-Ben/JCache from
which
I want to eventually build a pull request to Peter. There is nothing
in it
for the moment but the simplest join to JCACHE provider=ISPN7, bridging
from OpenHFT SHM to RedHat as an off-heap DataContainer.If you guys go to your workspace /apps/OpenHFT/
and execute a
git pull -u benstream master
does this new module show up? What exactly entails the 'issue a git pull
request' mechanics? Did I just issue one to you? :-) or is it (likely)
something more formal?Reply to this email directly or view it on
GitHubhttps://github.com//issues/13#issuecomment-38999382
.—
Reply to this email directly or view it on GitHub
#13 (comment).
from hugecollections-old.
RobAustin
commented on July 19, 2024
Ben, I can take a look
Rob
Sent from my iPad
On 29 Mar 2014, at 15:52, Peter Lawrey [email protected] wrote:
I can't check now as I am on a plane. It's not too hard from the web gui.
On 29 Mar 2014 15:49, "Ben Cotton" [email protected] wrote:HI Dimtry, Xiao
I have built this repo at https://github.com/Cotton-Ben/JCache from which
I want to eventually build a pull request to Peter. There is nothing in it
for the moment but the simplest join to JCACHE provider=ISPN7, bridging
from OpenHFT SHM to RedHat as an off-heap DataContainer.If you guys go to your workspace /apps/OpenHFT/
and execute a
git pull -u benstream master
does this new module show up? What exactly entails the 'issue a git pull
request' mechanics? Did I just issue one to you? :-) or is it (likely)
something more formal?Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-38999382
.—
Reply to this email directly or view it on GitHub.
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
Hi Rob, I just rolled back. I just Broke a few things Dmitry and Xiao
built. Will fix ASAP. Right now all we can do is attempt the lone Test
at
https://github.com/Cotton-Ben/JCache/blob/master/src/test/java/net/openhft/jcache/OffHeapDefaultDataContainerTest.java
from which we are trying to join collections=3.0e-SNAPSHOT to
infinispan-7.0.0-SNAPSHOT. Thx, Ben
On 03/29/2014 01:40 PM, Rob Austin wrote:
Ben, I can take a look
Rob
Sent from my iPad
On 29 Mar 2014, at 15:52, Peter Lawrey [email protected]
wrote:I can't check now as I am on a plane. It's not too hard from the web
gui.
On 29 Mar 2014 15:49, "Ben Cotton" [email protected] wrote:HI Dimtry, Xiao
I have built this repo at https://github.com/Cotton-Ben/JCache
from which
I want to eventually build a pull request to Peter. There is
nothing in it
for the moment but the simplest join to JCACHE provider=ISPN7,
bridging
from OpenHFT SHM to RedHat as an off-heap DataContainer.If you guys go to your workspace /apps/OpenHFT/
and execute a
git pull -u benstream master
does this new module show up? What exactly entails the 'issue a
git pull
request' mechanics? Did I just issue one to you? :-) or is it
(likely)
something more formal?Reply to this email directly or view it on
GitHubhttps://github.com//issues/13#issuecomment-38999382
.—
Reply to this email directly or view it on GitHub.—
Reply to this email directly or view it on GitHub
#13 (comment).
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
Hi Xiao. I just repaired my breaking of your correctly generic OffHeapDefaultDataContainer. In the repair process of repairing the damage I caused, I also found my misuse of OpenHFT's #newDirectReference() API. Ah, the shame. Monday should be productive. We should prioritize rolling forward everything back to our public repo's [jcache] module,and potentially, issuing a pull request to upstream OpenHFT. Thx, Ben
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
Ok. Rolled forward everything into our Fork's new candidate OpenHFT [jcache] module. The symmetry of a potentially (but definitely not yet) generic off-heap DataContainer looks good, but need to work with Xiao and Dmitry to get the
testSuite to pass.
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
Xiao, Dmitry: First 3.0e is released on mvn central, so update your builds. Also: on the RedHat side, I committed the code that joins our OpenHFT SHM adapted OffHeapDefaultDataContainer to the Infinispan JCache InternalEntryFactory (see Cotton-Ben/infinispan@2420ee9 ) but ... when we run our Test we currently see the following roadblock. Will need both of you guys' help to remedy.
C:\jdk1.7.0_45\bin\java -ea -Didea.launcher.port=7533 "-Didea.launcher.bin.path=C:\Program Files (x86)\JetBrains\IntelliJ IDEA Community Edition 13.0.2\bin" -Dfile.encoding=UTF-8 -classpath "C:\Program Files (x86)\JetBrains\IntelliJ IDEA Community Edition 13.0.2\plugins\testng\lib\testng-plugin.jar;C:\jdk1.7.0_45\jre\lib\charsets.jar;C:\jdk1.7.0_45\jre\lib\deploy.jar;C:\jdk1.7.0_45\jre\lib\javaws.jar;C:\jdk1.7.0_45\jre\lib\jce.jar;C:\jdk1.7.0_45\jre\lib\jfr.jar;C:\jdk1.7.0_45\jre\lib\jfxrt.jar;C:\jdk1.7.0_45\jre\lib\jsse.jar;C:\jdk1.7.0_45\jre\lib\management-agent.jar;C:\jdk1.7.0_45\jre\lib\plugin.jar;C:\jdk1.7.0_45\jre\lib\resources.jar;C:\jdk1.7.0_45\jre\lib\rt.jar;C:\jdk1.7.0_45\jre\lib\ext\access-bridge-64.jar;C:\jdk1.7.0_45\jre\lib\ext\dnsns.jar;C:\jdk1.7.0_45\jre\lib\ext\jaccess.jar;C:\jdk1.7.0_45\jre\lib\ext\localedata.jar;C:\jdk1.7.0_45\jre\lib\ext\sunec.jar;C:\jdk1.7.0_45\jre\lib\ext\sunjce_provider.jar;C:\jdk1.7.0_45\jre\lib\ext\sunmscapi.jar;C:\jdk1.7.0_45\jre\lib\ext\zipfs.jar;C:\cygwin64\home\ben\Github\OpenHFT\JCache\target\test-classes;C:\cygwin64\home\ben\Github\OpenHFT\JCache\target\classes;C:\Users\ben\.m2\repository\org\infinispan\infinispan-core\7.0.0-SNAPSHOT\infinispan-core-7.0.0-SNAPSHOT.jar;C:\Users\ben\.m2\repository\org\infinispan\infinispan-commons\7.0.0-SNAPSHOT\infinispan-commons-7.0.0-SNAPSHOT.jar;C:\Users\ben\.m2\repository\org\jboss\logging\jboss-logging\3.1.2.GA\jboss-logging-3.1.2.GA.jar;C:\Users\ben\.m2\repository\org\jgroups\jgroups\3.5.0.Alpha1\jgroups-3.5.0.Alpha1.jar;C:\Users\ben\.m2\repository\org\jboss\spec\javax\transaction\jboss-transaction-api_1.1_spec\1.0.1.Final\jboss-transaction-api_1.1_spec-1.0.1.Final.jar;C:\Users\ben\.m2\repository\org\jboss\marshalling\jboss-marshalling-river\1.4.4.Final\jboss-marshalling-river-1.4.4.Final.jar;C:\Users\ben\.m2\repository\org\jboss\marshalling\jboss-marshalling\1.4.4.Final\jboss-marshalling-1.4.4.Final.jar;C:\Users\ben\.m2\repository\javax\cache\cache-api\1.0.0-PFD\cache-api-1.0.0-PFD.jar;C:\Users\ben\.m2\repository\org\infinispan\infinispan-cdi\7.0.0-SNAPSHOT\infinispan-cdi-7.0.0-SNAPSHOT.jar;C:\Users\ben\.m2\repository\org\infinispan\infinispan-client-hotrod\7.0.0-SNAPSHOT\infinispan-client-hotrod-7.0.0-SNAPSHOT.jar;C:\Users\ben\.m2\repository\org\infinispan\infinispan-core\7.0.0-SNAPSHOT\infinispan-core-7.0.0-SNAPSHOT-tests.jar;C:\Users\ben\.m2\repository\org\testng\testng\6.1.1\testng-6.1.1.jar;C:\Users\ben\.m2\repository\junit\junit\4.11\junit-4.11.jar;C:\Users\ben\.m2\repository\org\beanshell\bsh\2.0b4\bsh-2.0b4.jar;C:\Users\ben\.m2\repository\com\beust\jcommander\1.12\jcommander-1.12.jar;C:\Users\ben\.m2\repository\org\yaml\snakeyaml\1.6\snakeyaml-1.6.jar;C:\cygwin64\home\ben\Github\OpenHFT\HugeCollections\collections\target\classes;C:\Users\ben\.m2\repository\com\intellij\annotations\12.0\annotations-12.0.jar;C:\jdk1.7.0_45\lib\tools.jar;C:\cygwin64\home\ben\Github\OpenHFT\Java-Lang\lang\target\classes;C:\Users\ben\.m2\repository\net\openhft\compiler\2.1\compiler-2.1.jar;C:\Users\ben\.m2\repository\net\openhft\affinity\2.0.1\affinity-2.0.1.jar;C:\Users\ben\.m2\repository\net\java\dev\jna\jna\4.0.0\jna-4.0.0.jar;C:\Users\ben\.m2\repository\net\java\dev\jna\platform\3.5.2\platform-3.5.2.jar;C:\Users\ben\.m2\repository\org\kohsuke\jetbrains\annotations\9.0\annotations-9.0.jar;C:\Users\ben\.m2\repository\org\hamcrest\hamcrest-core\1.3\hamcrest-core-1.3.jar;C:\Users\ben\.m2\repository\org\osgi\org.osgi.core\5.0.0\org.osgi.core-5.0.0.jar;C:\Users\ben\.m2\repository\org\osgi\org.osgi.compendium\5.0.0\org.osgi.compendium-5.0.0.jar;C:\Users\ben\.m2\repository\org\ops4j\pax\exam\pax-exam-container-native\3.4.0\pax-exam-container-native-3.4.0.jar;C:\Users\ben\.m2\repository\org\ops4j\pax\exam\pax-exam\3.4.0\pax-exam-3.4.0.jar;C:\Users\ben\.m2\repository\org\ops4j\base\ops4j-base-lang\1.4.0\ops4j-base-lang-1.4.0.jar;C:\Users\ben\.m2\repository\org\ops4j\base\ops4j-base-store\1.4.0\ops4j-base-store-1.4.0.jar;C:\Users\ben\.m2\repository\org\slf4j\slf4j-api\1.5.11\slf4j-api-1.5.11.jar;C:\Users\ben\.m2\repository\org\ops4j\base\ops4j-base-io\1.4.0\ops4j-base-io-1.4.0.jar;C:\Users\ben\.m2\repository\org\ops4j\base\ops4j-base-monitors\1.4.0\ops4j-base-monitors-1.4.0.jar;C:\Users\ben\.m2\repository\org\ops4j\base\ops4j-base-util-property\1.4.0\ops4j-base-util-property-1.4.0.jar;C:\Users\ben\.m2\repository\org\ops4j\pax\exam\pax-exam-spi\3.4.0\pax-exam-spi-3.4.0.jar;C:\Users\ben\.m2\repository\org\ops4j\base\ops4j-base-spi\1.4.0\ops4j-base-spi-1.4.0.jar;C:\Users\ben\.m2\repository\com\google\guava\guava\12.0\guava-12.0.jar;C:\Users\ben\.m2\repository\com\google\code\findbugs\jsr305\1.3.9\jsr305-1.3.9.jar;C:\Users\ben\.m2\repository\org\ops4j\pax\tinybundles\tinybundles\2.0.0\tinybundles-2.0.0.jar;C:\Users\ben\.m2\repository\biz\aQute\bnd\bndlib\2.1.0\bndlib-2.1.0.jar;C:\Users\ben\.m2\repository\org\ops4j\pax\swissbox\pax-swissbox-core\1.7.0\pax-swissbox-core-1.7.0.jar;C:\Users\ben\.m2\repository\org\ops4j\pax\swissbox\pax-swissbox-lifecycle\1.7.0\pax-swissbox-lifecycle-1.7.0.jar;C:\Users\ben\.m2\repository\org\ops4j\pax\swissbox\pax-swissbox-tracker\1.7.0\pax-swissbox-tracker-1.7.0.jar;C:\Users\ben\.m2\repository\org\ops4j\base\ops4j-base-net\1.4.0\ops4j-base-net-1.4.0.jar;C:\Users\ben\.m2\repository\org\ops4j\pax\url\pax-url-link\1.6.0\pax-url-link-1.6.0.jar;C:\Users\ben\.m2\repository\org\ops4j\pax\url\pax-url-commons\1.6.0\pax-url-commons-1.6.0.jar;C:\Users\ben\.m2\repository\org\ops4j\pax\swissbox\pax-swissbox-property\1.7.0\pax-swissbox-property-1.7.0.jar;C:\Users\ben\.m2\repository\org\ops4j\pax\url\pax-url-classpath\1.6.0\pax-url-classpath-1.6.0.jar;C:\Users\ben\.m2\repository\org\ops4j\pax\swissbox\pax-swissbox-optional-jcl\1.7.0\pax-swissbox-optional-jcl-1.7.0.jar;C:\Users\ben\.m2\repository\org\ops4j\pax\exam\pax-exam-junit4\3.4.0\pax-exam-junit4-3.4.0.jar;C:\Users\ben\.m2\repository\org\ops4j\pax\exam\pax-exam-link-mvn\3.4.0\pax-exam-link-mvn-3.4.0.jar;C:\Users\ben\.m2\repository\org\ops4j\pax\url\pax-url-aether\1.6.0\pax-url-aether-1.6.0.jar;C:\Users\ben\.m2\repository\org\ops4j\pax\url\pax-url-maven-commons\1.6.0\pax-url-maven-commons-1.6.0.jar;C:\Users\ben\.m2\repository\org\ops4j\base\ops4j-base-util-xml\1.4.0\ops4j-base-util-xml-1.4.0.jar;C:\Users\ben\.m2\repository\org\ops4j\base\ops4j-base-util-collections\1.4.0\ops4j-base-util-collections-1.4.0.jar;C:\Users\ben\.m2\repository\org\sonatype\aether\aether-api\1.13.1\aether-api-1.13.1.jar;C:\Users\ben\.m2\repository\org\sonatype\aether\aether-spi\1.13.1\aether-spi-1.13.1.jar;C:\Users\ben\.m2\repository\org\sonatype\aether\aether-util\1.13.1\aether-util-1.13.1.jar;C:\Users\ben\.m2\repository\org\sonatype\aether\aether-impl\1.13.1\aether-impl-1.13.1.jar;C:\Users\ben\.m2\repository\org\sonatype\aether\aether-connector-wagon\1.13.1\aether-connector-wagon-1.13.1.jar;C:\Users\ben\.m2\repository\org\apache\maven\wagon\wagon-provider-api\1.0\wagon-provider-api-1.0.jar;C:\Users\ben\.m2\repository\org\codehaus\plexus\plexus-utils\3.0\plexus-utils-3.0.jar;C:\Users\ben\.m2\repository\org\codehaus\plexus\plexus-classworlds\2.4\plexus-classworlds-2.4.jar;C:\Users\ben\.m2\repository\org\sonatype\sisu\sisu-inject-plexus\2.2.3\sisu-inject-plexus-2.2.3.jar;C:\Users\ben\.m2\repository\org\codehaus\plexus\plexus-component-annotations\1.5.5\plexus-component-annotations-1.5.5.jar;C:\Users\ben\.m2\repository\org\sonatype\sisu\sisu-inject-bean\2.2.3\sisu-inject-bean-2.2.3.jar;C:\Users\ben\.m2\repository\org\sonatype\sisu\sisu-guice\3.0.3\sisu-guice-3.0.3-no_aop.jar;C:\Users\ben\.m2\repository\org\apache\maven\maven-aether-provider\3.0.4\maven-aether-provider-3.0.4.jar;C:\Users\ben\.m2\repository\org\apache\maven\maven-model\3.0.4\maven-model-3.0.4.jar;C:\Users\ben\.m2\repository\org\apache\maven\maven-model-builder\3.0.4\maven-model-builder-3.0.4.jar;C:\Users\ben\.m2\repository\org\codehaus\plexus\plexus-interpolation\1.14\plexus-interpolation-1.14.jar;C:\Users\ben\.m2\repository\org\apache\maven\maven-repository-metadata\3.0.4\maven-repository-metadata-3.0.4.jar;C:\Users\ben\.m2\repository\org\apache\maven\wagon\wagon-file\1.0\wagon-file-1.0.jar;C:\Users\ben\.m2\repository\org\apache\maven\wagon\wagon-http-lightweight\1.0\wagon-http-lightweight-1.0.jar;C:\Users\ben\.m2\repository\org\apache\maven\wagon\wagon-http-shared\1.0\wagon-http-shared-1.0.jar;C:\Users\ben\.m2\repository\commons-io\commons-io\2.0.1\commons-io-2.0.1.jar;C:\Users\ben\.m2\repository\org\jsoup\jsoup\1.6.1\jsoup-1.6.1.jar;C:\Users\ben\.m2\repository\org\codehaus\plexus\plexus-container-default\1.5.5\plexus-container-default-1.5.5.jar;C:\Users\ben\.m2\repository\org\apache\xbean\xbean-reflect\3.4\xbean-reflect-3.4.jar;C:\Users\ben\.m2\repository\com\google\collections\google-collections\1.0\google-collections-1.0.jar;C:\Users\ben\.m2\repository\commons-httpclient\commons-httpclient\3.1\commons-httpclient-3.1.jar;C:\Users\ben\.m2\repository\commons-codec\commons-codec\1.2\commons-codec-1.2.jar;C:\Users\ben\.m2\repository\commons-logging\commons-logging\1.0.4\commons-logging-1.0.4.jar;C:\Users\ben\.m2\repository\org\ops4j\pax\url\pax-url-wrap\1.6.0\pax-url-wrap-1.6.0.jar;C:\Users\ben\.m2\repository\org\ops4j\pax\swissbox\pax-swissbox-bnd\1.7.0\pax-swissbox-bnd-1.7.0.jar;C:\Users\ben\.m2\repository\org\apache\felix\org.apache.felix.framework\4.2.1\org.apache.felix.framework-4.2.1.jar;C:\Program Files (x86)\JetBrains\IntelliJ IDEA Community Edition 13.0.2\plugins\testng\lib\testng.jar;C:\Program Files (x86)\JetBrains\IntelliJ IDEA Community Edition 13.0.2\lib\idea_rt.jar" com.intellij.rt.execution.application.AppMain org.testng.RemoteTestNGStarter -port 62601 -usedefaultlisteners false -socket62602 -temp C:\Users\ben\AppData\Local\Temp\idea_testng4463646136332375779.tmp
RemoteTestNG starting
ISPN7 JCACHE DataContainer view of OpenHFT SHM is being created
OpenHFT /dev/shm/net.openhft.jcache.OffHeapDefaultDataContainerTest.@t=1396268516361 entries=[{}]
RedHat Infinispan join point: initialize ....
ISPN7 JCACHE DataContainer created jcacheDataContainer=[net.openhft.jcache.offheap.container.OffHeapDefaultDataContainer@7f42ea9b]
warning: Supported source version 'RELEASE_6' from annotation processor 'org.sonatype.guice.bean.scanners.index.SisuIndexAPT6' less than -source '1.7'
1 warning
warning: Supported source version 'RELEASE_6' from annotation processor 'org.sonatype.guice.bean.scanners.index.SisuIndexAPT6' less than -source '1.7'
1 warning
OHDDC.put(k=369604103,v=BondVOInterface{ coupon= 0.055, issueDate= 20140315, maturityDate= 20440315, marketPxIntraDayHistory= [BondVOInterface.MarketPx{ askPx= 0.0, bidPx= 0.0, callPx= 0.0, maturityPx= 0.0, parPx= 0.0 }, BondVOInterface.MarketPx{ askPx= 0.0, bidPx= 0.0, callPx= 0.0, maturityPx= 0.0, parPx= 0.0 }, BondVOInterface.MarketPx{ askPx= 0.0, bidPx= 0.0, callPx= 0.0, maturityPx= 0.0, parPx= 0.0 }, BondVOInterface.MarketPx{ askPx= 0.0, bidPx= 0.0, callPx= 0.0, maturityPx= 0.0, parPx= 0.0 }, BondVOInterface.MarketPx{ askPx= 0.0, bidPx= 0.0, callPx= 0.0, maturityPx= 0.0, parPx= 0.0 }, BondVOInterface.MarketPx{ askPx= 0.0, bidPx= 0.0, callPx= 0.0, maturityPx= 0.0, parPx= 0.0 }, BondVOInterface.MarketPx{ askPx= 0.0, bidPx= 0.0, callPx= 0.0, maturityPx= 0.0, parPx= 0.0 }], symbol= IBM_HY_30_YR_5.5 },metaData=EmbeddedExpirableMetadata{lifespan=-1, maxIdle=6000000, version=null});
RedHat ICE OHDDC.entries=[{}]
RedHat InternalCacheEntry entries.get(k)=[NULL]
Oh, this is a brand new Entry<K,V>: RedHat EntryFactory eF.create(k,v,metadata); eF=[net.openhft.jcache.offheap.container.OffHeapInternalEntryFactoryImpl@39078501]
OHDDC.entries.put(k=369604103, e=OffHeapMetadataTransientCacheEntry{key=369604103});
java.lang.ClassCastException: Value must be a net.openhft.jcache.BondVOInterface but was a class net.openhft.jcache.offheap.container.entries.metadata.OffHeapMetadataTransientCacheEntry
at net.openhft.collections.VanillaSharedHashMap.checkValue(VanillaSharedHashMap.java:204)
at net.openhft.collections.VanillaSharedHashMap.put0(VanillaSharedHashMap.java:227)
at net.openhft.collections.VanillaSharedHashMap.put(VanillaSharedHashMap.java:214)
at net.openhft.jcache.offheap.container.OffHeapDefaultDataContainer.put(OffHeapDefaultDataContainer.java:172)
at net.openhft.jcache.OffHeapDefaultDataContainerTest.testOpenHFTasOffHeapJcacheOperandProvider(OffHeapDefaultDataContainerTest.java:97)
RemoteTestNG finishing: 9159 ms
Process finished with exit code 0
from hugecollections-old.
geminigx
commented on July 19, 2024
Ben, we need to first isolate and demonstrate that we can do a VanillaSharedHashMap<String, InternalCacheEntry>.put("CUSIP1234",V) -- where V is RedHat ICE reference. Otherwise, we cannot cross from JCACHE-->OffHeapDefaultDataContainer-->ICE-->SHM.
Thanks, Xiao
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
Thanks Xiao. Hmmm. Let me reach out to Tristan and Mircea for RedHat counsel. I mean their on-heap DefaultDataContainer has to provide some lesson and mechanism as to how to take an arbitrary V (like our BondVOInterface) and via ICE put into their final ConcurrentMap
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
Xiao, Dmitry: Don't worry about the change in OpenHFT root module build anatomy. Peter released both HC 3.0e and JL 6.3.4 into Maven central. For now, we don't have urgent need to build anything from OpenHFT source. Let's now spend time specifically on the RedHat facing off-heap JCACHE join to SHM. Please take these steps to confirm:
1. cd $WORKSPACE
2. git clone https://github.com/Cotton-Ben/infinispan.git
3. cd infinispan
4. mvn -s maven-settings.xml install -DskipTests #do *not* build from IntelliJ, it will *not* work
5. import as maven project $WORKSPACE/infinispan into IntelliJ
6. From IntelliJ, right-click on https://github.com/Cotton-Ben/infinispan/blob/master/off-heap/src/test/java/org/infinispan/offheap/OffHeapDefaultDataContainerTest.java and select "Run Tests"
7. Confirm all the Test(s) BondVOInterface put(s) via OffHeapDefaultDataContainer successfully write off-heap to /dev/shm
8. Do not worry about the the RedHat EntryFactory.create() tests failings ... we know we have to meet with Mircea re: correct, generic ICE adaptation.
Thx,
Ben
from hugecollections-old.
geminigx
commented on July 19, 2024
Confirmed, everything works as per the given instructions.
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
Thanks Xiao. I have asked RedHat (Mircea, Tristan, Adrian) for a meeting to discuss next steps. Let's you, Dmitry and I re-sort the attached. I speculatively assert that we can benefit if RedHat makes their DataContainer API perfectly <K,V> generic. They presently immediately bind to typeSet <Object, ICE> ... which pays ZERO accommodation to our off-heap ambition to build and SHM bridge at this crossing. Let's sort it out.
What we ultimately want to do is build an ISPN7-valid Test of a new bridge that connects a JCACHE API view to an HPC off-heap capability.
Specifically:
from
1. Cache.Entry<K,V> API view (ISPN7 AdvancedCache CacheImpl) to
2. DataContainer<K,V> API view (JPM OffHeapDefaultDataContainer<K,V> Impl) to
3. SharedHashMap<K,V> API view (OpenHFT VanillaSharedHashMap<K,V> Impl)
We want to model the planned off-heap bridge described above, based off of the symmetry any exisiting Red-Hat test that proves an inplace existing on-heap bridge from
1. Cache.Entry<K,V> API view (ISPN7 AdvancedCache CacheImpl<K,V>) to
2. DataContainer API view (RedHat DefaultDataContainer Impl) to (#not generic)
3. ConcurrentMap<K,V> API view (RedHat BoundedConcurrentHashMap<K,V> Impl)
The potential roadblock that has us mildly concerned is that neither of
DataContainer nor DefaultDataContainer are explicilty generic on <K,V> and instead binds as <Object,InternalCacheEntry>. Interestingly, BoundedConcurrentMap is generic on <K,V> (but the current bridge to it may not take adavantage of that). This DataContainer binding to something that is not formally <K,V> may be a problem with our ultimately, generically, building a best bridge to the off-heap capability.
Today's meeting at JPM is to explore this concern and identify our view of it as an (isA|isNotA) potential roadblock.
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
Also, let's (quickly) determine if (maybe?) HHM would be any easier than SHM as an initial DataContainer join to RedHat.
from hugecollections-old.
Cotton-Ben
commented on July 19, 2024
This did not format in the email to Git (weird)
Neither RedHat's DataContainer nor DefaultDataContainer are explicilty generic on <K,V> and instead binds as <Object,InternalCacheEntry>.
from hugecollections-old.
peter-lawrey
commented on July 19, 2024
HHM is designed to be similar in behaviour to SHM. It is resizeable and can
have oversized entries.
On 3 Apr 2014 08:07, "Ben Cotton" [email protected] wrote:
Also, let's (quickly) determine if (maybe?) HHM would be any easier than
SHM as an initial DataContainer join to RedHat.Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-39448249
.
from hugecollections-old.
peter-lawrey
commented on July 19, 2024
As Serializable is supported you can have anything it supports. Note: you
cannot share references between values or keys or anything else. A value
(or key) must be self contained.
I suggest BytesMarshallable as this has some methods for more efficient
writing of Maps and collections than Externalizable.
On 3 April 2014 08:17, Ben Cotton [email protected] wrote:
Does HHM offer any advantage wrt to generic V custody? i.e. if I trade-off
my ZERO-COPY for Externalizable ambitions, can I get a V that accommodates
more complex Object graphs (as V)?With that trade off, can I realize an arbitrarily complex Object graph as
V?Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-39449288
.
from hugecollections-old.
ben--cotton
commented on July 19, 2024
Dmitry, Xiao: wrt to Tue's conf call w/ RedHat and OpenHFT, please review this Draft adapter.
If it seems right, this weekedn I'll build all the off-heap RedHat tests for all the impls under https://github.com/Cotton-Ben/infinispan/tree/master/off-heap/src/main/java/org/infinispan/offheap/container/entries
We get this API adapter to work in such a way that when crossing the off-heap bridge from JCACHE to Peter's Entry we also find an exact ref instance of RedHat ICE. Ironically, we are asking the algos to "find" our LRI RDR_DIM operands by crossing an "ICEy Bridge" ... sorry, not too punny (exhausted).
from hugecollections-old.
RobAustin
commented on July 19, 2024
Since this has been open since april, Im going to close this issue, unless anyone has any objections
from hugecollections-old.
Related Issues (20)
- setSegments(int) is not public in HugeConfig; cannot be accessed from outside package HOT 3
- Comparing behaviour of HugeHashMap with HashMap HOT 2
- custom marshalling/serialization HOT 16
- remark on replication/distribution HOT 9
- how to get exactly 1 OpenHFT test to run HOT 10
- Using Shared/HugeHashMap HOT 3
- PingPong latency test across /dev/shm/SharedHashMap IPC ... HOT 19
- support for "read through" and "write behind" gettr/settrs (in addition to JBI) HOT 25
- Cache size exceed bug HOT 1
- TCPSocketReplication4WayMapTest testBufferOverflow failed (Windows 8.1) HOT 10
- VanillaShortShortMultiMap is full when capacity is still available HOT 5
- Difference between setSmallEntrySize and setCapacity
- SharedHashMap: iterating using keyset, valueset is very slow for larger tables HOT 8
- problem using SharedHashMapBuilder ... HOT 6
- OpenHFT scope of capability re: SHMEntry fields (user JBI supplied) and "barrier" operations HOT 9
- HugeHashMap with JPA elements HOT 4
- SharedHashMap causing crash on Windows OS HOT 28
- Chronicle Map not thread-safe in certain circumstances HOT 14
- ChronicleMap / ChronicleMapBuilder - actualEntriesPerSegment restricted to minimum of 8 HOT 13
- too many Segment.getKey() invocations HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from hugecollections-old.