date:20110818

[jira] [Commented] (CASSANDRA-2820) Re-introduce FastByteArrayInputStream (and Output equivalent)

2011-08-18 Thread Norman Maurer (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086831#comment-13086831
]

Norman Maurer commented on CASSANDRA-2820:
--

Wouldn't this stuff be a nice contribution to the commons-io project ?

Re-introduce FastByteArrayInputStream (and Output equivalent)
-

Key: CASSANDRA-2820
URL: https://issues.apache.org/jira/browse/CASSANDRA-2820
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 0.8.0
Environment: n/a
Reporter: Paul Loy
Assignee: Paul Loy
Priority: Minor
Labels: bytearrayinputstream, bytearrayoutputstream, license,
synchronized
Fix For: 1.0

Attachments: fast_bytearray_iostreams_harmony-patch-2.txt,
fast_bytearray_iostreams_harmony-patch-3.txt,
fast_bytearray_iostreams_harmony-patch-4.txt,
fast_bytearray_iostreams_harmony-patch-5.txt,
fast_bytearray_iostreams_harmony-patch-6.txt

In https://issues.apache.org/jira/browse/CASSANDRA-37
FastByteArrayInputStream and FastByteArrayOutputStream were removed due to
being code copied from the JDK and then subsequently modified. The JDK
license is incompatible with Apache 2 license so the code had to go.
I have since had a look at the performance of the JDK ByteArrayInputStream
and a FastByteArrayInputStream (i.e. one with synchronized methods made
un-synchronized) and seen the difference is significant.
After a warmup-period of 1 loops I get the following for 1 loops
through a 128000 byte array:
bais : 3513ms
fbais: 72ms
This varies depending on the OS, machine and Java version, but it's always in
favour of the FastByteArrayInputStream as you might expect.
Then, at Jonathan Ellis' suggestion, I tried this using a modified Apache
Harmony ByteArrayInputStream - i.e. one whose license is compatible - and the
results were the same. A significant boost.
I will attach a patch with changes for the 0.8.0 tag.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3048) SimpleAuthority should reload property file automatically

2011-08-18 Thread Thomas Peuss (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-3048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086832#comment-13086832
 ] 

Thomas Peuss commented on CASSANDRA-3048:
-

Like in SimpleAuthenticator the properties-file is loaded on every request. If 
that is not OK I can change the patch in a way to check the 
lastModified-timestamp of the property-file.
If we do that we should change SimpleAuthenticator as well.

 SimpleAuthority should reload property file automatically
 -

 Key: CASSANDRA-3048
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3048
 Project: Cassandra
  Issue Type: Improvement
Reporter: Thomas Peuss
Priority: Minor
 Attachments: CASSANDRA-3048.patch


 Currently you need a restart of Cassandra to load a changed access.properties 
 file. This is very annoying. The patch changes the behaviour of 
 SimpleAuthority to match the behaviour of SimpleAuthenticator.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-2630) CLI - 'describe column family' would be nice

2011-08-18 Thread satish babu krishnamoorthy (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

satish babu krishnamoorthy updated CASSANDRA-2630:
--

Attachment: cassandra-0.8.2-2630.txt

 CLI - 'describe column family' would be nice
 

 Key: CASSANDRA-2630
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2630
 Project: Cassandra
  Issue Type: Improvement
Affects Versions: 0.8.2
Reporter: Jeremy Hanna
Priority: Minor
  Labels: cli, lhf
 Attachments: cassandra-0.8.2-2630.txt


 I end up verifying column families a lot and using 'describe keyspace 
 keyspace;' spits out a whole bunch of data since our keyspace has a lot of 
 metadata.  It would be really useful to have a 'describe column family;' 
 for a given column family in the currently authenticated keyspace.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-1285) Have a way to increase the replication factor

2011-08-18 Thread Carl Heymann (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086835#comment-13086835
 ] 

Carl Heymann commented on CASSANDRA-1285:
-

I see the issue is resolved. Is there any special procedure necessary to change 
the replication factor? If I try to update as follows (on a keyspace with 
RF=2), using the CLI:
{code}
update keyspace LTS with strategy_options=[{replication_factor:3}];
{code}
I don't see any change in RF reported with describe keyspace LTS; It remains 
2. Adding the placement strategy into the update command doesn't make a 
difference. If I run repair on all nodes (there are 3 nodes), I don't see any 
changes either.

Is there a different way I can try to achieve this?

 Have a way to increase the replication factor
 -

 Key: CASSANDRA-1285
 URL: https://issues.apache.org/jira/browse/CASSANDRA-1285
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Affects Versions: 0.7 beta 1
Reporter: Arya Goudarzi
Assignee: Gary Dusbabek
 Fix For: 0.7 beta 2

 Attachments: v2-0001-thrift-changes.txt, 
 v2-0002-UpdateKeyspace-migration.txt, v2-0003-UpdateColumn-family.txt, 
 v2-0004-avro-update-ks-and-cf-implementations.txt


 In 0.6 we were able to change the storage.conf and increase the replication 
 factor and restart the server then repair the data across cluster to increase 
 the replication factor for a keyspace. In 0.7 having moved away from 
 storage.conf, it would be a good idea to have a method in api/jmx to alter 
 keyspace so that replication factor could be changed as in 0.6. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Edited] (CASSANDRA-1285) Have a way to increase the replication factor

2011-08-18 Thread Carl Heymann (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086835#comment-13086835
 ] 

Carl Heymann edited comment on CASSANDRA-1285 at 8/18/11 6:42 AM:
--

I see the issue is resolved. Is there any special procedure necessary to change 
the replication factor? If I try to update as follows (on a keyspace with 
RF=2), using the CLI (cassandra v0.8.0):
{code}
update keyspace LTS with strategy_options=[{replication_factor:3}];
{code}
I don't see any change in RF reported with describe keyspace LTS; It remains 
2. Adding the placement strategy into the update command doesn't make a 
difference. If I run repair on all nodes (there are 3 nodes), I don't see any 
changes either.

Is there a different way I can try to achieve this?

  was (Author: carl.heymann):
I see the issue is resolved. Is there any special procedure necessary to 
change the replication factor? If I try to update as follows (on a keyspace 
with RF=2), using the CLI:
{code}
update keyspace LTS with strategy_options=[{replication_factor:3}];
{code}
I don't see any change in RF reported with describe keyspace LTS; It remains 
2. Adding the placement strategy into the update command doesn't make a 
difference. If I run repair on all nodes (there are 3 nodes), I don't see any 
changes either.

Is there a different way I can try to achieve this?
  
 Have a way to increase the replication factor
 -

 Key: CASSANDRA-1285
 URL: https://issues.apache.org/jira/browse/CASSANDRA-1285
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Affects Versions: 0.7 beta 1
Reporter: Arya Goudarzi
Assignee: Gary Dusbabek
 Fix For: 0.7 beta 2

 Attachments: v2-0001-thrift-changes.txt, 
 v2-0002-UpdateKeyspace-migration.txt, v2-0003-UpdateColumn-family.txt, 
 v2-0004-avro-update-ks-and-cf-implementations.txt


 In 0.6 we were able to change the storage.conf and increase the replication 
 factor and restart the server then repair the data across cluster to increase 
 the replication factor for a keyspace. In 0.7 having moved away from 
 storage.conf, it would be a good idea to have a method in api/jmx to alter 
 keyspace so that replication factor could be changed as in 0.6. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3044) Hector NodeAutoDiscoverService fails to resolve hosts due to / being part of the IP address

2011-08-18 Thread Tomas Salfischberger (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086940#comment-13086940
 ] 

Tomas Salfischberger commented on CASSANDRA-3044:
-

Issue also affects the Pelops client from Scale7 
(https://github.com/s7/scale7-pelops).

 Hector NodeAutoDiscoverService fails to resolve hosts due to / being part of 
 the IP address
 ---

 Key: CASSANDRA-3044
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3044
 Project: Cassandra
  Issue Type: Bug
  Components: Core, Drivers
Affects Versions: 0.8.4
 Environment: Cassandra 0.8.4, hector 0.8.0
Reporter: Aaron Turner
Assignee: Brandon Williams
 Fix For: 0.8.5


 Didn't get this problem with Cassandra 0.8.2- started happening under 0.8.4.  
 Temporary work around was to disable node auto discovery.  Seems to be 
 related to:
 http://svn.apache.org/viewvc?view=revrevision=1155157
 http://issues.apache.org/jira/browse/CASSANDRA-1777
 LOG:
 240514 [pool-2-thread-1] INFO 
 me.prettyprint.cassandra.connection.NodeAutoDiscoverService - using existing 
 hosts [10.255.255.176(10.255.255.176):9160, 
 10.255.255.175(10.255.255.175):9160]
 240553 [pool-2-thread-1] ERROR me.prettyprint.cassandra.service.CassandraHost 
 - Unable to resolve host /10.255.255.176
 240553 [pool-2-thread-1] INFO 
 me.prettyprint.cassandra.connection.NodeAutoDiscoverService - Found a node we 
 don't know about /10.255.255.176(/10.255.255.176):9160 for TokenRange 
 TokenRange(start_token:33370589793653380361461751202224080323, 
 end_token:93518639523624865529944734322199113946, endpoints:[/10.255.255.176])
 240553 [pool-2-thread-1] INFO 
 me.prettyprint.cassandra.connection.NodeAutoDiscoverService - Found 1 new 
 host(s) in Ring
 240553 [pool-2-thread-1] INFO 
 me.prettyprint.cassandra.connection.NodeAutoDiscoverService - Addding found 
 host /10.255.255.176(/10.255.255.176):9160 to pool
 240554 [pool-2-thread-1] ERROR 
 me.prettyprint.cassandra.connection.HConnectionManager - General exception 
 host to HConnectionManager: /10.255.255.176(/10.255.255.176):9160
 java.lang.IllegalArgumentException: protocol = socket host = null
 at 
 sun.net.spi.DefaultProxySelector.select(DefaultProxySelector.java:151)
 at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:358)
 at java.net.Socket.connect(Socket.java:529)
 at org.apache.thrift.transport.TSocket.open(TSocket.java:178)
 at 
 org.apache.thrift.transport.TFramedTransport.open(TFramedTransport.java:81)
 at 
 me.prettyprint.cassandra.connection.HThriftClient.open(HThriftClient.java:123)
 at 
 me.prettyprint.cassandra.connection.ConcurrentHClientPool.init(ConcurrentHClientPool.java:43)
 at 
 me.prettyprint.cassandra.connection.RoundRobinBalancingPolicy.createConnection(RoundRobinBalancingPolicy.java:68)
 at 
 me.prettyprint.cassandra.connection.HConnectionManager.addCassandraHost(HConnectionManager.java:103)
 at 
 me.prettyprint.cassandra.connection.NodeAutoDiscoverService.doAddNodes(NodeAutoDiscoverService.java:68)
 at 
 me.prettyprint.cassandra.connection.NodeAutoDiscoverService$QueryRing.run(NodeAutoDiscoverService.java:53)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
 at 
 java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
 at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:662)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

69 matches

Mail list logo